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/
Received on Jun 04 2007
Intro
