Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with gdb not catching breakpoints in shared .dynlib

On Nov 3, 2004, at 11:51 PM, Greg Earle wrote:

Eric Albert wrote:
On Nov 3, 2004, at 10:04 PM, Greg Earle wrote:
(I had to remove the "-O2" from CFLAGS to prevent a crash.)
I couldn't reproduce that crash. Are you just running it as './sshblaster2 sship.txt'?

Yep. When "-O2" is in CFLAGS, it dies in strlen():

It still doesn't crash for me. Oh, wait, yes it does if I re-enable the fork and use 127.0.0.1. More on that below.

Breakpoint 1, string_from_char (what=0x682d7573 <Address 0x682d7573 out of bounds>) at string.c:41

0x682d7573 is "h-us", which only shows up in the code in the "ssh-userauth" string in ask_userauth in auth.c. Sounds like something's smashing the stack. (Random tip: Whenever you crash with a bad address, see if it looks like ASCII. If it does, you're probably crashing somewhere vaguely near where you referenced a string with those characters.)

Yep. Mac OS X's OpenSSL build appears to have AES support, so we use a blocksize of 16 in packet_read() in packet.c. That causes completeread() to overflow the 8-character buffer variable from packet_read. Change packet_read's buffer[8] to buffer[16] and things are much happier.

Great, thanks.  I can comment out the fork() and it still runs - and,
most importantly, now I can get gdb to stop at the breakpoint (but it
also still crashes, after the 3rd successful cycle through):

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x3a002270 in ssh_cleanup (session=0x1802200) at client.c:211
211 printf("session->client_kex.methods[%d] == %s\n", i, session->client_kex.methods[i]);
(gdb) print *session
$2 = {
[...]
client_kex = {
cookie = '\0' <repeats 15 times>,
methods = 0x0
},

Not sure why methods[0] is a NULL pointer instead of the expected
string "diffie-hellman-group1-sha1" (especially since the two
string arrays, "default_methods" and "supported_methods", are both
properly NULL-terminated), but that's a battle for another day.  :)

This might be an aftereffect of the aforementioned stack smash; I'm not sure. I should note, though, that the problem isn't that methods[0] is NULL; rather, methods itself is NULL, so when you try to reference methods[0] you dereference NULL and crash.

(Also, I don't see any such line in the copy of the source code you pointed to. I'm not sure what you're running.)

(What's weird is that this same code must surely run fine
on Linux, seeing as how we're seeing an average of 1-3 of these
Script Kiddie SSH brute-force scans/attacks a day around here.)

Either their systems don't have openssl/aes.h or they're lucky and an 8-byte stack smash doesn't actually crash on their systems. The latter is entirely possible, since different architectures and operating systems lay out the stack differently. That doesn't make the broken code right, of course. :)

-Eric

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Unix-porting mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/unix-porting/email@hidden

This email sent to email@hidden
References: 
 >Problems with gdb not catching breakpoints in shared .dynlib (From: Greg Earle <email@hidden>)
 >Re: Problems with gdb not catching breakpoints in shared .dynlib (From: Eric Albert <email@hidden>)
 >Re: Problems with gdb not catching breakpoints in shared .dynlib (From: Greg Earle <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.