full-disclosure - Re: screen 4.0.3 local Authentication Bypass

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <ED2845AF-FC05-4EF2-8844-3FF181691BC0@beskerming.com>
Date: Tue, 5 Jun 2007 12:12:01 +0930
From: Sûnnet Beskerming <info@...kerming.com>
To: rembrandt@...erlin.de,
 a.klink@...ops.de
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: screen 4.0.3 local Authentication Bypass

Hi,

I have experienced the same issue as Alex in not being able to  
replicate the issue on screen 4.00.03 (OS X 10.4.9).  Have you  
perhaps modified tset or some other basic setting?  What shell are  
you starting from?  I tested using the default settings as per OS X  
10.4.9 (bash, screen 4.00.03), with no modification to any system  
settings ('sudo screen' didn't allow the bypass, either).

While I could not replicate the bypass, I did find that screen will  
accept commands as valid passwords (i.e. ^a+x ^a+x ^a+x, then ^a+x to  
unlock).  Perhaps you used ^a+c or ^c when entering the password and  
screen happily accepted it as a password (which it will).  From  
testing your exploit and fiddling around with various other options,  
it appears that once the screen is locked with screen 4.00.03, it  
will send any input to the password input, even if it is a command  
keystroke.  Even copying the password into the buffer (all variations  
of the buffer), locking the screen and then pasting the buffer back  
to stdin didn't work - it regarded the paste command as the actual  
password.

Having said all that, reading through the source for the relevant  
section of screen (attacher.c), it appears that if you actually are  
experiencing an authentication bypass, then it is likely that you  
have linked against a PAM library (or even BSD Authentication) that  
might have gone a little haywire.  Since the non-PAM screen lock code  
relies just on crypt and getpass (and salts the input before passing  
it to crypt), I doubt it is this part of the code that is at risk.

Perhaps one of the screen devs might be able to pitch in.

Carl

Sûnnet Beskerming Pty. Ltd.
Adelaide, Australia
http://www.beskerming.com

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