lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <m1DEvlW-0024fjC@building.weird.com> Date: Fri, 25 Mar 2005 15:50:46 -0500 (EST) From: "Greg A. Woods" <woods-smail@...nix.com> To: sean <infamous41md@...pop.com> Cc: "BUGTRAQ: Full Disclosure Security Mailing List" <bugtraq@...urityFocus.com> Subject: Re: smail remote and local root holes (no, not really ;-) Sean you can't send me mail because hotpop.com is blacklisted: $ host -a hotpop.com.postmaster.rfc-ignorant.org hotpop.com.postmaster.rfc-ignorant.org A 127.0.0.3 hotpop.com.postmaster.rfc-ignorant.org TXT "Not supporting postmaster@...pop.com" You'll have to find a different mail domain to send from. All of my addresses will refuse all mail with a sender address @hotpop.com and I'm not going to whitelist a domain like that one. Your report was forwarded to me successfully though. (Thanks Bruce!) (I really should try to fix my BUGTRAQ subscription though.... or rather get securityfocus to properly fix their DNS so I don't have to bounce random messages from the list....) You have indeed found a really old heap buffer overflow (it is in code that's been there effectively unchanged since long before I took over maintenance). Don't worry though -- it's definitely not exploitable. It's just tripping one of smail's own self-defense mechanisms. If you fix your debugger (and/or recompile with -g) to give a proper backtrace you'll find that the failure comes in xfree(), and it's killing itself on purpose because it has detected your heap overflow attempt. (gdb) where #0 abort () at /work/woods/m-NetBSD-1.6/lib/libc/stdlib/abort.c:84 #1 0x136c4 in xfree (region=0x132c44 'A' <repeats 54 times>, "!A>") at alloc.c:153 #2 0x10960 in preparse_address_1 ( address=0x135c0f "A!@", 'A' <repeats 54 times>, ":A>", error=0xeffff0f8, rest=0xeffff0f4) at addr.c:235 #3 0x4087c in receive_smtp (in=0xe2778, out=0xe27d0, peer=0xeffff2b8) at smtprecv.c:787 #4 0x30498 in do_smtp (in=0xe2778, out=0xe27d0, peer=0xd6c00) at modes.c:2853 #5 0x2e48c in do_daemon_accept (ls=4, fd=6, from=0xeffff2b8) at modes.c:1725 #6 0x2ddd0 in daemon_mode () at modes.c:1524 #7 0x27290 in main (argc=3, argv=0xeffff500) at main.c:932 #8 0x1030c in ___start (argc=3, argv=0xeffff4fc, envp=0xd58e0, cleanup=0, obj=0x0, ps_strings=0xeffffff0) at /work/woods/m-NetBSD-1.6/lib/csu/sparc_elf/crt0.c:97 #9 0x10238 in _start () at /work/woods/m-NetBSD-1.6/lib/csu/sparc_elf/../common_elf/crtbegin.c:167 Also if you check your smail paniclog you'll find entries like: 2005/03/25 14:21:30: [3521] X_CHECK failed! ptr=0x8153c84, line=153, file=alloc.c 2005/03/25 14:21:30: [27057] smtpd PID 3521 killed by signal SIGABRT and dumped core: Abort trap Since the call to xfree() comes so soon after the buffer is overflowed, there's no chance to even try an exploit. The best you can do is kill your own connection, leaving lots of evidence about your attempt and where you connected from, including enough info to find and fix the bug. ;-) BTW, why do you go to so much trouble to write a bug exerciser in C though? A little text file fed to "nc localhost 25" is all you need in this case, for example: HELO localhost MAIL FROM:<A!@...BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB:C> (and with the right version of "nc" you can use '-i 10' or similar to give yourself time to attach the debugger to the server process before the second line of text is sent to the sever) Your proposed fix isn't quite right, but it's very close. Thanks! (exercising that old code also revealed a logic bug in it too! :-) (you'll find my exact changes in the next release.... due soon :-) However your analysis of the signal handler missed one very critical point: That signal handler never returns, and so making use of any possible malloc(), etc., reentry bug is going to be damn near impossible. Further the write_log() call may not even call malloc() or realloc() since the storage it allocates reused in subsequent calls, so you would have to be very lucky to manage to interrupt some other early malloc() call that happens before all other write_log() calls, and do so in such a way that a subsequent call to malloc() via write_log() could ever do any damage, and you would probably have to use a stack overflow right then and there in malloc() because otherwise there won't be any other chance before the exit() call that happens immediately upon return from write_log(). I don't think any modern implementations of malloc() are even potentially vulnerable to stack buffer overflows due to reentrant calls in the first place either. If you do ever manage to even get a core dump though let me know where, how, and on what platform! :-) (but please be sure to always compile with '-g' so the backtrace is useful) -- Greg A. Woods H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@...ohack.ca> Planix, Inc. <woods@...nix.com> Secrets of the Weird <woods@...rd.com>
Powered by blists - more mailing lists