Slashdot Mirror
Linux Worm Spreading, Many Systems Vulnerable
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."
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.
11*43+456^2
Just as vulnerable, perhaps. However, with open source software one has the ability to go in and fix the problem rather than waiting for some vendor to do it for you. That's where the power lies -- often, when a vulnerability is discovered, a report is sent out including exploit code and a patch to correct the issue.
That's what makes open source software overall more secure -- the turnaround time with patches is a lot faster.
Buffer overflow exploits (which could then be used to open a shell) involve executable machine code, which would be for a specific instruction set (e.g. Intel's).
Well, I tried to be a good citizen. They must be getting hammered.
I tried every decent and legal way I could think of to resolve the issue w/the business before I rented the chicken suit
According to the Symantec report cited in the story, the bug in openssl is this which is reported as RHSA-2002-155, for which the the fix is openssl-0.9.6b-24.i386.rpm for RedHat 7.3 i386 (plus some other RPMs for other versions, or other RPMS for other versions of RedHat). Maybe the 'g' build from openssh.org is necessary, but RedHat seems to think they've already fixed in in their "b-24" release.
If you follow the stoopid /. suggestion, and compile/install the new OpenSSL you are going to leave RPM nirvana and enter "random untracked apps linked against random untracked libraries" hell.
r pm -Fvh ftp://updates.redhat.com/X.Y/en/os/i386/openssl*
rpm -Fvh ftp://updates.redhat.com/X.Y/en/os/i686/openssl*
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.
the worm ONLY affects SSL-enabled Apache servers, not your run of the mill (non mod_ssl) servers.
Seems a bit more detailed.
O W:+SSLv3:+TLSv1:-SSLv2:+EXP:+eNULL
//cow
Here is the alert:
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~
In fact, Microsoft has already pre-infected their own new OS, Windows XP. Maybe those draconian EULAs (you hereby agree that "M$ 0wnz j00") aren't such a dumb idea after all...
Not that I like it, but the fact is that MS is targeting the sort of people we're worrying about, giving them what it thinks they need, whether they ask for it or want it, or not. We hate this because we're tech-savvy and want to control our machines, but for the average user, having someone else "0wn" their machine is probably, ultimately, a necessity. The question is just who's going to do the owning - virus writers and crackers, or Microsoft/Symantec etc.
Actually, the stacks are usually pretty similar. (On most Linux boxes, stacks grow towards lower addresses, except on Alpha, IIRC. Heaps depend on the libc implementation, not the CPU.) As a result, the structure of a buffer flow vulnerability doesn't change much from machine to machine.
The big difference that keeps this 'sploit tied to x86 is the instruction set. You can't run x86 instructions on other CPUs by default. (Ignoring FX!86 on Alpha, since it's not likely to step up to bat on your shellcode anyway.)
--JoeProgram Intellivision!
as root type openssl version
"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...
Sometimes the best solution to morale problems is just to fire all the unhappy people.
[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.
Look my firewall blocks EVERY port that hasn't been deemed necessary. Its a server so I don't need gcc
Just offering a quick band-aid to get through the weekend.
Thanks for the advice though. Really.
OpenSSL 0.9.6e is perfectly safe. And that was available via Software Update on 30 Jul 2002.
Andreas
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!)
It's an OpenSSL bug. This worm happens to use Apache and mod_ssl to get to OpenSSL in order to exploit OpenSSL, and it happens to use shellcode that only works on Linux on x86 platforms.
If your server is not listening to 443 (HTTPS by nature) then there is obviously no point of configuring your firewall to block this.
Or rather, if you're server isn't listening on port 443 there's no point in opening this port up in your firewall. Default deny people. Default deny. Portmap may not be vulnerable today but someone may discover a bug in it at 3am tomorrow while you're happily sleeping in bed and use it to exploit your box. Just block everything and open up only the services you need. And of those servers, think about if you really need them open or not and if you could be using a more secure program to do the same thing.. perhaps DJB's tools like publicfile and djbdns for example to replace these huge monolithic apps for a simple home box with a couple dozen web pages.
In my ssl error log:
[Fri Sep 13 03:24:07 2002] [error] mod_ssl: SSL handshake failed (server obscured:443, client obscured2) (OpenSSL library error follows)
[Fri Sep 13 03:24:07 2002] [error] OpenSSL: error:1406B458:lib(20):func(107):reason(1112)
A little bit before that, in my http log:
162.33.137.47 - - [13/Sep/2002:03:23:58 -0700] "GET / HTTP/1.1" 400 383 "-" "-"
This is consistent with the alert: first an HTTP request to get the server signature, then an HTTPS attempt to exploit.
Mod parent down. Just because Mr Baker is too lazy or ignorant to find this: http://enterprisesecurity.symantec.com/products/pr oducts.cfm?productID=65
hardly seems to mean his post is in the least insightful.
Score:-1, Funny