Announcement

Collapse
No announcement yet.

An Easy But Serious Screensaver Security Problem In X.Org

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • An Easy But Serious Screensaver Security Problem In X.Org

    Phoronix: An Easy But Serious Screensaver Security Problem In X.Org

    I've been alerted this afternoon that there's an outstanding security vulnerability within the current X.Org Server that's receiving little attention. This active vulnerability could allow anyone with physical access to your system to easily bypass the desktop's screen lock regardless of your desktop environment...

    http://www.phoronix.com/vr.php?view=MTA0NTA

  • Nobu
    replied
    There's been a blog post written about this by Peter Hutterer, for those interested.

    Leave a comment:


  • disi
    replied
    Originally posted by phoronix View Post
    Phoronix: An Easy But Serious Screensaver Security Problem In X.Org

    I've been alerted this afternoon that there's an outstanding security vulnerability within the current X.Org Server that's receiving little attention. This active vulnerability could allow anyone with physical access to your system to easily bypass the desktop's screen lock regardless of your desktop environment...

    http://www.phoronix.com/vr.php?view=MTA0NTA
    Even though Gentoo is listed, it was fixed the same day 19/01/12 in Portage for x86, amd64, hppa, arm: https://bugs.gentoo.org/399347

    Leave a comment:


  • krazy
    replied
    The X screen locker has always been a suboptimal hack.

    KDE 4.8 (to be released on 25th Jan) already ditches the X screen locker for one integrated with the compositor. This just goes to show what a good move that is.

    Leave a comment:


  • daniels
    replied
    Originally posted by cynyr View Post
    Hmm, I don't have a keypad on my keyboard (mini Apple Aluminum wired keyboard same layout as the bluetooth one now) so this doesn't seem to work. Also I'm still running xorg-server-1.10 here on my gentoo install due to some issues with the newer nvidia drivers, wine, and team fortress 2.

    How do I check to see if my XKB has the default debugging, without the effected xorg-server and without a keypad?
    Run 'xkbcomp -xkb :0 - | less' and look for a fragment like this:
    interpret XF86_Ungrab {
    action = Private(type=0x86, data=[stuff in hex]);
    };
    interpret XF86_ClearGrab {
    action = Private(type=0x86, data=[more stuff in hex]);
    };

    Leave a comment:


  • cynyr
    replied
    Hmm, I don't have a keypad on my keyboard (mini Apple Aluminum wired keyboard same layout as the bluetooth one now) so this doesn't seem to work. Also I'm still running xorg-server-1.10 here on my gentoo install due to some issues with the newer nvidia drivers, wine, and team fortress 2.

    How do I check to see if my XKB has the default debugging, without the effected xorg-server and without a keypad?

    Leave a comment:


  • Kano
    replied
    @mcdebugger

    Better: set a hd pw in the bios if possible. Even better: get a hd/ssd with integrated encryption. Even without that removing the hd and connecting to another pc will not allow immediate access to modify data. That could be done only by professionals.

    @korpenkraxar

    Most likely you need the fn key to get the blue *.
    Last edited by Kano; 01-19-2012, 05:56 PM.

    Leave a comment:


  • korpenkraxar
    replied
    Arch Linux, Gnome 3, xkeyboard-config version 2.4.1-2 (w/o the patch), Thinkpad W500 with a swedish laptop. I have not been able to unlock the screen. What log file is supposedly printed to? Hmm, which is Keypad-Multiply on this keyboard?

    Leave a comment:


  • mcdebugger
    replied
    Originally posted by not.sure View Post
    Unless you have your disk encrypted, then when you reboot you're exactly nobody (sure, you can manipulate the kernel but lets not go there..).
    You also can lock your BIOS and set a password for editing bootloader's commands. Of course you should also lock your PC case In addition to crypted storage this may be a little nervous for attacker.

    Leave a comment:


  • not.sure
    replied
    Originally posted by Kano View Post
    Well it does not expose root rights until you have got a root terminal open all the time. But when you reboot with correct options you are root.
    Unless you have your disk encrypted, then when you reboot you're exactly nobody (sure, you can manipulate the kernel but lets not go there..).

    Btw also fixed in debian unstable now http://packages.qa.debian.org/x/xorg...9T101901Z.html

    Leave a comment:

Working...
X