[Bug crypt/25441] DOS attack risk caused by incomplete system password check function

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25441

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |carlos at redhat dot com
         Resolution|---                         |WONTFIX
              Flags|                            |security-

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
Yes, it can take a long time to cryptographically hash long password. I don't
see this issue as a security issue unless we have concrete examples of specific
DoS issues impacting real applications. The API imposes no limits, and so we
should not either. Instead the limits need to be imposed by remote login
interfaces like ssh (disable passwords) or pam (limit maximum password size).
Limiting this at the lowest level API will not work well because we have no way
to propagate a complex failure up the software stack e.g. failed because of
policy reasons for too long password.

I'm marking this as RESOLVED/WONTFIX.

Please review:
https://sourceware.org/glibc/wiki/Security%20Process

Note: In Fedora we have moved from libcrypt.so (provided by glibc) to libxcrypt
(provided by the libxcrypt project: https://github.com/besser82/libxcrypt). We
accomplish this by building glibc with --disable-crypt, and then building
libxcrypt in the compatibility mode to provide all the backwards compatibility
required for older applications. We should continue to move forward with
libxcrypt and newer one-way hashing algorithms. Fedora 30 fully removes the
deprecated interfaces
(https://fedoraproject.org/wiki/Changes/FullyRemoveDeprecatedAndUnsafeFunctionsFromLibcrypt).

-- 
You are receiving this mail because:
You are on the CC list for the bug.