lshd buffer overrun. Possibly remote root compromise.

[Niels Möller]

Summary:

         PLEASE DISABLE LSHD SERVICE. Apply below patch.

Simon Josefsson <jas@extundo.com> writes:

> FWIW, I can reproduce it:
> 
> lshd: write_buffer: do_write length = 256
> lshd: write_buffer: do_write closure->length = 293
> lshd: garbage collecting...
> lshd: gc_mark: Memory corrupted!
> Aborted
> 
> I think it has nothing to do with the actual bits sent, but rather
> that some earlier random data caused the code to take a rarely tested
> execution path, which has garbage collect bugs in it, which is
> discovered a while later.

I'm afraid it's worse than that. It seems to be a genuine buffer
overrun, on the heap. It's the buffer in read_line.c,

/* GABA:
   (class
     (name read_line)
     (super read_handler)
     (vars
       (handler object line_handler)
       (e object exception_handler)

       ; Line buffer
       (pos . uint32_t)
       (buffer array uint8_t MAX_LINE)))
*/

The below patch should fix the bug. It's a case of checking for an
error, reporting it, and then forgetting to return from the function.
Instead the code just went on overwriting the buffer. Pretty
embarrassing.

diff -u -a -r1.31 read_line.c
--- src/read_line.c	16 Feb 2003 21:30:11 -0000	1.31
+++ src/read_line.c	18 Sep 2003 20:02:48 -0000
@@ -100,6 +100,7 @@
       /* Too long line */
       EXCEPTION_RAISE(self->e,
 		      make_protocol_exception(0, "Line too long."));
+      return available;
     }

   /* Ok, now we have a line. Copy it into the buffer. */

The buggy code was checked in a little more than four years ago,
1999-08-22, at about this time of day.

I'm *not* going to bet that it isn't exploitable. I'll try to get new
releases out within a few days, until then, I recommend that you apply
the above patch to lshd and recompile, or disable lshd service.

Thanks to Bennett Todd for reporting the problem.

Sorry about the trouble. Regards,
/Niels