no need to call pam dogshit :). the bug is neither in auth2-pam-freebsd.c nor libpam. it's last years libopie bug (CVE-2010-1938).
http://twitter.com/msfriedl/status/87114829789278208 and follow ups. -m On Wed, Jul 06, 2011 at 11:54:29AM +0200, Dag-Erling Smørgrav wrote: > There is absolutely no way the bug is in auth2-pam-freebsd.c. It is > clearly a stack smash, and auth2-pam-freebsd.c never inspects, modifies > or stores the user name, or handle it in any way except: > > - receive a pointer to it from openssh and pass it on to pam_start(). > > - receive a pointer to it from libpam and pass it on to setproctitle() > or debug() with appropriate format strings. > > The buffer overflow is either somewhere downstream of pam_start() or in > a module. Running sshd with -d should tell you which; if it's in > pam_start(), the last message you'll see is "PAM: initializing for > $user". If you see anything after that (the next message should be > "PAM: setting PAM_RHOST to $rhost"), it's in a module. > > You can also comment out the entire contents of /etc/pam.d/sshd and add > the following at the bottom: > > auth required pam_permit.so > account required pam_permit.so > session required pam_permit.so > password required pam_permit.so > > Then run the exploit. If it still works, the bug is in libpam; if it > doesn't, it's in a module. You can figure out which module by > uncommenting lines, one by one, until the exploit starts working again. > > BTW, libpam in 4.11 is not "the FreeBSD pam library itself", it's > Linux-PAM, which is--or at least was, at the time--a pile of dogshit. > FreeBSD didn't get its own PAM library (OpenPAM) until 5.0. > > DES > -- > Dag-Erling Sm?rgrav - [email protected] _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
