OpenSSH 3.4 has been released with a fix for a serious vulnerability in the challenge-response authentication code. CVE-2002-0639. The patch is available; the impact is substantial.
What the bug is
A buffer overflow in OpenSSH's BSD-style challenge-response handler. Specifically, the code that processes the response to a challenge does not properly validate the response length. A malformed response can overflow a buffer in the handler.
The vulnerability is exploitable before authentication completes — the attacker does not need valid credentials. The attack reaches the privileged sshd parent process; on systems without privilege separation, this is full root.
What is at stake
Three things.
Most internet-facing SSH deployments are vulnerable. Default OpenSSH configurations enable challenge-response. The vulnerability affects 2.x versions and most 3.x versions.
Public exploit code is presumably imminent. The advisory describes the bug in enough detail that researchers can develop exploits within hours.
The attack surface is enormous. SSH is the management protocol for essentially every Unix server. A wave of exploitation could compromise a substantial fraction of the internet's infrastructure.
What operators should do
Patch immediately. OpenSSH 3.4 is available now. Build, install, restart sshd on every host.
Where patching is delayed, the workaround is to disable challenge-response: set ChallengeResponseAuthentication no in sshd_config. This eliminates the vulnerable code path. The trade-off: SSH cannot authenticate via challenge-response (S/Key, OPIE, BSD authentication). Most deployments do not actively use these; the trade-off is favourable.
Privilege separation matters. Hosts running OpenSSH 3.x with privilege separation enabled have reduced exposure — exploitation gives the attacker access as the unprivileged sshd user, not as root. The privilege-separation discipline I wrote about last year pays back here.
What I have done
For my own infrastructure: patches applied within hours of the advisory. The discipline of fast patching for security-critical infrastructure continues. Privilege separation has been enabled across all my hosts since 3.0; the limit on exposure is meaningful.
For friends running SSH: a note with the advisory link and the patching urgency. Most have already received the OpenSSH announcement; the follow-up is cheap.
For my Snort sensor: a rule for the specific overflow patterns. The rule will catch exploitation attempts before they succeed against any unpatched hosts in my range.
A small reflection
The vulnerability is in code I read carefully two years ago. I had assessed the codebase as well-engineered; the assessment continues to hold; this specific bug is the kind of subtle issue that careful code can still contain. The structural defences (privilege separation, prompt patching, IDS rules) are what bound the impact.
For anyone who thinks well-engineered code is bug-free: this is a useful counter-example. Even good code has bugs. The structural defences matter.
More as the situation develops.