A Rash of Vulnerabilities Come to Light

by Brian Hatch

July 8, 2002 —

Recently, a number of pretty devastating security problems have been
discovered. First, a bug in Apache was discovered that allows a remote
attacker to run code of their choice as the Web server user. This means
that, depending what you are running Apache as, the cracker could get on
as 'web', 'www-data', 'nobody', etc....

Depending on whom you ask, this vulnerability is not exploitable on
Linux, only BSD and Windows. However, GOBBLES, the security group that
proved it was exploitable on BSD (while others claimed it wasn't), hints
that they have a Linux-specific exploit as well. Upgrading to Apache
1.2.26 or 2.0.39 will solve this problem.

Next, we had a hole in OpenSSH that, under certain conditions, can leave
you vulnerable to a root compromise. You are only vulnerable if running
versions prior to 3.4 and have one or both of the following in your
/etc/ssh/sshd_config file:

ChallengeResponseAuthentication yes
PAMAuthenticationViaKbdInt yes

Upgrading to OpenSSH 3.4 will fix this bug. The new version not only
fixes those bugs, but also enables Privilige Separation by default. This
new feature runs as much of the server as possible as a dummy user
(sshd), thus any vulnerabilities that are found should grant access to
the system as the sshd user in a chroot'ed jail at worst. This is good.

Both of these vulnerabilities were discovered[1] by Internet Security
Systems (ISS). Unfortunately, ISS released details about the Apache bug
with no honest attempt to provide the Apache team a chance to fix it.
Worse yet, the patch that ISS supplied did not fix the problem. ISS
contacted the OpenSSH team, who decided to fix up[2] the Privilige
Separation code, but ISS unfortunately decided, again, that the
limelight was more important than giving vendors the appropriate time to
fix the problem. ISS released their findings five days before OpenSSH
had scheduled the updated code's release. OpenSSH released the fix
minutes thereafter, but the extra time to get PrivSep working across the
board was lost.

In spite of ISS's irresponsible disclosure[3], both OpenSSH and Apache
had fixes out as fast as lightening. Linux distributions were close
behind, making RPMs and .debs available for users to upgrade.

As we speak, at least one Apache worm is on the loose, attacking Apache
Web servers that have not been upgraded. That this worm is barely making
a dent is a testament both to the speed of the Apache team and the
security-minded nature of Unix administrators. I've always said, Unix is
more securable than Windows.[4]

The last vulnerability that's recently reared its ugly head is in DNS
resolver libraries. In this case, a malicious DNS server out on the
Internet could send you an invalid DNS response that will crash or
compromise your software. The good news is that the Linux resolver is
not vulnerable; the bad news is that BIND, the default DNS server for
most Linux distributions, is vulnerable[5] -- rather, BIND4 and BIND8
are vulnerable, BIND9 is not.

The suggested fix for this has been to have all your machines query a
BIND9 host until you can upgrade your resolver software and the
BIND4/BIND8 hosts. This would seem to be a good idea, but it's still not
sufficient. DNS responses are trivial to fabricate -- DNS uses UDP, so
you only need to send a malicious DNS packet that arrives before the
authentic DNS packet. For the more paranoid, the best bet would be to
run a DNS resolver that discards malicious packets on each of your hosts
and query it instead of any server on the network. (You'd point to
127.0.0.1 in /etc/resolv.conf.)

However, the latest BIND vulnerabilities offer me an excuse to show
everyone how to install DJBDNS, an alternate DNS suite written by the
illustrious Dan Berstein[6]. So for next week, sit back as I show you
how you can ditch BIND and move to a package that, to date, has zero
vulnerabilities and a bounty for anyone who is able to find one.[7]

NOTES

[1] 'Discovered' may be a bit of a stretch, since others were also aware
of the Apache bug and were already working on a fix for it.

[2] The Privilege Separation code for OpenSSH worked well on BSD, but
had some issues on other common OSs such as Linux and Solaris. The
OpenSSH team decided to disclose that there was a vulnerability in
the software without disclosing the actual problem, and get
community involvement to get Privilege Separation fully functional
on all OSs. They set a one-week timetable before they'd release the
next version with functional PrivSep code and the bugfix itself.

[3] For an excellent article on ISS' inappropriate handling of the
Apache vulnerability, see Jon Lasser's SecurityFocus column at
http://online.securityfocus.com/columnists/91

[4] http://www.hackinglinuxexposed.com/about/linux_is_securable.html

[5] That BIND has yet another vulnerability should not surprise anyone.

[6] It should be noted that DJBDNS includes a client library as well,
and it's not vulnerable to the bugs recently discovered.

[7] I'll be performing this upgrade in real time on a friend's system.
We'll see if he notices.

ITworld