[Sorry for the delay in following up, I had to dash off to New Mexico
on short notice.]
On Nov 4, 2004, at 1:09 AM, Eric Albert <email@hidden> wrote:
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.
(I never saw any "More on that below" about this strlen() crash :-) )
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.
I made that change, but it had no effect - it still crashes at:
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.)
I just stuck a printf() in there just to see what the values were
when it hit the "breakpoint". (Why? If I try running it in GDB and
have it spit out the same when it hits that line, sooner or later
GDB stops and says it got a SIGALRM. I tried commenting out the
"alarm(10);" at line 102 of "sshblaster2.c" and it still SIGALRM's.
And when I try doing "catch signal SIGALRM" in GDB it says that
isn't implemented yet. Oh, and while I'm ranting, it would be
really cool if Xcode 2.0 implemented a high-level GUI interface to
some of the low-level breakpoint and tracepoint stuff in GDB,
since Xcode 1.5 doesn't ... )
At this point I'm stumped, it basically runs through 5 loops and
then croaks at the start of the 6th:
At this point I can only assume that something's stomping over
the memory where the client_kex part of the SSH_SESSION array
is stored. But I guess at this point it's no longer a UNIX
porting issue ...
- Greg
_______________________________________________
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
