A Rash of Vulnerabilities Come to Light

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


[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


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

What’s wrong? The new clean desk test
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies