Hi,
What you've done below is actually sent a SIGINT (^c) at the start of
the screen lock process, and not actually locked the screen. In
order to get the 'Getpass error' (which is what the original report
alerted on), then you pass through both rounds of key acceptance, but
fail prior to actual locking of the screen. It will then sleep(2)
with the 'Getpass error' before returning to the original prompt.
NOTE - screen was never locked at this point.
The normal method of operation:
~user(bash) $screen
(press enter to ack info)
~user(screen) $^a+x
Key: <-- Enter a password
Again: <-- Re-enter
Screen used by User <user>.
Password: <-- Same password as above
~user(screen) $exit
~user(bash) $
If you send the SIGINT at the first Key: prompt, you haven't actually
locked screen, but it will drop you back down to the screen prompt
~user(bash) $screen
(press enter to ack info)
~user(screen) $^a+x
Key: ^c
~user(screen) $exit
~user(bash) $
If you follow the instructions to the letter, you tend to get this on
a non-BSD system:
~user(bash) $screen
(press enter to ack info)
~user(screen) $^a+x
Key: <-- Enter a password
Again: <-- Re-enter
Screen used by User <user>.
Password: ^c
Screen used by User <user>.
Password: ^c
Screen used by User <user>.
Password: ^c
If (and a big if) BSD is sending the SIGINT to screen as a whole,
then what may be happening is the SIGINT terminating screen itself:
~user(bash) $screen
(press enter to ack info)
~user(screen) $^a+x
Key: <-- Enter a password
Again: <-- Re-enter
Screen used by User <user>.
Password: ^c
~user(bash) $
It may even be poor handling of SIGRETURN, though it should be noted
that OS X also uses SIGRETURN in the same way that BSD does. If it
is poor handling of SIGRETURN, this might explain why (from the man
page):
"Sigreturn() allows users to atomically unmask, switch stacks,
and return
from a signal context. The processes signal mask and stack
status are
restored from the context. The system call does not return;
the users
stack pointer, frame pointer, argument pointer, and processor
status
longword are restored from the context. Execution resumes at
the speci-
fied pc."
The code applicable to the LockTerminal() function can be found in
attacher.c, which has not changed over the last several versions -
suggesting that older versions of the code may also be at risk.
Again, in order to get the errors as claimed in the advisory, screen
DOES NOT lock.
On 05/06/2007, at 9:58 AM, Pranay Kanwar wrote:
> Hi,
>
> Verified on OpenBSD
>
> $ uname -a
> OpenBSD drake 4.1 GENERIC#172 i386
> $ pkg_info screen
> Information for inst:screen-4.0.3p0
>
> Comment:
> multi-screen window manager
> ------output snipped------
>
> $screen
> Then pressing space-bar to continue
>
> Locking the screen with C-a C-x.
>
> Pressing Ctrl+C
>
> Key:
> Getpass error
> $
>
> The screen gets unlocked without entering a password.
>
> Regards
>
> warl0ck // MSG
> http://www.metaeye.org
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
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
