This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 435773 - (CVE-2008-0887) CVE-2008-0887 gnome-screensaver using NIS auth will unlock if NIS goes away
CVE-2008-0887 gnome-screensaver using NIS auth will unlock if NIS goes away
Status: CLOSED CURRENTRELEASE
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
high Severity high
: ---
: ---
Assigned To: jmccann
desktop-bugs@redhat.com
reported=20080303,source=it,public=20...
: Security
: 437957 (view as bug list)
Depends On: 436521 436522 440255 440256 440257
Blocks: 246139
  Show dependency treegraph
 
Reported: 2008-03-03 14:57 EST by Alan Matsuoka
Modified: 2015-01-14 18:20 EST (History)
6 users (show)

See Also:
Fixed In Version: 2.18.2-4.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-09 01:18:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Alan Matsuoka 2008-03-03 14:57:41 EST
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@redhat.com> - 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 14:57:41 EST
Created attachment 296671 [details]
screensaver log
Comment 7 jmccann 2008-03-12 13:48:12 EDT
Created attachment 297817 [details]
patch for upstream svn / rawhide
Comment 8 Josh Bressers 2008-03-13 16:04:53 EDT
This does not appear to affect xscreensaver.  I'm not able to reproduce this as
described above.
Comment 9 jmccann 2008-03-13 17:56:52 EDT
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 10:03:32 EDT
I just tested this, xscreensaver does still lock the screen.
Comment 11 jmccann 2008-03-14 10:25:50 EDT
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 13:33:35 EDT
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 09:33:37 EDT
*** Bug 437957 has been marked as a duplicate of this bug. ***
Comment 19 Mark J. Cox (Product Security) 2008-04-02 04:03:37 EDT
embargo was agreed as apr02 with vendor-sec; removing embargo.
Comment 22 Fedora Update System 2008-04-02 13:30:59 EDT
gnome-screensaver-2.18.2-4.fc7 has been submitted as an update for Fedora 7
Comment 23 Fedora Update System 2008-04-02 13:36:15 EDT
gnome-screensaver-2.20.0-12.fc8 has been submitted as an update for Fedora 8
Comment 25 Fedora Update System 2008-04-09 01:18:01 EDT
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 01:21:09 EDT
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.