-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 rembrandt wrote:
> http://www.milw0rm.com/exploits/4028 ... > I found no security contact either and did not wanted to spam the > mailinglist. That's... strange reasoning. Contacting the developers/community is what the lists are for, after all. The report mentions using Ctrl+x; I'll assume that it meant C-a x. Control-C doesn't do anything during the Password prompt, at least for me; but then, screen handles term-locking by invoking an external program (`/local/bin/lck' or `/usr/bin/lock' if they exist), so it wouldn't surprise me overly much to find a broken system lock. However, while screen was prompting for password on one terminal, that session was listed as "detached" from a new one, and could be reattached from there. That's not a bug, though, as the texinfo manual specifically notes: > Warning: When you leave other shells unlocked and have no password > set on `screen', the lock is void: One could easily re-attach from > an unlocked shell. This feature should rather be called > `lockterminal'. Which makes a lot of sense, if screen's "lock" function is described as invoking /usr/bin/lock. So, the failure is user error: if you expect to prevent other connections to screen, you should first set a screen password using screen's "password" command. After doing that, screen will then be able to prompt other users for that password before allowing them to connect (the lock program invoked by screen's lock command, even if it's just the built-in one, can not communicate the password chosen by the user back to screen, so this behavior is not at all surprising). - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIYJFA7M8hyUobTrERAt88AJ9LM1tAvBiZNUADgYoOeqLjbFFSzACfY706 OzBmd2/O1Saw39B9R2h08Cw= =twq5 -----END PGP SIGNATURE-----
