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.

RedHat 7.3 fix already in openssl-0.9.6b-24?

[leighklotz]

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.

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.

Re:Wrong Answer for Red Hat Linux

[yem]

Retrieving ftp://updates.redhat.com/7.3/en/os/i386/openssl-0. 9.6b-28.i386.rpm

So RedHat doesn't have the latest version on the ftp site?

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

Incidents.org just released an advisory as well...

[McCow]

Seems a bit more detailed.

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:-LO W:+SSLv3:+TLSv1:-SSLv2:+EXP:+eNULL

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
cow's go muu~

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