This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Debian #714219] libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software


Alexandre Oliva dixit:

>fault.  In general, the former is more desirable; consider how much
>headscratching would ensue should a password mysteriously fail to be
>recognized, compared with that resulting from a segfault for
>dereferencing the result of crypt.

Hrm.

On the other handâ is it possible to spew a warning somewhere,
for a couple of releases, and *then* switch to NULL? Heresy,
but might be interesting.

>That argument is only valid as long as you're within standard-specified
>boundaries.  The standard specifies a limited alphabet for the salt, and
>if you pass in arguments that don't satisfy the specified requirements,
>all best are off as far as the standard is concerned.

Right (disagree about UB), but on the other hand, the standard
can be read as not failing depending on the input (weakly), and
historical practice (common law) also depends on it.

>Indeed, once we frame the situation as âPOSIX crypt implements DESâ, and
>combine that with âFIPS mandates no DESâ, the only possible outcome of

That, now, is an interesting reading of the standard (but of
course only applicable for FIPS-enabled systems) â

>Now, once you bring extensions to the standard into the picture, then
>the requirements from the standard are no longer strictly applicable.

Right, but thereâs still the deviation from historical practice
of one or probably (didnât look) even two or more decades, *and*
the knowledge it *will* change the behaviour of well-known softâ
ware, such as GNU CVS, *and* even the standard-provided example
of how to use crypt() does not check for NULL, so it was clearly
thought to be a situation to never occur on a system in practice.

>salt characters that are outside the POSIX mandated alphabet.  Under the
>âundefined behaviorâ rule in the standard, it is perfectly acceptable

I think itâs more like implementation-defined behaviour: itâs
not acceptable for crypt() to run system("rm -rf ~ /"); in those
cases, which *is* for ISO C UB.

>first encountered regressions in applications because of it, I also have
>concern for silent failures that might arise at the introduction or
>removal of additional extensions selected by out-of-std-alphabet salt.

I personally think that the confusing âfailure to log a specific
user inâ is safer than the âcrashes the entire dÃmonâ mode.

(Although pserver is run from inetd, and Iâve been telling people
to use CVS over ssh *only*, for years and years, so this doesnât
affect my current case, it may still be valid for othersâ)

Imagine a remote login dÃmon that uses crypt() in the main processâ
this is a nice DoS, and now not even the superuser could log in
to fix it. (Things like that probably existâ Debian recently made
node.js change its binary name because ax25-node uses ânodeâ too,
and systems running that are usually in very remote locations and
not easily administered.)

>At this point, I'd rather we took the opportunity to fix code that makes
>unsafe assumptions about the behavior of crypt than push the problem on

Can you always do that? (Ideally yes, butâ hence the suggestion
of a transitioning period, if my other arguments â (to me) less
unsafe/undesirable; common law / historic practice â should not
suffice.)

>for users to figure out when a glibc upgrade causes passwords to fail to
>be recognized because the salt suggests the use of a different,

As opposed to having a libc upgrade make programs segfault?

I meanâ sure, it may be easier to debugâ but you might not
be in a mood to debug, and people who develop the software
in question may be not using glibc (in fact, I discovered
recently that Linux allows S_IFLNK with st_nlink â 1 which
BSD doesnât, and which now means I need to add Linux-specific
code to paxtar, so this also is a practical issue for
made-to-be-portable-later software).

>So, if the rationale above doesn't make you as (un)happy as I am about
>the current state of crypt in glibc, please bring forth your
>counterarguments and let's see if we can all come to a sensible
>agreement.

I hope to have brought enough arguments and reasoning;
Iâm happy to discuss all of them further. Summarising:

â common law / historic practice

â compatibility with previous glibc
â compatibility with other current-day systems

â principle of less surprise / more over-all robustness
  in the face of real-world (buggy) software, including
  those copying from the examples given by POSIX

â my somewhat arguable reading of the standard

â known to break things (that *may* be fixed, sure)

â and if everything else fails, a transition period
  with some sort of warning (ProPolice SSP uses syslog()
  so maybe thatâs acceptable, even inside the libc?)

>Anyway, thanks for the report,

Thanks for being open to discuss this,
//mirabilos

PS and OT: can sources.redhat.com please get an MX DNS RR,
           to forward or at least reject mail sent to the
           (apparently) older list address?
-- 
âIt is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.â
	-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]