Heyho,
FRIGN pointed me to this[0] yesterday.
> Vendor was notified about this issue on 2015-11-13.
I could not find a mail related to this on the suckless mailing lists for that
date, but hiro mentioned an unspecific issue which might be related on
2015-09-09:
> I tried slock on a computer with some crazy network credential system and
> entering a password results in segfault when the network has an outage. It's
> horrible.
Now to the proposed fix[1]: It surely solves the issue in this specific case,
but a too short sp_pwdp as argument is not the only way for crypt() to return
NULL.
The salt might contain bytes not from the valid range [a-zA-Z0-9./]. Should we
check for that? What about the EPERM failure?
I think a good compromise is to check the return of the crypt() call and if it
is NULL, we handle it as if the wrong password was entered and print out a
warning. This way the screen still stays locked on failure and the user has the
chance to discover the failure if he is logging the output somewhere.
The check if the salt is 2 byte and those are in the valid range can of course
be done in advance before actually locking the screen.
--Markus
0:
http://seclists.org/oss-sec/2016/q3/333
1:
http://s1m0n.dft-labs.eu/files/slock/slock.c.patch
Received on Mon Aug 22 2016 - 15:15:07 CEST