Created attachment 12225 [details] demo Hi Security Team: I found a security problem in the underlying crypt function of the system. The crypt function can be used for password checking, because the crypt function does not limit the length of the password. When checking a very long password, this function will always be in calculation and cannot return normally. And, the CPU usage rate reaches 100%. Failure to return normally will cause the program using this function to be abnormal and achieve the effect of a DOS attack. The crypt function in the official documentation states that the function of the function is used for password checking. Developers believe that this function is very secure, so they will use this function for password checking (usually used for system password checking, and some applications also Will use this function to check their own password), when developers do not limit the length of the password will trigger a DOS attack, usually the password check is in the login function, the login function can usually be remotely operated, all can Implement remote DOS attacks without authentication. I have found this problem with multiple products, for example: 1. Linux PAM (Verification only) 2. VMware related products (DoS attacks have been implemented, reported to vendors) 3. FreeNAS related products(DoS attacks have been implemented, reported to vendors) 4. The crypt module in the Python standard library (Verification only, reported to vendors) 5. Management port of a brand server(DoS attacks have been implemented, reported to vendors) Many products will use this function for password checking, and fully trust the security of this function (the related products listed can be used as proof). If no other protection measures are taken, it is easy to implement DOS attacks (including possible switches, routers, etc. (Such as key network equipment), the password length should be limited, normal passwords will not be very long, it should be a system-level function, it should be controlled from the system level, and it can not be limited only by the product developer. Because it is a problem with the underlying functions of the system, all Linux distributions will be affected. /glibc/crypt/crypt-entry.c I wrote some demos, I put it in the attachment, you can test. If you have any questions, please send me an email and look forward to your reply, thank you.
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).
(In reply to Carlos O'Donell from comment #1) > 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). Hi, there are already actual applications that have caused DoS due to this crypt function problem. I reported this problem and obtained CVE. You can view CVE-2020-11650. At the same time, I also found the same in VMware related products. DoS vulnerability, VMware confirmed the existence of the problem, and is currently releasing a patch to fix it, so the crypt function has problems and affects multiple applications. You should fix the problem from glibc to limit the length and solve the problem from the source.