root ssh exploit
2003-09-16 18:15:48.009624+00 by
Dan Lyke
13 comments
Okay, Un*x kiddies, there's an OpenSSH buffer overflow bug [Edit: root exploit in the wild /. was apparently wrong, there's not an exploit out there, just an overflow that might lead to denial of service issues if pushed]. Debian "stable" users should make sure that they have a:
deb http://security.debian.org/ stable/updates main contrib
non-free
line in their /etc/apt/sources.list, and run "apt-get update ; apt-get upgrade" immediately. All other users should take the appropriate steps. Don't let this turn into a Microsoft style situation.
[ related topics:
Free Software moron security
]
comments in ascending chronological order (reverse):
#Comment Re: root ssh exploit made: 2003-09-16 21:27:43.395476+00 by:
Dan Lyke
It seems like there's some ssh filtering going on out there in the world. This does not bode well.
#Comment Re: root ssh exploit made: 2003-09-16 21:38:20.787348+00 by:
Dan Lyke
From a reliable source:
> ---------- Forwarded message ----------
> Date: Tue, 16 Sep 2003 16:21:31 -0400
> Subject: Today's OpenSSH "vulnerability"
>
> 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/piperm...osure/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.
#Comment Re: root ssh exploit made: 2003-09-16 22:26:01.774373+00 by:
meuon
In english for the rest of the world from ISS.. who arguably discovered it but had not yet released this to the public: http://xforce.iss.net/xforce/alerts/id/144
#Comment Re: root ssh exploit made: 2003-09-16 22:55:05.914797+00 by:
ebradway
Hmmmm... Sounds like weapons of mass destruction to me...
Does any flavor of Unix allow processes to write outside of their own space? Maybe I'm just being overly hopeful. But this bug, on rare occasions, simply clears out too much memory when an SSHD session suffers a fatal failure. You can't control what it writes to the additional memory space, so it can't be used to fill memory with some malignant code and trick the system into running it. It's also positioned deep enough into the call stack of SSHD so that it wouldn't overwrite any permission flags.
Compared to the Microsoft RPC flaws, this is peanuts.
#Comment Re: root ssh exploit made: 2003-09-16 23:17:03.964349+00 by:
Dan Lyke
The issue is that sshd runs as root, hopefully changes users to something else, and spawns processes. So the fear is that you could get it to not change user (or change user to uid 0, ie: root) and spawn a process, preferably a shell.
Something too to put thought into when overwriting memory (which it does to make sure that subsequent processes don't get interesting security related data). And it's amazing what exploits people have come up with.
P#3/\r T3h (0113g3 |<!d5 w/+00 mu(# +!m3 0|\| +#3!r h@|\|dz.
#Comment Re: root ssh exploit made: 2003-09-16 23:55:50.672575+00 by:
meuon
[edit history]
English please.. That one is hurting my head trying to phigure it out.
"..?..?.. kids with too much time on their hands"?
#Comment Re: root ssh exploit made: 2003-09-17 00:18:39.064105+00 by:
topspin
Fear the college kids with too much time on their hands, I think. Oddly, THAT is easier for me to read than the alloc code above it. Sigh....
#Comment Re: root ssh exploit made: 2003-09-17 17:40:16.313825+00 by:
Mark A. Hershberger
Dan,
Have you seen evidence of this bug being exploited? I just read the ISS advisory (I read bugtraq and full-disclosure last night) and this looks pretty un-exploitable. Perhaps a DoS, but no root compromise.
Anyway, 'apt-get update && apt-get install ssh' did the trick for me on my boxes.
#Comment Re: root ssh exploit made: 2003-09-17 17:51:03.220198+00 by:
Dan Lyke
Mark, no I haven't seen evidence of an exploit, whence my edit to the main entry. If there was or is a new exploit for something floating around right now (This morning's weblog reading suggests at least one of Meuon's boxes got 0wN3d last night), I suspect the OpenSSH flaw is a red herring.
However, I do withdraw my chiding Meuon on paranoia when he blocked port 22 yesterday, although I had a few moments of "oh crap" when I had my existing SSH session up and couldn't get back into my colo server with SSH and couldn't figure out how it was configured differently than my other net exposed system.
#Comment Re: root ssh exploit made: 2003-09-17 18:16:09.253843+00 by:
Mark A. Hershberger
O... Just commented after reading the new comments ... didn't re-read the top.
In any case, I manage a couple of boxes where ssh is only allowed from known IPs, so that's not too strange. Every little bit of paranoia gets you one step ahead of the competition.
#Comment Re: root ssh exploit made: 2003-09-17 18:50:06.598689+00 by:
Dan Lyke
In related news: Fudge. Maybe this is my cue to move to Exim on the colo machine. /. reports a Sendmail hole.
All of my known fears on my colo box come from a few favors I'm doing folks, in watching the security updates install I'm going to have to seriously reconsider a few of them.
#Comment Re: root ssh exploit made: 2003-09-19 03:21:45.187342+00 by:
ebradway
I gave up on Sendmail years ago. Right now, I'm using Courier+Qmail. My new server (in construction) will be pure Courier.
A question for those a little more system savvy:
Linux doesn't yet isolate data and executable memory, correct? But BSD does?
My new system is planned to be based on Debian (woody), but I may just do it as BSD if this is the case.
Also, does BSD support SMP yet? I plan to put my second 400Mhz Celeron in the server when I do the upgrade (yeah, I even a dual 400Mhz celeron is glacial by today's standard - but for my purposes, it's still a kickin' server).
I'll go research these questions myself - just interesting stuff to ponder as we deal with code errors like this...
#Comment Re: root ssh exploit made: 2003-09-20 18:29:17.422257+00 by:
Mark A. Hershberger
Patch for non-executable stack on Linux: http://www.openwall.com/linux/
Defeating the patch: http://www.insecure.org/sploit...n-executable.stack.problems.html
More on why the Non-executable stack patch for Linux is not in the kernel: http://old.lwn.net/1999/1230/security.phtml
PaX: http://www.grsecurity.net/