Slashdot Log In
Linux Worm Spreading, Many Systems Vulnerable
Posted by
timothy
on Fri Sep 13, 2002 06:59 PM
from the patchy-patchy dept.
from the patchy-patchy dept.
sverrehu writes "A GNU/Linux worm exploiting a bug in OpenSSL spreads through vulnerable Apache web servers, according to Symantec. The worm, which was first reported in Europe, targets several popular Linux distributions. See also the SecurityFocus vulnerability listing for the OpenSSL bug." sionide also writes: "Netcraft recently published a report which explains that a large portion of Apache systems are still unpatched (halfway down). To protect yourself please upgrade to OpenSSL 0.9.6g."
This discussion has been archived.
No new comments can be posted.
Linux Worm Spreading, Many Systems Vulnerable
|
Log In/Create an Account
| Top
| 617 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Finally (Score:5, Funny)
Open Source Vulnerable Too (Score:3, Insightful)
Re:Open Source Vulnerable Too (Score:4, Insightful)
Maybe the stats aren't as bad as they think... (Score:5, Informative)
"Almost half of the 22 million Apache HTTP sites found by the survey are running Apache/1.3.26, whilst only around a quarter of the Apache SSL sites are running this version, which fixes the chunked encoding vulnerability."
Does this statistic take into account that some Linux distros (for example, RedHat) backport the bugfixes to earlier versions of Apache/OpenSSL/etc.??
All of our servers are running Apache 1.3.23, but it's 1.3.23 release 14 which DOES include the fixes for the bugs mentioned on that page. If they are simply going by the Apache version number reported, then they may be over-estimating the number of vulnerable web servers by several million...
But you all know what they say about statistics anyway...
Re:Open Source Vulnerable Too (Score:4, Insightful)
Airline pilots are highly trained and constantly upgrade their skills, and are highly paid.
Likewise, programmers who run enterprise-strength systems have heavy responsibilities. This is not something one ought to go into for the money, but rather, for the love and dedication to the craft. (not aircraft)...
As far as QA, I tell you what. If the system is designed correctly, it will need very little QA. I know this because some systems can never get it right, no matter how much QA go into them, because of fundamuntal design flaws.
And yes, designing computer software is hard. Like heart surgery. One slip of the old wrist and it's flatline.
Not overrated. (Score:5, Insightful)
All the skill it should take is to apt-get upgrade or up2date, or whatever the distro in question uses for updates. Debian woody had the patch posted immediately. So the skills needed to update your Apache system are no different from those needed to patch code red (Which, a year after its creation, is still roaming around)
The often tauted ability to "go in and fix things" or even to simply "contribute" is highly overrated. Who found and fixed this bug? Was it some random user, or one of the original developers?
Well, judging by the advisory from the OpenSSL team [openssl.org] (Dated July 30, btw, this is hardly a new issue) and a cursory glance over the developer list [openssl.org], the advisory issue was not found by anyone on the development team. So, I'm going to have to go ahead and disagree with you. I consider the ability of users to find and patch security vulnerabilities to be a benefit of free software that simply cannot be overstated.
Having said that, I'll concede the obvious. Most end users are not skilled in the ways of finding or fixing bugs. However, there are zero end users of proprietary tools who even have the option of patching security holes in the software upon which they depend.
So, while some may say "But any user can find/fix security holes when it's free software!" I'll simply say "But any user has the freedom to find/fix security holes when it's free software!" Whether or not the user has the skills is irrelevant, what's important is that the option is there.
Re:Open Source Vulnerable Too (Score:5, Informative)
A couple of important things mentioned though;
1) It must find /bin/sh to spawn a shell
2) It needs gcc to compile the source
Personally I always turn off anything on a production system that doesn't need to run. Also, hardening of the installation to make sure that as few amenities as possible are present for a potential intruder. A compiler is a good example of that. No need to have one on a production system.
Perhaps it is time to have vendors such as Red Hat and others consider using chroot() jails as much as possible, especially for Apache, BIND and other services known to be exploitable.
For those of you who are really serious about running Linux in a production environment and require security features such as compartmentalized shared memory, have a look at HP Linux [hp.com]. I think this is a derivative work of SE Linux, by the NSA.
What I haven't seen on the Symantec website though was exactly what the code does. The fact that it can spread is alarming, and the parent post has a good point that Linux users aren't immune. But what kind of access does this exploit allow? At most, it would be the user that Apache runs as, no? Does it try to further exploit local systems once it has made its way in or is it basically setting itself up to contribute to a DDoS attack?
This should serve as a wakeup call to Linux vendors, especially if they want to make headway in the desktop market. Linux distributions need to be more secure "out-of-the-box" than they currently are. Too much emphasis on trying to copy functionality from Windows and too little emphasis on what Linux is really good at.
no it's not (Score:4, Insightful)
The fact is that UNIX and Linux security is simply better than Microsoft's and that mechanisms for fixing problems, which do inevitably occur, are better and faster as well.
In fact, as far as I can tell, this particular problem is already fixed in recent packages, so you aren't vulnerable if you keep your machine up to date. Also, once a vulnerability is known, having the source, many people can and do fix it almost instantly.
Nice boiler-plate advisory (Score:3, Insightful)
...so? (Score:5, Insightful)
Besides which, the impact is a lot less than, say, Code Red which affected a much larger number of machines -- it hit all unpatched IIS servers versus unpatched SSL-enabled Apache servers.
Again, I ask, how is this news? What has changed that made this story worth reporting again [slashdot.org]?
Yeah, So...? (Score:5, Insightful)
Welcome to the world of mainstream.
0.9.6e is good (Score:5, Informative)
Contrary to the slashdot post, you only need to be up to 0.9.6e to be safe. If you happen to just now be upgrading past this bug, 0.9.6g is even better, but if you're already running "e" you are safe. The article kinda alarmed me at first when I saw the "g", thinking there was a new exploit in "e" and I needed to upgrade again.
some earlier are ok too -- vendors have backported (Score:5, Informative)
Also as mentioned by another poster, the netcraft report about the number of unpatched apache servers is complete nonsense. This is an openSSL bug, which has nothing to do with the apache version number, which what they measure and use to conclude people haven't updated.
(presumably older apache versions don't work with the newer openSSL libraries. Guess what... that's why the fixes were backported!)
RedHat 7.3 fix already in openssl-0.9.6b-24? (Score:4, Informative)
Linux is losing an important edge (Score:5, Insightful)
And that is where Linux is starting to lose its edge on Windows: the quality of the sysadmins. With the risk of being accused of making a crass generalisation, I'd say that many, many Windows sysadmins are of the point-and-click Mickey Mouse variety. Worse, not just the admins, but the infrastructure architects as well. After all, all you need to set up a domain is to complete one easy wizard, right? I have seen the result in all its ugly glory. Linux on the other hand required an admin who knows what he is doing, since there were no easy wizards. Much configuration was by editing files, with the how-to printouts in hand.
I say "required" in the past tense, since Linux is becoming easier and easier to set up. Some distros are close to the point where I'd be happy to give the CD to my mom and have her set up her own desktop. That is not a bad thing. Yet, I already have seen a few (very few, thankfully) "sysadmins" setting up Linux boxes for database or web services, without really knowing what they are doing. When we get to the point where managers themselves can set up Linux, they will be tempted to hire less and less qualified staff, as has already happened to a large degree with Windows NT.
My fear is that Linux servers will be run by less qualified people in the future, and that it will cause the proliferation of aggressive and effective Linux virii.
Re:Linux is losing an important edge (Score:5, Funny)
hackers? interested in linux?! no way!
Wrong Answer for Red Hat Linux (Score:5, Informative)
The correct solution is to run:
up2date -u
OR, if you don't use the free Red Hat Network., run:
rpm -Fvh ftp://updates.redhat.com/X.Y/en/os/i386/mod*
rpm -Fvh ftp://updates.redhat.com/X.Y/en/os/i386/apache*
Of course, replace X.Y with your version such as 7.0, 7.1, 7.2, 7.3, etc.
PEOPLE! Package management is GOOD. You should get and apply the updated packages from your vendor/distro. Slashdot editors/submitters should get a clue instead of recommend solutions that ultimately fsck stuff up.
Re:Wrong Answer for Red Hat Linux (Score:4, Informative)
Don't worry. Redhat has an irritating policy of backporting fixes into previously released versions of each package. Its the revision number that counts. Check the date on that file.
OT: Anyone care to elaborate on why apache 2.0.40 requires at least openssl 0.9.6e? I modified the configure script to accept 0.9.6c and it was happy enough...
I hate to say it (Score:5, Insightful)
I hope I never see another post stating that again, ok? Especially not a god damned +5 one.
What about... (Score:4, Interesting)
I realize the binary may not run on FreeBSD/OSX/etc., but the vulnerability itself is not Linux-specific, right? Could the virus be ported?
Sorry, I'd RTFA but it's slashdotted.
Competence closes this hole too... (Score:3, Insightful)
-jag
...and opens another one! (Score:5, Insightful)
Thank you, try again.
While are you are correct in saying that a limited subset of users should be permitted to run the compiler, that subset should never be the superuser. Compilers have security holes too, and gcc has been no exception. (was it 2.7 or 2.8? don't recall, too tired)
Never do your compiling as root.
How Do We Solve The Lazy Admin Problem? (Score:5, Insightful)
Unfortunately given human nature, we can't rely on sys admins and end users to patch their boxen. Almost every mechanism I can think of to automate this process either calls for automatically updating machines (which sucks if a patch breaks an untested scenario and also may need some legal exemptions) or some similar mechanisms to enable computers to help themselves [slashdot.org].
Any Slashdotters have any thoughts about this?
Re:How Do We Solve The Lazy Admin Problem? (Score:4, Insightful)
Security is about risk management. It's about process, procedure, and diligence. Security is not a technology problem, and it is not solved by geeks.
You can have a secure server farm running virtually any kind of software out there (including M$ products). How? By having a tight, auditable system. You carefully install the systems, documenting your procedure and following best practices (even if you develop them -- the important thing is to have a process). You maintain them on a schedule, leaving nothing to chance. You document the configuration thoroughly, and you enforce rigorous change control.
You might not even have OpenSSL upgraded even though it's vulnerable! You have to decide how much risk is acceptable and worthwhile, but the trick is to consciously and deliberately evaluate the risk, and decide how you're going to deal with it.
This applies to everything. You don't leave it up to your sysadmins to decide whether or not they should upgrade -- it's a part of a checklist that must be done, and can be independently verified at any time. It's part of a procedure that will allow new upgrades to be thoroughly tested and carefully rolled out to avoid downtimes due to unexpected incompatibilities between new and old versions. Imagine someone unwittingly upgrading apache from 1.3 to 2.0, without full testing on a major production system or even realizing that there may be configuration differences.... Nightmarish.
The only way to truly run a secure system is to realize that it has to be extremely carefully planned and managed. It's a hell of a lot of work, and it costs a lot of money. So it quickly becomes an exercise in traditional risk management. This is where the suits and the high-priced consultants often come in. You have to find out how much everything is worth, and what kind of risk you're willing to tolerate (or conversely, how much security you can afford given your environment). You will never be 100% mathematically inpenetrable, but you can reduce your risk to a level that you're comfortable with.
Obviously, this kind of thing scales. If you have a simple system, your plans and procedures can be fairly simple as well. As long as you have a solid verifiable plan, and you stick to it, you'll be fine. If you have a complicated system, your security management is going to be complicated as well.
Security Lists (Score:3, Insightful)
-Serp
Incidents.org just released an advisory as well... (Score:4, Informative)
Here is the alert [incidents.org]:
published: 2002-09-13
OpenSSL, the collection of libraries and programs used by many popular
programs, has had a number of security problems recently. It looks like
the problems are not over yet.
It has been discussed on several mailing lists, that aside from the
exploit known for openssl 0.9.6d, there are exploits available for
even the most recent version (0.9.6g).
As a precaution, we recommend to disable programs that use openssl as
much as possible. The exploits available so far focus on apache, which
is probably the most common exposed service that is using openssl.
As a precaution, we recommend disabling SSLv2, if you have to run an
Apache server with mod_ssl enabled. The magic configuration lines
are:
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!NULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:-L
One of the openssl apache exploits was found to install a DDOS agent
called 'bugtraq.c'. It uses port 2002 to communicate and can be used
to launch a variety of DDOS attacks. This program uses UDP packets on
port 2002 to communicate, not necessarily to attack.
-
cow's go muu~
What to look for in your logs (Score:5, Informative)
[27/Aug/2002 20:02:19 23525] [error] OpenSSL: error:1406B458:SSL routines:GET_CLIENT_ MASTER_KEY:key arg too long
[27/Aug/2002 20:02:22 24087] [error] OpenSSL: error:1406B458:SSL routines:GET_CLIENT_ MASTER_KEY:key arg too long
Thing is though, that "key arg too long" error is part of the July patch to OpenSSL, so you won't see it if you aren't patched. Hopefully this log signature doesn't become as familiar as nimda scans.
Nobody is Answering (Score:4, Insightful)
The submission states "A GNU/Linux worm" and "a bug in OpenSSL". But OpenSSL runs on a heck of a lot of systems that aren't Linux. Does this exploit only affect Linux systems running OpenSSL, or does it affect any system running OpenSSL?