Review Request 111261: [KDE-Workspace]: Possible NULL ptr. deref. in KDM and KCheckPass

[Oswald Buddenhagen]

> On June 29, 2013, 11:37 a.m., Oswald Buddenhagen wrote:
> > Ship It!
> 
> Albert Astals Cid wrote:
>     Mr Mancha Mancha we're going to need your real name and email before we can submit this for proper attribution.
> 
> mr. mancha wrote:
>     Hello Albert. For the purpose of attribution, my name is "mancha" (just once, not twice). As for email, either mancha1 at hush.com or mancha at lavabit.com will do.
>     
>     PS. I am grateful to Oswald and Michael for taking the time to review my code. My submission improved considerably thanks to their valuable suggestions.

contrary to what albert may actually believe, disclosing one's identity is not a requirement, but a request to comply with the prevalent (ego-centered) culture of the community.
a contributor may very well choose to work under an alias, and legally that's about the same as anyone else with an unverified identity claiming a particular "real-sounding" name.

on a completely different matter, somebody feeling like actually submitting the code to the right branch(es)?

mancha: you're welcome. :)


- Oswald


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111261/#review35275
-----------------------------------------------------------


On June 28, 2013, 7:12 a.m., mr. mancha wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/111261/
> -----------------------------------------------------------
> 
> (Updated June 28, 2013, 7:12 a.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Description
> -------
> 
> Background:
> Beginning with glibc 2.17 (eglibc 2.17), crypt() fails with EINVAL (w/ NULL return) if the salt violates specifications. Additionally, on FIPS-140 enabled Linux systems, DES or MD5 encrypted passwords passed to crypt() fail with EPERM (w/ NULL return).
> 
> Description:
> If KDM uses raw crypt() authentication (or pw_encrypt() on a patched Shadow system; see: https://alioth.debian.org/tracker/index.php?func=detail&aid=314234 ), instead of higher-level authentication such as PAM, and that crypt() can return a NULL pointer (as glibc 2.17+ does when passed a DES/MD5 encrypted passwords on Linux systems in FIPS-140 mode), then attempting to login to such an account via KDM crashes the daemon.
> 
> -----
> kdm[1879]: segfault at 0 ip b74a1909 sp bfd209d4 error 4 in libc-2.17.so[b7421000+186000]
> kdm[1841]: Unknown session exit code 0 (sig 11) from manager process
> -----
> 
> Likewise, KCheckPass, when called in a similar scenario as KDM above, or when attempting to pass invalid input to crypt()/pw_encrypt() such as a "locked" account that has a "!" prepended in the password field, will crash.
> 
> -----
> kcheckpass[1927]: segfault at 0 ip b762b910 sp bffb0494 error 4 in libc-2.17.so[b75ab000+186000]
> -----
> 
> Note: an earlier (and buggy) patch was emailed directly to ML (not via RR). Please disregard that submission entirely.
> 
> 
> Diffs
> -----
> 
>   kcheckpass/checkpass_etcpasswd.c 1dbe06f 
>   kcheckpass/checkpass_osfc2passwd.c 9a074f9 
>   kcheckpass/checkpass_shadow.c ec3a4e0 
>   kdm/backend/client.c bdff6da 
> 
> Diff: http://git.reviewboard.kde.org/r/111261/diff/
> 
> 
> Testing
> -------
> 
> Tests conducted on KDE-Workspace 4.10.4 confirm attached patch corrects the issues described above. Before applying the patch, KDM and KCheckPass segfault as shown in log snippets above. After applying the patch, both properly handle NULL returns from crypt() and pw_encrypt().
> 
> 
> Thanks,
> 
> mr. mancha
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130629/1e7f22ad/attachment.htm>