full-disclosure - Re: OpenSSH 3.5p1 Remote Root Exploit for FreeBSD

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20110706175353.GA2497@localhost>
Date: Wed, 6 Jul 2011 19:53:55 +0200
From: Markus Friedl <mfriedl@...il.com>
To: Dag-Erling Smørgrav <des@....no>
Cc: full-disclosure@...ts.grok.org.uk, markus@...nbsd.org
Subject: Re: OpenSSH 3.5p1 Remote Root Exploit for FreeBSD

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 - des@....no

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/