[4014] in Release_7.7_team
Today's OpenSSH "vulnerability"
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Sep 16 16:21:35 2003
Date: Tue, 16 Sep 2003 16:21:31 -0400
Message-Id: <200309162021.h8GKLVxo028463@error-messages.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
CC: jis@MIT.EDU, tom@MIT.EDU
Today the OpenSSH team released a new version of openssh as well as a
patch to buffer_append_space() in buffer.c. The interesting part of
the patch reads:
- buffer->alloc += len + 32768;
- if (buffer->alloc > 0xa00000)
+
+ newlen = buffer->alloc + len + 32768;
+ if (newlen > 0xa00000)
fatal("buffer_append_space: alloc %u not supported",
- buffer->alloc);
- buffer->buf = xrealloc(buffer->buf, buffer->alloc);
+ newlen);
+ buffer->buf = xrealloc(buffer->buf, newlen);
+ buffer->alloc = newlen;
In the old code, buffer->alloc was adjusted before the larger amount
of memory was allocated. That wouldn't be a problem in and of itself,
except that in some cases cleanup handlers invoked by fatal() can
result in the freeing of the buffer being appended to, and
buffer_free() does:
memset(buffer->buf, 0, buffer->alloc);
which will write zeros to memory beyond the end of buffer->buf.
Is this problem exploitable? The OpenSSH team said, "It is uncertain
whether this error is potentially exploitable"; the FreeBSD team said,
"The bug is not believed to be exploitable for code execution on
FreeBSD." I personally have serious doubts that this problem is
exploitable. "Smash the heap with zeros" bugs can occasionally result
in vulnerabilities (e.g. by zeroing out a uid or a password field used
by later code), but the raw material for an attack here doesn't seem
very generous. The cleanup handlers run by fatal() don't talk over
the wire or make decisions about granting access.
Confusing the matter, slashdot went ahead and reported that there is
an exploit in the wild, based on a vague post to full-disclosure:
http://lists.netsys.com/pipermail/full-disclosure/2003-September/010116.html
Nothing ties this mail thread to the bug fixed in OpenSSH 3.7, and the
phrasing "attempts various offsets" sounds to me like an exploit for
an earlier integer overflow vulnerability.
Based on all this information, I don't think we need to put out an
emergency patch release. I have incorporated the fix into the
forthcoming 9.2.17 patch release, which would naturally go to field on
Monday September 22 given our normal testing schedule.
