Summary: A rash of recent vulnerabilities has caused a minor uproar regarding the method and timeliness of their disclosure, but it also provided vendors an opportunity to showcase their firefighting abilities.

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.

Bri Hatch is Chief Hacker at Onsight, Inc., and author of Hacking Linux Exposed and Building Linux VPNs. His hatred for BIND goes back just as long as his hatred of Sendmail, and he has the psychological scars to prove it. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2002.

This article was first published here in ITworld.com Inc., 118 Turnpike Rd., Southborough, MA 01772  on 09-Jul-2002.