unix_chkpwd abnormal exit: 11 unix_chkpwd crashes under gnome-screensaver and prevents unlock (/dev/null corruption?)

Bug #270781 reported by Thomas Babut
52
This bug affects 7 people
Affects Status Importance Assigned to Milestone
pam (Fedora)
Fix Released
Medium
pam (Ubuntu)
Triaged
High
Unassigned

Bug Description

Binary package hint: libpam-modules

I am running Ubuntu Hardy 32-Bit on a Thinkpad T61 with all updates available today. The gnome screensaver locks my screen after 10 minutes idle automatically. Now in the password dialogue I can enter any password or string and the screen gets unlocked. In syslog you'll find the following error message simultaneously:

 kernel: [32810.156696] unix_chkpwd[4787] general protection eip:b7f86446 esp:bfd2d31c error:0

But when I lock my screen manually, this bug doesn't occur and I have to type the right password to unlock the screen again.

Some more informations:

# lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04

# apt-cache policy libpam-modules
libpam-modules:
  Installed: 0.99.7.1-5ubuntu6.1
  Candidate: 0.99.7.1-5ubuntu6.1
  Version table:
 *** 0.99.7.1-5ubuntu6.1 0
        500 http://de.archive.ubuntu.com hardy-updates/main Packages
        100 /var/lib/dpkg/status
     0.99.7.1-5ubuntu6 0
        500 http://de.archive.ubuntu.com hardy/main Packages

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I cannot reproduce this on an up to date hardy i386 virtual machine with the same package versions. I even tried a small test program that just runs unix_chkpwd with various input and it works fine. Can you run 'memtest' to make sure your memory is ok? Can you provide more details on your setup?

Changed in pam:
assignee: nobody → jdstrand
status: New → Incomplete
Revision history for this message
Thomas Babut (thbabut) wrote :

In the meantime I've done a memory test over night and it passed without errors.

Hardware is a Thinkpad T61 with following components:
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HBM (ICH8M-E) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)

I am not using Compiz at all, so all desktop effects are disabled.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Can you post /var/log/syslog and /var/log/kern.log after the crash? What are the contents of /etc/pam.d/common-* and /etc/pam.d/gnome-screensaver. Does the username or password contain weird characters (if posting them here, for your security, please change the password to something else)?

Revision history for this message
Steve Langasek (vorlon) wrote :

