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.

Re:Open Source Vulnerable Too

[delta407]

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.

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.

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

[Wdomburg]

> Maybe the 'g' build from openssh.org is
> necessary, but RedHat seems to think they've
> already fixed in in their "b-24" release

Red Hat typically backports security fixes from later releases to the version they shipped with the distribution release to avoid introducing unrelated changes.

Note that RHSA-2002-155 is now superceded by RHSA-2002-160, which additionally addresses CAN-2002-0659.

Matt

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

Re:Wrong Answer for Red Hat Linux

[devnullkac]

Well, I've been keeping my RedHat 7.3 up2date and I got hit. I didn't know it until I read this post, but last night TicketMaster Brasil (of all places) pinged my server one minute before the characteristic /tmp/.uubugtraq file appeared. The only thing that saved me was that the link phase of the worm compilation failed due to missing libraries (specifically, RC4 and MD5).

I agree that package management is good, but it looks like RedHat is running behind on this one. I'll be closing down the SSL port on my firewall for now :-(

Although I never saw it actually operating, you can probably clear the worm from your system via the following command (though you'll have to take measures to ensure it doesn't come right back):

killall -9 .bugtraq

The worm itself is nicely commented; it even has a disclaimer that the author isn't responsible for any harm:

Peer-to-peer UDP Distributed Denial of Service (PUD)
by contem@efnet

<snip>

I am not responsible for any harm caused by this program!
I made this program to demonstrate peer-to-peer communication and
should not be used in real life. It is an education program that
should never even be ran at all, nor used in any way, shape or
form. It is not the authors fault if it was used for any purposes
other than educational.

Doubt the disclaimer will keep him out of jail for life, though

Re:Wrong Answer for Red Hat Linux

[ajs]

Redhat has an irritating policy of backporting fixes into previously released versions of each package.

Debian and FreeBSD among many others do the same thing.

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~

Re:only Intel systems?

[Mr Z]

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

--Joe

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

Re:Nice boiler-plate advisory

[sheriff_p]

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.