Bug 811402 - pam segfaults on failing to check for crypt() returning NULL in fips mode
pam segfaults on failing to check for crypt() returning NULL in fips mode
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
17
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-10 18:12 EDT by Paul Wouters
Modified: 2013-07-08 13:20 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-08 13:20:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
patch for crasher (1.49 KB, patch)
2012-04-10 18:56 EDT, Paul Wouters
no flags Details | Diff

  None (edit)
Description Paul Wouters 2012-04-10 18:12:29 EDT
Description of problem:
When changing a password in fips mode, passwd segfaults

Version-Release number of selected component (if applicable):
pam-1.1.5-5.fc17.x86_64

How reproducible:
always

Steps to Reproduce:
1. install F17 test in a VM (or on hardware without AES-NI)
2. boot with boot=/dev/vda2 fips=1   (if /dev/vda2 is your /boot partition)
3. login as your user (root cannot login)
4. become superuser
5. passwd youruser
  
Actual results:
Program received signal SIGSEGV, Segmentation fault.
__strncmp_sse2 () at ../sysdeps/x86_64/strcmp.S:214
214             movlpd  (%rsi), %xmm2


Expected results:
a new password :)

Additional info:
(gdb) bt
#0  __strncmp_sse2 () at ../sysdeps/x86_64/strcmp.S:214
#1  0x00007fbc76cc7811 in create_password_hash (
    pamh=pamh@entry=0x7fbc81811df0, password=0x7fbc8181a0c0 "testme",
    ctrl=ctrl@entry=8395044, rounds=<optimized out>) at passverify.c:427
#2  0x00007fbc76cc4e87 in pam_sm_chauthtok (pamh=0x7fbc81811df0,
    flags=<optimized out>, argc=<optimized out>, argv=<optimized out>)
    at pam_unix_passwd.c:798
#3  0x00007fbc7eba00c4 in _pam_dispatch_aux (use_cached_chain=<optimized out>,
    resumed=<optimized out>, h=0x7fbc81817af0, flags=8192, pamh=0x7fbc81811df0)
    at pam_dispatch.c:110
#4  _pam_dispatch (pamh=pamh@entry=0x7fbc81811df0, flags=flags@entry=8192,
    choice=choice@entry=6) at pam_dispatch.c:407
#5  0x00007fbc7eba4312 in pam_chauthtok (pamh=0x7fbc81811df0, flags=0)
    at pam_password.c:46
#6  0x00007fbc7ffa3e5e in main (argc=<optimized out>, argv=<optimized out>)
    at passwd.c:532


passverify shows:
                crypt_make_salt(sp, 8);
                /* For now be conservative so the resulting hashes
                 * are not too long. 8 bytes of salt prevents dictionary
                 * attacks well enough. */
#ifdef HAVE_CRYPT_GENSALT_R
        }
#endif
        sp = crypt(password, salt);
        if (strncmp(algoid, sp, strlen(algoid)) != 0) {
                /* libxcrypt/libc doesn't know the algorithm, use MD5 */
                pam_syslog(pamh, LOG_ERR,
                           "Algo %s not supported by the crypto backend, "
                           "falling back to MD5\n",
                           on(UNIX_BLOWFISH_PASS, ctrl) ? "blowfish" :
                           on(UNIX_SHA256_PASS, ctrl) ? "sha256" :
                           on(UNIX_SHA512_PASS, ctrl) ? "sha512" : algoid);
                memset(sp, '\0', strlen(sp));
                return crypt_md5_wrapper(password);

According to gdb, sp is NULL and algoid = "$6$" (which seems to be UNIX_SHA512_PASS)

This is consistent with man 3 crypt which says NULL is returned on error, but this code blindly strncmp's the NULL.



So it seems the root cause is that in fips mode, libc does not know UNIX_SHA512_PASS.
Comment 1 Paul Wouters 2012-04-10 18:56:53 EDT
Created attachment 576626 [details]
patch for crasher

Attached patch fixes the crasher, though it then falls back to algo $1$ which I think is MD5? Which is also not really fips co,pliant :P

But that fix is for glibc, not pam
Comment 2 Tomas Mraz 2012-04-11 02:23:43 EDT
Glibc should definitely support the SHA512 password hashes in the FIPS mode so it must be fixed. Have you reported this problem to glibc?

Of course the check for null return from crypt() in passverify.c should be added as well.
Comment 3 Paul Wouters 2012-04-12 16:16:58 EDT
I reported it in RHBZ, but I'll also point it out to upstream

https://bugzilla.redhat.com/show_bug.cgi?id=811753
Comment 4 Fedora End Of Life 2013-07-04 02:34:54 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 5 Paul Wouters 2013-07-08 13:20:28 EDT
This is addressed in f17 and up, it just did not make it into the changelog and so the bug was left open accidentally

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