The contents of /etc/pam.d/* are immaterial, here; we know that it's the unix_chkpwd process that's segfaulting, which means pam_unix must be involved. And I have seen bugs more recently whereby pam_unix will fail open if unix_chkpwd crashes unexpectedly; but the only case where I've /seen/ unix_chkpwd crash unexpectedly has been with a bug that post-dates the version in hardy.

So what would really help here is a backtrace of unix_chkpwd's crash.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in pam:
assignee: jdstrand → nobody
status: Incomplete → Invalid
Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6) Gecko/2009020410 Fedora/3.0.6-1.fc10 (CK-IBM) (CK-IBM) Firefox/3.0.6

The screensaver lock option doesn't work anymore after a while.

After a normal startup/reboot, screen locking works fine, but after a while (I don't have a precise time or action) it doesn't work: screensaver works, but no password prompt is provided (it behaves like "Lock screen when screensaver is active" is unchecked).

Environment
-----------

Fedora 10 (Cambridge) up-to-date
[uname -a] Linux <hostname> 2.6.27.15-170.2.24.fc10.i686.PAE #1 SMP Wed Feb 11 23:35:37 EST 2009 i686 i686 i386 GNU/Linux

[root@thoth ~]# rpm -qa | grep pam
pam_passwdqc-1.0.5-1.i386
pam_krb5-2.3.2-1.fc10.i386
pam_smb-1.1.7-9.fc10.i386
pam_ccreds-7-3.fc10.i386
pam-1.0.2-2.fc10.i386
pam_pkcs11-0.5.3-26.i386
gnome-keyring-pam-2.24.1-1.fc10.i386
[root@thoth ~]#

Hardware: Lenovo T400 laptop
Components:
00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
...

Related to this issue, audit log reports:

type=ANOM_ABEND msg=audit(03/02/2009 22:04:48.811:108) : auid=snap uid=snap gid=snap ses=2 pid=16059 comm=unix_chkpwd sig=Segmentation fault
type=ANOM_ABEND msg=audit(03/02/2009 22:04:48.814:109) : auid=snap uid=snap gid=snap ses=2 pid=16060 comm=unix_chkpwd sig=Segmentation fault

and /var/log/messages contains:
Mar 2 22:04:48 thoth kernel: unix_chkpwd[16059] general protection ip:83e978 sp:bfd12ea4 error:0 in ld-2.9.so[826000+20000]
Mar 2 22:04:48 thoth kernel: unix_chkpwd[16060] general protection ip:15c900 sp:bf9b3f84 error:0 in ld-2.9.so[144000+20000]

(I really need this feature to work since I'm working at the cust site, so I need to lock my screen from time to time. Thank you)

Reproducible: Always

Steps to Reproduce:
None.

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

You can make it public. It is a security related bug, but not a "Security Sensitive Bug". 10x

Revision history for this message
In , Vincent (vincent-redhat-bugs) wrote :

Pasting your /etc/pam.d/system-auth file would be helpful. Something is segfaulting, so it would be good to know your authentication sources (i.e. if you're using LDAP or NIS, etc.).

FWIW, I don't get this behaviour with F10/x86_64 using local authentication, and I didn't see it with a F10/x86 box using LDAP authentication.

As for a time "estimate", would you say it happens at least daily, or every few hours? More or less often?

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

Also please attach the /etc/nsswitch.conf.

It would really help if you could get the backtrace from the crash although I am afraid that this will not be an easy task.

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

I see 2 problems here:

1. the crash - I suppose this crash happens in some nss module (what is your glibc package version-release)?

2. pam_unix module doesn't guard against crash in unix_chkpwd - it should probably rather disallow access than allow it in case of the crash. Also when this problem with screensaver happens to you what happens when you try to login on the text console?

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

Hi Vincent, hi Tomas,
Thanks for the quick feedback. Here's the data requested:

$ cat /etc/pam.d/system-auth
#%PAM-1.0
auth required pam_shells.so
auth required pam_unix.so likeauth nullok try_first_pass
auth optional pam_ecryptfs.so unwrap
auth required pam_nologin.so
#
account required pam_unix.so
#
password optional pam_ecryptfs.so
password required pam_passwdqc.so min=disabled,8,8,8,8 passphrase=0 enforce=users
password sufficient pam_unix.so remember=8 nullok use_authtok md5 shadow
password required pam_deny.so
#
session required pam_limits.so
session required pam_unix.so
password optional pam_ecryptfs.so unwrap
session optional pam_console.so
[snap@thoth ~]$

I'm using local authentication.
This problem happens daily.

Later I'll try to find in which case it starts happening. When the problem starts I think only a reboot solve it (I'll check later if a logoff/logon is a workaround or not).

Glibc version is 2.9.3

$ rpm -q glibc
glibc-2.9-3.i686
$

I don't think that will affect the text console (I'll get back to you with other details if available).

Please tell me what else can I do to help you in this case. Again, thanks a lot for the feedback.

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

Oh, and the content of nsswitch.conf file also:

$ cat /etc/nsswitch.conf
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
# nisplus or nis+ Use NIS+ (NIS version 3)
# nis or yp Use NIS (NIS version 2), also called YP
# dns Use DNS (Domain Name Service)
# files Use the local files
# db Use the local database (.db) files
# compat Use NIS on compat mode
# hesiod Use Hesiod for user lookups
# [NOTFOUND=return] Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd: db files nisplus nis
#shadow: db files nisplus nis
#group: db files nisplus nis

passwd: files
shadow: files
group: files

#hosts: db files nisplus nis dns
hosts: files mdns4_minimal [NOTFOUND=return] dns

# Example - obey only what nisplus tells us...
#services: nisplus [NOTFOUND=return] files
#networks: nisplus [NOTFOUND=return] files
#protocols: nisplus [NOTFOUND=return] files
#rpc: nisplus [NOTFOUND=return] files
#ethers: nisplus [NOTFOUND=return] files
#netmasks: nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files

netgroup: nisplus

publickey: nisplus

automount: files nisplus
aliases: files nisplus

$

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

Do you have nscd enabled and running or not?

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

No, Tomas, the service is stopped.
# service nscd status
nscd is stopped
#

I'm having this problem almost all the time. Other interesting thing is that things are running fine after a reboot only (but not after a logoff/logon) and when exiting the screensaver it prompts me for a password or I can manually lock screen. But after a while I discovered that even if it is working (screensaver exists with the password dialog, if I let it run then the next screensaver exit place me back to the desktop without any password dialog.

This means that unix_chkpwd starts to crash on both cases: when I manually lock the screen (which starts the screensaver, but after pressing a key returns directly to the desktop) or when exiting the screensaver (pressing any key while running).

In case of a trace or something else, please provide me with the steps to follow and I'll try to provide you further details. Thank you.

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

At the time the unix_chkpwd starts crashing in the screensaver can you try it to run manually:

echo -ne '<password>\0000' | /sbin/unix_chkpwd <user> nullok ; echo $?

Replace the <password> with the password of your account and the <user> with the user name.

Does it crash too? If it does, can you find any related entries in the audit log - use ausearch -x unix_chkpwd.

Does it still crash if you replace nullok with some bogus word? It should return 4 as exit value and add an audit entry and of course not crash.

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

Well, it doesn't crash in this case:

[snap@thoth ~]$ echo -ne '******\0000' | /sbin/unix_chkpwd snap nullok ; echo $?
0
[snap@thoth ~]$

Generally, When it crashes I get also the two aforementioned messages in /var/log/messages. Of course, it didn't crash in this case since no such messages were reported in messages log file. And audit log shows only old records about it, no current one:

# ausearch -i | grep unix_chkpwd | tail -n 5
type=ANOM_ABEND msg=audit(03/03/2009 21:14:30.477:92) : auid=snap uid=snap gid=snap ses=1 pid=12474 comm=unix_chkpwd sig=Segmentation fault
type=ANOM_ABEND msg=audit(03/03/2009 21:14:30.483:93) : auid=snap uid=snap gid=snap ses=1 pid=12475 comm=unix_chkpwd sig=Segmentation fault
type=ANOM_ABEND msg=audit(03/03/2009 21:23:44.502:95) : auid=snap uid=snap gid=snap ses=1 pid=12805 comm=unix_chkpwd sig=Segmentation fault
type=USER_AUTH msg=audit(03/03/2009 21:24:35.600:96) : user pid=12819 uid=snap auid=snap ses=1 msg='op=PAM:unix_chkpwd acct=snap exe=/sbin/unix_chkpwd (hostname=?, addr=?, terminal=pts/0 res=success)'
type=ANOM_ABEND msg=audit(03/03/2009 21:23:44.499:94) : auid=snap uid=snap gid=snap ses=1 pid=12804 comm=unix_chkpwd sig=Segmentation fault
#

When replacing nullok with some bogus word:

[snap@thoth ~]$ echo -ne 'id5n4pIT\0000' | /sbin/unix_chkpwd snap fakeword ; echo $?
bash: echo: write error: Broken pipe
4
[snap@thoth ~]$

indeed it returns 4 and no crash is reported: messages log file is clean and audit log reports:

type=ANOM_EXEC msg=audit(03/03/2009 21:30:21.705:97) : user pid=12965 uid=snap auid=snap ses=1 msg='op=PAM:unix_chkpwd acct=snap exe=/sbin/unix_chkpwd (hostname=?, addr=?, terminal=pts/0 res=failed)'

That's it for now. Thanks again Tomas.

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

Please download and install testing packages pam-1.0.2-2.1debug.fc10
from http://people.redhat.com/tmraz/testing

The unix_chkpwd will write debug messages to /var/log/secure when it runs.

What messages from unix_chkpwd do you see in /var/log/secure when the unix_chkpwd starts crashing?

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

Currently I have pam-1.0.2-2.fc10.i386 installed. But I can't find the debug version of it in your repo. I'll look in some other places too.

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

The URL mentioned above does not point to a YUM repository. You have to download and install the pam-1.0.2-2.1debug.fc10 packages manually with rpm.

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

Yes, but i need i386 version. I see only the debug version for X86_64. I'm using i386 so I need that version. Am I missing something?

$ uname -a
Linux thoth.<domain> 2.6.27.19-170.2.35.fc10.i686.PAE #1 SMP Mon Feb 23 13:09:26 EST 2009 i686 i686 i386 GNU/Linux
$

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

Tomas, I do need to install pam-1.0.2-2.1debug.fc10.i386.rpm package, right? However, I can't find it for now... Can you please upload this version too? 10x

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

You can download them now from the http://people.redhat.com/tmraz/testing/

I had some problems building the i386 packages in mock.

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :
Download full text (3.7 KiB)

Ok, so the debug version of pam is installed:

# rpm -ivh pam-1.0.2-2.1debug.fc10.i386.rpm --force
Preparing... ########################################### [100%]
   1:pam ########################################### [100%]
Updating /etc/pam.d/system-auth...
#

(the other package pam-debuginfo-1.0.2-2.1debug.fc10.i386.rpm was not installed).

First case:

Having the system started from hibernate (which means the problem should still be there), using System > Lock Screen it blanks the screen, screensaver doesn't start (I've notice that in the past also, but that's not a problem anyway), leaving it a couple of seconds then pressing a key, here are the related messages in /var/log/secure:

Mar 5 20:59:50 thoth gnome-screensaver-dialog: PAM unable to dlopen(/lib/security/pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Mar 5 20:59:50 thoth gnome-screensaver-dialog: PAM adding faulty module: /lib/security/pam_ecryptfs.so
Mar 5 20:59:50 thoth gnome-screensaver-dialog: pam_unix(gnome-screensaver:account): read unix_chkpwd output error 0: Success

Indeed, there is no /lib/security/pam_ecryptfs.so file. But as you can see, no unix_chkpwd crash or debug data yet.

Second case:

Now I was rebooting the system because I was curious how come it's working at the startup.

So it's simply working as it should. Now trying again to lock the screen, of course it's working (since again, after a normal startup or reboot is working for a while), and these are the debug messages generated:

Mar 5 21:21:12 thoth gnome-screensaver-dialog: PAM unable to dlopen(/lib/security/pam_ecryptfs.so): /lib/security/pam_ecryptfs.so: cannot open shared object file: No such file or directory
Mar 5 21:21:12 thoth gnome-screensaver-dialog: PAM adding faulty module: /lib/security/pam_ecryptfs.so
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Started.
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Signals set up.
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Not at tty.
Mar 5 21:21:12 thoth unix_chkpwd[4763]: User from getuidname(): snap
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Passwords read: 1
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Hash obtained: 0
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Hash verified: 7
Mar 5 21:21:12 thoth unix_chkpwd[4763]: Password verification result: 7
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Started.
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Signals set up.
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Not at tty.
Mar 5 21:21:19 thoth unix_chkpwd[4764]: User from getuidname(): snap
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Passwords read: 1
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Hash obtained: 0
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Hash verified: 0
Mar 5 21:21:19 thoth unix_chkpwd[4764]: Password verification result: 0
Mar 5 21:21:19 thoth unix_chkpwd[4765]: Started.
Mar 5 21:21:19 thoth unix_chkpwd[4765]: Signals set up.
Mar 5 21:21:19 thoth unix_chkpwd[4765]: Not at tty.
Mar 5 21:21:19 thoth unix_chkpwd[4765]: User from getuidname(): snap

I didn't have the patience to wait for the issue to appear after reboot, so I installed
ecryptfs-utils-61-0.fc10.i386.rpm (and t...

Read more...

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

The issue started to happen again (alright, way later than it happend in the past, but it still happens). Messages related to it are the following:

- in /var/log/messages:

Mar 6 12:36:47 thoth kernel: unix_chkpwd[29542] general protection ip:468978 sp:bfea2c74 error:0 in ld-2.9.so[450000+20000]
Mar 6 12:36:47 thoth kernel: unix_chkpwd[29544] general protection ip:c40900 sp:bf9b0784 error:0 in ld-2.9.so[c28000+20000]

-in /var/log/secure:

Mar 6 12:36:47 thoth gnome-screensaver-dialog: pam_unix(gnome-screensaver:account): read unix_chkpwd output error 0: Success

- in the audit log:

type=ANOM_ABEND msg=audit(03/06/2009 12:36:47.036:178) : auid=snap uid=snap gid=snap ses=1 pid=29542 comm=unix_chkpwd sig=Segmentation fault
type=ANOM_ABEND msg=audit(03/06/2009 12:36:47.039:179) : auid=snap uid=snap gid=snap ses=1 pid=29544 comm=unix_chkpwd sig=Segmentation fault

I also installed pam-debuginfo package:

# rpm -ivh pam-debuginfo-1.0.2-2.1debug.fc10.i386.rpm
Preparing... ########################################### [100%]
   1:pam-debuginfo ########################################### [100%]
#

but I think I should provide the debug versions in /etc/pam.d/system-auth, right?

Should I do other changes as well to get further details?

Please advice. Thank you.

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

Unfortunately the logs or rather nonexistence of any message from the unix_chkpwd in /var/log/secure means that the crash happens during the load of the shared libraries.

I'm reassigning the bug to glibc.

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

Hello,

Can somebody continue on this issue please?
As I said, I am willing to help on this problem since I really need to have this working properly. Thank you

Revision history for this message
In , Jakub (jakub-redhat-bugs) wrote :

The crash is likely in __libc_check_standard_fds.
If a setuid/setgid/other AT_SECURE process is started without the standard file descriptors open (0, 1, 2), glibc during startup will try to open /dev/full on fd 0 and /dev/null on fd 1 and 2 (whichever is closed during exec), to avoid various exploits. The hlt insn is executed if it failed to open /dev/full resp. /dev/null, or if they aren't character devices, or if they don't have the expected major/minor number. So most likely after a while something screws up your /dev/null device, e.g. replaces it with a normal file or removes it etc.

The bug is in whatever corrupts /dev/null resp. /dev/full and partially in whatever starts suid/sgid binaries knowingly with one or more of the standard file descriptors closed.

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

Hi Jakub, very good info, thanks a lot for the feedback.

You are right, one of the apps (I need to find out which one) corrupts the /dev/null device. After recreating it as it should be, screen locking works again. :-)

# ls -l /dev/null
-rw-r--r-- 1 root root 0 2009-03-13 00:20 /dev/null
#
# rm -f /dev/null; mknod -m 666 /dev/null c 1 3
#
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 2009-03-13 00:21 /dev/null
#

And of course, since I still have pam-debug installed, this action is captured in /var/log/secure with the following info:
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Started.
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Signals set up.
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Not at tty.
Mar 13 00:22:43 thoth unix_chkpwd[22656]: User from getuidname(): snap
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Passwords read: 1
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Hash obtained: 0
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Hash verified: 7
Mar 13 00:22:43 thoth unix_chkpwd[22656]: Password verification result: 7
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Started.
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Signals set up.
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Not at tty.
Mar 13 00:22:51 thoth unix_chkpwd[22662]: User from getuidname(): snap
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Passwords read: 1
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Hash obtained: 0
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Hash verified: 0
Mar 13 00:22:51 thoth unix_chkpwd[22662]: Password verification result: 0
Mar 13 00:22:51 thoth unix_chkpwd[22663]: Started.
Mar 13 00:22:51 thoth unix_chkpwd[22663]: Signals set up.
Mar 13 00:22:51 thoth unix_chkpwd[22663]: Not at tty.
Mar 13 00:22:51 thoth unix_chkpwd[22663]: User from getuidname(): snap

In conclusion, I think I should run a small 'monitor' (maybe a simple C prog) to collect the list of processes from time to time, catch de change of /dev/null character device and compare the result to discover the culprit.

From your point of view, should I still leave pam-debug package in my system or not? I'm still willing to help in this case as long I don't brake the system: it's my main production laptop. ;-)

Thanks again. W4F.

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

You can leave the debug packages in the system if you don't mind the excessive logging to /var/log/secure.

I will make an update package in Fedora soon anyway but of course you will still need to find out what application messes up the /dev/null.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

pam-1.0.4-2.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/pam-1.0.4-2.fc9

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

pam-1.0.4-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/pam-1.0.4-2.fc10

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

pam-1.0.4-2.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update pam'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2783

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

pam-1.0.4-2.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing-newkey update pam'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-2849

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

Package was updated on my system (together with this update, I removed pam-debug version). I've noticed that /dev/null didn't get corrupted anymore, although I didn't discover which app was doing it.
Now my question is: in case /dev/null becomes corrupted again (as a normal file instead of a char device), will I be able to login to my system? Or I have to reboot is or something to make it work?

Thanks for the feedback!

Revision history for this message
In , Tomas (tomas-redhat-bugs) wrote :

I've tried to allow this but you should test this.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

pam-1.0.4-3.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/pam-1.0.4-3.fc9

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

pam-1.0.4-3.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update pam'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2783

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

pam-1.0.4-3.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing-newkey update pam'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-3061

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

pam-1.0.4-4.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/pam-1.0.4-4.fc9

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

pam-1.0.4-4.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/pam-1.0.4-4.fc10

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

pam-1.0.4-4.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing update pam'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3204

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

pam-1.0.4-4.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with
 su -c 'yum --enablerepo=updates-testing-newkey update pam'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-3231

Revision history for this message
Michael Tokarev (mjt+launchpad) wrote :

This is in fact reproduceable. I had the same issue too, was difficult to debug (due to setuid-ness of the binary in question), but finally it turned out to be wrong permissions for /dev/full (local config error really) - it was 0660 instead of 0666, so unix_chkpwd was unable to open it when run from user, and complained.

So, we've quite several issues here.

1) some programs (xscreensaver is one) executes PAM stuff with (some) standard filedescriptors closed. Not that it's an issue by itself, but it MAY lead to some unexpected results like this one, and is somewhat unsafe too.

2) wrong logic in calling unix_chkpwd helper from pam_unix. This is a security issue and is a significant one. Failure to verify the password gets interpreted as success. How about running *almost* out of processes and calling some su(1) to expect unix_chkpwd to fail?

3) wrong logic in unix_chkpwd itself, it should not crash if it's unable to reopen its standard file descriptros.

Oh well.

I'd bot close this bug given the above.

See also fedora bug report of the same nature -- https://bugzilla.redhat.com/show_bug.cgi?id=488147 .

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

pam-1.0.4-4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message
In , Fedora (fedora-redhat-bugs) wrote :

pam-1.0.4-4.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.

Revision history for this message
In , Marius (marius-redhat-bugs) wrote :

The app that corrupted /dev/null is Vodafone Mobile Connect client, installed with the package vodafone-mobile-connect-1.99.17-8.noarch. I didn't used it, therefore the issue dissapeared.

I have pam updated to the latest version: pam-1.0.4-4.fc10.i386.

Now, testing again by corrupting /dev/null char device:

# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 2009-04-18 14:59 /dev/null
#
# rm -f /dev/null; touch /dev/null; ls -l /dev/null
-rw-r--r-- 1 root root 0 2009-04-20 15:04 /dev/null
#

"Lock Screen" works fine! No related messages are generated in /var/log/messages or /var/log/secure. I just created back the device as designed:

# ls -l /dev/null
-rw-r--r-- 1 root root 0 2009-04-20 15:04 /dev/null
#
# rm -f /dev/null; mknod -m 666 /dev/null c 1 3
#
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 2009-04-20 15:12 /dev/null
#

I consider this problem solved!
Again, thank you very much for the support and the quick feedback. It was a pleasure to help the community support to improve the experience!

Keep up the good work!

Steve Langasek (vorlon)
Changed in pam (Ubuntu):
importance: Undecided → High
status: Invalid → Triaged
Revision history for this message
Chris Weiss (cweiss) wrote :

I am having this issue on a lucid x64 install upgraded from a properly working karmic. I have another lucid x64 clean install that does not have the issue.

the only information I have is this in my auth.log. can I enable some extended login somehow?
Apr 18 16:27:29 cw gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): unix_chkpwd abnormal exit: 11
Apr 18 16:27:31 cw gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): unix_chkpwd abnormal exit: 11
Apr 18 16:27:31 cw gnome-screensaver-dialog: pam_unix(gnome-screensaver:auth): authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=chrisw

there's 2 because i tried 2 times to make sure I didn't typo, then switched to console and logged in to kill gnome-screensaver. This also isn't failing intermittently, it fails every time, even when manually locking the screen.

Revision history for this message
H.-Dirk Schmitt (dirk-computer42) wrote :

Is /dev/null corrupted (see https://bugs.launchpad.net/ubuntu/+bug/387189) ?
This can trigger this bug.

Revision history for this message
Paul Sladen (sladen) wrote :

Some of the dups/link suggest that the pam_unix abnormal exit (crash) is down to corruption of /dev/null, possibly caused by a rogue version of the Vodafone Mobile Connect client.

It could be that this is being shipped (at least in the case of one of the dups) but a netbook distributor along with UNR/UNE.

summary: - unix_chkpwd crashes on gnome-screensaver
+ unix_chkpwd abnormal exit: 11 unix_chkpwd crashes under gnome-
+ screensaver
summary: - unix_chkpwd abnormal exit: 11 unix_chkpwd crashes under gnome-
- screensaver
+ unix_chkpwd abnormal exit: 11 unix_chkpwd crashes under gnome-
+ screensaver and prevents unlock
summary: unix_chkpwd abnormal exit: 11 unix_chkpwd crashes under gnome-
- screensaver and prevents unlock
+ screensaver and prevents unlock (/dev/null corruption?)
Revision history for this message
Chris Cowan (macil) wrote :

I had this problem, and it turned out I had chown'ed /etc/shadow as root:root instead of root:shadow. I was really confused because my password worked fine for logging in normally and for ssh, but just not for the screensaver.

Revision history for this message
Steve Langasek (vorlon) wrote :

https://bugzilla.redhat.com/show_bug.cgi?id=488147#c21 explains that this segfault comes not from unix_chkpwd, but from glibc which aborts when a setuid or setgid application is started without fds (0,1,2) open and opening a placeholder fd to either /dev/null or /dev/full fails with a permissions problem.

And fds 1 and 2 are closed by pam_unix before launching unix_chkpwd, which is what triggers the abort.

Ultimately the bug is in whatever has broken the standard devices on the system, preventing the fds from being reopened. But we may be able to defend against this better by just not closing stdout/stderr in the first place.

security vulnerability: yes → no
Changed in pam (Fedora):
importance: Unknown → Medium
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.