Linux Trojan rears its ugly head(sophos.com)
sophos.com
Linux Trojan rears its ugly head
http://www.sophos.com/blogs/chetw/g/2010/06/12/linux-malware-rears-ugly-head/
6 comments
"One in 25 years" is far too optimistic (see e.g. http://secunia.com/advisories/product/2719/?task=advisories - the NULL pointer bug was exploitable only from programs already running on the host, so most of these "count" by your criteria), but yes - the article is nonsensical.
Linux has exploitable bugs about once a week, read lwn and scan over the security page for kernel cve's.
follow up interesting question - do you trust the compiler you use to build from source?
<sarcasm>I am so scared by this. You mean, a program I run can do things I don't expect it to do? Oh my... This is huge!</sarcasm>
No, really.
As far as we can know, every instance of Oracle RDBMS, PeopleSoft, AutoCAD, PhotoShop, Windows, Exchange, Office and SQL Server may harbor any number of backdoors. We will never know, since, as the article points out, we cannot examine the source code. And Sophos probably won't know either unless the maker is lame enough to include a fingerprintable backdoor.
If you are a package maintainer, you should always get your source off the tagged releases in the version control system. That way you can always test your build off trunk/head/whatever-the-most-current-version-is and ensure that, when the next release becomes adopted, your package will be fine.
If you are a Linux sysadmin and you are not using package management, you are insane. Or you will be, shortly. Even if you have to use the "yesterday" release, you should build your own package.
No, really.
As far as we can know, every instance of Oracle RDBMS, PeopleSoft, AutoCAD, PhotoShop, Windows, Exchange, Office and SQL Server may harbor any number of backdoors. We will never know, since, as the article points out, we cannot examine the source code. And Sophos probably won't know either unless the maker is lame enough to include a fingerprintable backdoor.
If you are a package maintainer, you should always get your source off the tagged releases in the version control system. That way you can always test your build off trunk/head/whatever-the-most-current-version-is and ensure that, when the next release becomes adopted, your package will be fine.
If you are a Linux sysadmin and you are not using package management, you are insane. Or you will be, shortly. Even if you have to use the "yesterday" release, you should build your own package.
This is a few weeks old right? Where did it go from there? Are we (linux users) all infected with lots of rootkits and file infectors and worms? No.
The interesting question is not "Are linux machines infected with a cloud of malware like Windows machines?" but rather, "What factors contribute to Windows malware that don't exist for Linux?". That is, on a technical level, Linux is just as vulnerable as Windows. Fred Cohen did his initial experiments on a a 4.3BSD machine in the early 80s, so we've know about the vulnerability all along.
Linux just doesn't accumulate the uncountable legions of malware that Windows does. It can't really be "market share", as even at 1% of all users, Linux desktops probably count higher than MS-DOS did in 1988, when the "Brain" virus swept through the population. So, this Sophos-employeed blogger should shy away from his name-calling, and start researching the really interesting "why" to see if it can't be applied back to Windows.
The interesting question is not "Are linux machines infected with a cloud of malware like Windows machines?" but rather, "What factors contribute to Windows malware that don't exist for Linux?". That is, on a technical level, Linux is just as vulnerable as Windows. Fred Cohen did his initial experiments on a a 4.3BSD machine in the early 80s, so we've know about the vulnerability all along.
Linux just doesn't accumulate the uncountable legions of malware that Windows does. It can't really be "market share", as even at 1% of all users, Linux desktops probably count higher than MS-DOS did in 1988, when the "Brain" virus swept through the population. So, this Sophos-employeed blogger should shy away from his name-calling, and start researching the really interesting "why" to see if it can't be applied back to Windows.
One solid technical reason is that most Windows users run as Administrator (root) which eases the spread of malware.
In addition, the lack of uniformity makes it more challenging to write an Unix virus. You'd need to have the worm recompile itself on the target machine, as did the Morris worm in 1988. That greatly increases complexity and cost.
Many Windows worms target a specific client/OS pair. That means the worm will require you to run, say, Outlook Express and Windows XP. That sounds pretty specific, but the potential target size is so huge that the virus author can allow itself to be that restrictive.
Let's imagine a disease that could contaminate only one human being out of a hundred.
How fast do you think the disease would spread compared to one that can infect ninety human beings out of a hundred?
Why bother write a malware that has got - even if it's perfectly written - an order of magnitude less chances to spread?
In addition, the lack of uniformity makes it more challenging to write an Unix virus. You'd need to have the worm recompile itself on the target machine, as did the Morris worm in 1988. That greatly increases complexity and cost.
Many Windows worms target a specific client/OS pair. That means the worm will require you to run, say, Outlook Express and Windows XP. That sounds pretty specific, but the potential target size is so huge that the virus author can allow itself to be that restrictive.
Let's imagine a disease that could contaminate only one human being out of a hundred.
How fast do you think the disease would spread compared to one that can infect ninety human beings out of a hundred?
Why bother write a malware that has got - even if it's perfectly written - an order of magnitude less chances to spread?
I will burst out laughing if a worm on my linux starts ask for dependencies.
Why bother write a malware that has got an order of magnitude less chances to spread?
Taking that viewpoint means explaining Windows malware like this: http://www.virusbtn.com/virusbulletin/archive/2009/09/vb2009...
That's an old school Windows file infector, if I read the article correctly. Win32/Induc.A infects Delphi compilers only. And yet it spread around all over the place.
The author of the link above writes this: "It seems clear that we’ve reached an era where rare dependencies, such as having a compiler on the system, or logic bombs can thrive."
Surely linux desktops are far more prevalent than Windows machines with Delphi compilers. This seems like a perfect counter example to the "Market Share" hypothesis. It would seem that the culture of Windows use has some part in their plight.
Taking that viewpoint means explaining Windows malware like this: http://www.virusbtn.com/virusbulletin/archive/2009/09/vb2009...
That's an old school Windows file infector, if I read the article correctly. Win32/Induc.A infects Delphi compilers only. And yet it spread around all over the place.
The author of the link above writes this: "It seems clear that we’ve reached an era where rare dependencies, such as having a compiler on the system, or logic bombs can thrive."
Surely linux desktops are far more prevalent than Windows machines with Delphi compilers. This seems like a perfect counter example to the "Market Share" hypothesis. It would seem that the culture of Windows use has some part in their plight.
"Why bother write a malware that has got ... an order of magnitude less chances to spread?"
That's plain wrong. Read Rick Moen takes on the subject here: http://linuxmafia.com/~rick/faq/index.php?page=virus#virus4
That's plain wrong. Read Rick Moen takes on the subject here: http://linuxmafia.com/~rick/faq/index.php?page=virus#virus4
I don't know this Mr. Moen, but the fallacy may not be where he believes it is.
When writing an exploit you need to know the kernel, libc and apache version to make your buffer overflow work, because memory layout is important - if it's a buffer overflow. There are so many apache builds, that makes things difficult for a worm (but not for a targeted exploit). Not impossible, but more difficult.
On Windows, the build is uniform.
Additionally, servers are less interesting targets since they are more monitored and operated by administrators. If your plan is to have as many zombies as possible, not a good idea.
Last but not least, a lot of virii and trojans use mail and the web as a channel. AFAIK you don't read mails and visit web pages on servers.
If the underlying argument is that there are less virii on Linux because it's more secure than Windows, this is wrong.
It's difficult to "measure" security and I really don't want to have a Linux vs Windows debate, but Windows cannot be considered as an insecure operating system anymore. User's behavior on the other hand, is still problematic.
When writing an exploit you need to know the kernel, libc and apache version to make your buffer overflow work, because memory layout is important - if it's a buffer overflow. There are so many apache builds, that makes things difficult for a worm (but not for a targeted exploit). Not impossible, but more difficult.
On Windows, the build is uniform.
Additionally, servers are less interesting targets since they are more monitored and operated by administrators. If your plan is to have as many zombies as possible, not a good idea.
Last but not least, a lot of virii and trojans use mail and the web as a channel. AFAIK you don't read mails and visit web pages on servers.
If the underlying argument is that there are less virii on Linux because it's more secure than Windows, this is wrong.
It's difficult to "measure" security and I really don't want to have a Linux vs Windows debate, but Windows cannot be considered as an insecure operating system anymore. User's behavior on the other hand, is still problematic.
Most Linux users get all their software from their distribution's repositories, instead of pulling source from assorted websites. All major distributions GPG sign their packages and use (GPG signed) checksums, which are automatically verified by the package managers.
On Windows, you may need to go to dozens of vendor sites to get software updates - each with their own update procedure (in addition to the Windows update itself). This process alone is probably responsible for many Windows infections, as it's hard for end-users to tell what's 'normal'.
There's also a difference in the user base. Linux desktop users, by definition, are more technically knowledgeable and experienced - they can install an OS. As trivial as it sounds, most people are not willing or able to do that. The willingness to learn what's necessary leads to better practices.
On Windows, you may need to go to dozens of vendor sites to get software updates - each with their own update procedure (in addition to the Windows update itself). This process alone is probably responsible for many Windows infections, as it's hard for end-users to tell what's 'normal'.
There's also a difference in the user base. Linux desktop users, by definition, are more technically knowledgeable and experienced - they can install an OS. As trivial as it sounds, most people are not willing or able to do that. The willingness to learn what's necessary leads to better practices.
The authors are now GPG-signing their releases to allow their customers to determine the validity of an archive.
It's an IRC daemon. Weren't half of these trojaned anyway? Most of these may as well have been written by the past equivalent of 4Chan.
sophos anti-virus wasn't able to detect compromised binaries or source until nearly 2 years after compromise, just like the rest of us. sounds like software i don't need.
(and that's assuming you get their on-demand scanning working (talpa) which only seems to work with out of date kernels.)
(and that's assuming you get their on-demand scanning working (talpa) which only seems to work with out of date kernels.)
As others have pointed out, this isn't a "linux trojan" as much as it is a "software source code repository hack."
Dropping a trojan into someones unguarded source repository can happen on any system. This isn't anywhere close to a "security breach" for linux because people still had to download and compile source.
This raises an interesting question - do you trust the source you build? But that's a different issue. The closest thing to Linux security issues is the null pointer bug which allows arbitrary execution as root. And that's like one in 25 years as far as I know.