gnome-screensaver 2.26.1 relies on the gnome-session D-Bus interface to determine session idle time, even when an Xfce desktop such as Xubuntu or Mythbuntu is used, which allows physically proximate attackers to access an unattended workstation on which screen locking had been intended.
gnome-screensaver 2.28.0 does not resume adherence to its activation settings after an inhibiting application becomes unavailable on the session bus, which allows physically proximate attackers to access an unattended workstation on which screen locking had been intended.
gnome-screensaver before 2.28.2 allows physically proximate attackers to bypass screen locking and access an unattended workstation by moving the mouse position to an external monitor and then disconnecting that monitor.
GNOME screensaver 2.20 in Ubuntu 7.10, when used with Compiz, does not properly reserve input focus, which allows attackers with physical access to take control of the session after entering an Alt-Tab sequence, a related issue to CVE-2007-3069.
Chris Coulson reported gnome-screensaver is prone to race condition between two subsequent actions -- shaking the unlock dialog and clearing the screen. A local attacker could use this flaw to cause a denial of service (gnome-screensaver crash), which allows physically proximate attackers to access an unattended workstation on which screen locking had been intended.
Upstream bug report: https://bugzilla.gnome.org/showbug.cgi?id=598476
Upstream patch: http://git.gnome.org/browse/gnome-screensaver/commit/?id=ab08cc93f2dc6223c8c00bfa1ca4f2d89069dbe0
CVE Request: http://www.openwall.com/lists/oss-security/2010/02/12/1
References: http://www.heise.de/newsticker/meldung/Gnome-Bildschirmsperre-in-OpenSuse-Linux-wirkungslos-928580.html
gnome-screensaver 2.14.3, 2.22.2, 2.27.x, 2.28.0, and 2.28.3, when the X configuration enables the extend screen option, allows physically proximate attackers to bypass screen locking, access an unattended workstation, and view half of the GNOME desktop by attaching an external monitor.
Description of problem:
If a RHEL5.1 GNOME desktop is locked, and the authentication method is NIS, anyone can unlock the screen with no passwd if the network connection to the NIS disappears or the NIS server is not available.
How reproducible:
Every time.
Steps to Reproduce:
1. Configure machine to be NIS server per:
http://kbase.redhat.com /faq/FAQ435684.shtm
2. Configure a NIS client using system-config-authentication
3. Login to GNOME desktop with NIS-only user.
4. Lock the screen
5. Stop the NIS server (customer disconnected network cable in his test)
6. Press return in lock window. Press cancel.
7. Screen unlocks with no passwd prompt.
Actual results:
Broke in.
Expected results:
Screen should stay locked as there is no way to validate the user who is logged in.
Additional info:
Similar bug on RHEL4:
https://bugzilla. redhat.com/showbug.cgi?id=237003
A similar bug was fixed on RHEL5:
Sun Oct 15 2006 Ray Strode <rstrode> - 2.16.0-13.el5 - lock screen immediately if login security token was removed before startup (bug 210411)
Customer tested gnome-screensaver-2.16.1-6.el5 from FastTrack channel but had same results.
Log file from his gnome-screensaver session attached.
Supporting Materials: Description of how to reproduce, log from gnome-screensaver. I've reproduced this on F8 and RHEL 5.1 as well, a sosreport is currently being generated from my RHEL 5.1 guest.
More Info:ore info...
The problem might be on any of the calls to getpwnam():
File Function Line 0 fusa-manager.c fusamanagergetuser 2272 pwent = getpwnam (username); 1 gs-auth-pam.c gsauthverifyuser 651 pwent = getpwnam (username); 2 gs-auth-pwent.c getencryptedpasswd 143 struct passwd p = getpwnam (user); 3 setuid.c hackuid 223 p = getpwnam ("nobody"); 4 setuid.c hackuid 224 if (! p) p = getpwnam ("noaccess"); 5 setuid.c hackuid 225 if (! p) p = getpwnam ("daemon");
Test program gets this error: #include <sys/types.h> #include <pwd.h> #include <stdlib.h> #include <stdio.h>
int main(char argc, char argv[]) {
if (!getpwnam("rickb")) printf("error"); }
./getpwnam doypcall: clntcall: RPC: Unable to receive; errno = Connection refused YPBINDPROCDOMAIN: Domain not bound
If NIS is down.
If those calls to getpwent() don't handle a NULL properly, we could be in trouble if the return values are undefined.
Additional info:
Problem may be that gnome-screenaver-dialog is exiting abnormally.
If you attach with gdb to this process and set a breakpoint on exit, continue, then shutdown the NIS server, you get this stack trace:
Program received signal SIGTERM, Terminated. [Switching to Thread 46912496279280 (LWP 10062)] 0x00000038cb40dd4d in raise () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000038cb40dd4d in raise () from /lib64/libpthread.so.0 #1 0x000000000040e529 in gcclosuremarshalVOIDOBJECT () #2 0x0000000000408889 in gcclosuremarshalVOIDOBJECT () #3 0x00000038cd42cf44 in gmaincontextdispatch () from /lib64/libglib-2.0.so.0 #4 0x00000038cd42fd7d in gmaincontextcheck () from /lib64/libglib-2.0.so.0 #5 0x00000038cd43008a in gmainlooprun () from /lib64/libglib-2.0.so.0 #6 0x00000038d712aad3 in gtkmain () from /usr/lib64/libgtk-x11-2.0.so.0 #7 0x00000000004085c1 in gcclosuremarshalVOIDOBJECT () #8 0x00000038ca81d8a4 in libcstartmain () from /lib64/libc.so.6 #9 0x00000000004082d9 in gcclosuremarshalVOIDOBJECT () #10 0x00007ffff53660e8 in ?? () #11 0x0000000000000000 in ?? ()
(gdb) info thread 2 Thread 1084229952 (LWP 10063) 0x00000038ca8c5d16 in poll () from /lib64/libc.so.6 1 Thread 46912496279280 (LWP 10062) 0x00000038cb40dd4d in raise () from /lib64/libpthread.so.0
Once this happens, the process terminates.
gnome-screensaver 2.28.x before 2.28.3 does not properly synchronize the state of screen locking and the unlock dialog in situations involving a change to the number of monitors, which allows physically proximate attackers to bypass screen locking and access an unattended workstation by connecting and disconnecting monitors multiple times, a related issue to CVE-2010-0414.
It was reported [1] that the GNOME screensaver could insecurely unlock a secondary screen when moving from a single screen display to a dual-screen display. If a user were to have a suspended laptop, attach an external monitor, resume, and attempt to unlock the GNOME screensaver, the external display will show the GNOME desktop and can be interacted with, without requiring a password.
Upstream has provided a possible patch to correct the issue [2].
CVE-2010-0285 has been assigned to this issue.
[1] https://bugzilla.gnome.org/showbug.cgi?id=593616 [2] http://git.gnome.org/browse/gnome-screensaver/commit/?id=2f597ea9f1f363277fd4dfc109fa41bbc6225aca
gnome screensaver before 2.14, when running on an X server with AllowDeactivateGrabs and AllowClosedownGrabs enabled, allows attackers with physical access to cause the screensaver to crash and access the session via the Ctl+Alt+Keypad-Multiply keyboard sequence, which removes the grab from gnome.
gnome-screensaver 3.4.x before 3.4.4 and 3.5.x before 3.5.4, when multiple screens are used, only locks the screen with the active focus, which allows physically proximate attackers to bypass screen locking and access an unattended workstation.
Description of problem:
Quoting Debian bug report: With the addition of the feature to send a message to the logged in user when they return and unlock a locked session, this gives local attackers the ability to read the X selection and clipboard buffers with a middle click on the mouse and a Ctrl+V. I note that the box to leave a message doesn't have a context menu that you could paste via, but it doesn't go far enough.
Additional info:
http://bugzilla.gnome.org/showbug.cgi?id=503005 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455484