Bug 435773 (CVE-2008-0887) - CVE-2008-0887 gnome-screensaver using NIS auth will unlock if NIS goes away
Summary: CVE-2008-0887 gnome-screensaver using NIS auth will unlock if NIS goes away
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: CVE-2008-0887
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: jmccann
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
: 437957 (view as bug list)
Depends On: 436521 436522 440255 440256 440257
Blocks: 246139
TreeView+ depends on / blocked
 
Reported: 2008-03-03 19:57 UTC by Alan Matsuoka
Modified: 2019-09-29 12:23 UTC (History)
6 users (show)

Fixed In Version: 2.18.2-4.fc7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-04-09 05:18:10 UTC
Embargoed:


Attachments (Terms of Use)
screensaver log (17.82 KB, text/plain)
2008-03-03 19:57 UTC, Alan Matsuoka
no flags Details
sosreport (3.68 MB, application/x-bzip2)
2008-03-03 20:00 UTC, Alan Matsuoka
no flags Details
patch for upstream svn / rawhide (7.78 KB, patch)
2008-03-12 17:48 UTC, jmccann
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2008:0197 0 normal SHIPPED_LIVE Moderate: gnome-screensaver security update 2008-04-02 11:33:45 UTC
Red Hat Product Errata RHSA-2008:0218 0 normal SHIPPED_LIVE Moderate: gnome-screensaver security update 2008-04-03 14:57:22 UTC

Description Alan Matsuoka 2008-03-03 19:57:41 UTC
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/FAQ_43_5684.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/show_bug.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  fusa_manager_get_user 2272 pwent = getpwnam (username);
1 gs-auth-pam.c   gs_auth_verify_user    651 pwent = getpwnam (username);
2 gs-auth-pwent.c get_encrypted_passwd   143 struct passwd *p = getpwnam
                                            (user);
3 setuid.c        hack_uid               223 p = getpwnam ("nobody");
4 setuid.c        hack_uid               224 if (! p) p = getpwnam
                                            ("noaccess");
5 setuid.c        hack_uid               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
do_ypcall: clnt_call: RPC: Unable to receive; errno = Connection refused
YPBINDPROC_DOMAIN: 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 g_cclosure_marshal_VOID__OBJECT ()
#2  0x0000000000408889 in g_cclosure_marshal_VOID__OBJECT ()
#3  0x00000038cd42cf44 in g_main_context_dispatch ()
  from /lib64/libglib-2.0.so.0
#4  0x00000038cd42fd7d in g_main_context_check () from /lib64/libglib-2.0.so.0
#5  0x00000038cd43008a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#6  0x00000038d712aad3 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0
#7  0x00000000004085c1 in g_cclosure_marshal_VOID__OBJECT ()
#8  0x00000038ca81d8a4 in __libc_start_main () from /lib64/libc.so.6
#9  0x00000000004082d9 in g_cclosure_marshal_VOID__OBJECT ()
#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.

Comment 1 Alan Matsuoka 2008-03-03 19:57:41 UTC
Created attachment 296671 [details]
screensaver log

Comment 7 jmccann 2008-03-12 17:48:12 UTC
Created attachment 297817 [details]
patch for upstream svn / rawhide

Comment 8 Josh Bressers 2008-03-13 20:04:53 UTC
This does not appear to affect xscreensaver.  I'm not able to reproduce this as
described above.

Comment 9 jmccann 2008-03-13 21:56:52 UTC
It would affect xscreensaver in a slightly different way (but I have not
confirmed this).  If the network drops between login and the time that the
screensaver starts (or anytime it restarts) it won't lock the screen.  So it
isn't as severe but still probably not what you expect.

Comment 10 Josh Bressers 2008-03-14 14:03:32 UTC
I just tested this, xscreensaver does still lock the screen.

Comment 11 jmccann 2008-03-14 14:25:50 UTC
I just tested xscreensaver on Fedora 8 and this is what happens if the network
disconnects before xscreensaver starts:
xscreensaver -verbose
do_ypcall: clnt_call: RPC: Unable to receive; errno = No route to host
YPBINDPROC_DOMAIN: Domain not bound
do_ypcall: clnt_call: RPC: Unable to receive; errno = No route to host
YPBINDPROC_DOMAIN: Domain not bound
do_ypcall: clnt_call: RPC: Unable to receive; errno = No route to host
YPBINDPROC_DOMAIN: Domain not bound
do_ypcall: clnt_call: RPC: Unable to receive; errno = No route to host
YPBINDPROC_DOMAIN: Domain not bound
do_ypcall: clnt_call: RPC: Unable to receive; errno = No route to host
YPBINDPROC_DOMAIN: Domain not bound
Could not figure out who the current user is!
[exits]

Comment 12 Josh Bressers 2008-03-14 17:33:35 UTC
So I tried that on RHEL[234].  xscreensaver will start without the network (it
does take quite a long time though).  If it's already running it will lock the
screen fine.

Comment 14 Josh Bressers 2008-03-18 13:33:37 UTC
*** Bug 437957 has been marked as a duplicate of this bug. ***

Comment 19 Mark J. Cox 2008-04-02 08:03:37 UTC
embargo was agreed as apr02 with vendor-sec; removing embargo.

Comment 22 Fedora Update System 2008-04-02 17:30:59 UTC
gnome-screensaver-2.18.2-4.fc7 has been submitted as an update for Fedora 7

Comment 23 Fedora Update System 2008-04-02 17:36:15 UTC
gnome-screensaver-2.20.0-12.fc8 has been submitted as an update for Fedora 8

Comment 25 Fedora Update System 2008-04-09 05:18:01 UTC
gnome-screensaver-2.18.2-4.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 26 Fedora Update System 2008-04-09 05:21:09 UTC
gnome-screensaver-2.20.0-12.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.