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."

Comments

0.9.6e is good

[photon317]

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.

Wrong Answer for Red Hat Linux

[Anonymous Coward]

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.

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*
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*

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.

Maybe the stats aren't as bad as they think...

[orius_khan]

"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...

What to look for in your logs

[GT_Alias]

I noticed some strange stuff a week or two ago in my Apache logs, watch out for this stuff in your ssl_engine_log file:

[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.

some earlier are ok too -- vendors have backported

[Xylantiel]

In Debian, at least, the fixes were backported to 0.9.6c. Updated packages fixing this problem were released almost a month an a half ago for all major distributions. (July 30 for Debian., packages numbered 0.9.6c-2.woody.0)

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!)