Linux glibc security fix created a nastier Linux bug – ZDNet

Sometimes a programming cure is worse than the disease. That’s the case with this Linux glibc security bug.
Steven J. Vaughan-Nichols, aka sjvn, has been writing about technology and the business of technology since CP/M-80 was the cutting edge, PC operating system; 300bps was a fast Internet connection; WordStar was the state of the art word processor; and we liked it.
The GNU C Library (glibc) is essential to Linux. So, when something goes wrong with it, it’s a big deal. When a fix was made in early June for a relatively minor problem, CVE-2021-33574, which could result in application crashes, this was a good thing. Unfortunately, it turned out the fix introduced a new and nastier problem, CVE-2021-38604. It’s always something!
The first problem wasn’t that bad. As Siddhesh Poyarekar, a Red Hat principal software engineer wrote, “In order to mount a minimal attack using this flaw, an attacker needs many pre-requisites to be able to even crash a program using this mq_notify bug.” Still, it needed patching and so it was fixed. Alas, the fix contained an even nastier bug.
While checking the patch, Nikita Popov, a member of the CloudLinux TuxCare Team, found the problem. It turns out that it is possible to cause a situation where a segmentation fault could be triggered within the library. This can lead to any application using the library crashing. This, of course, would cause a Denial-of-Service (DoS) issue. This problem, unlike the earlier one, would be much easier to trigger. Whoops.
Red Hat gives the problem in its Common Vulnerability Scoring System (CVSS) a score of 7.5, which is “high.” An attack using it would be easy to build and requires no privileges to be made. In short, it’s bad news. 
Popov himself thinks “every Linux application including interpreters of other languages (python, PHP) is linked with glibc. It’s the second important thing after the kernel itself, so the impact is quite high.”
Popov found the problem while doing “his usual routine of porting CVE-2021-33574 fix to our supported distros.”  He found that null pointers could be passed in certain situations. 
Technically, the problem lay in the ‘mq_’ function family. These provide POSIX compliant message queue application programming interface (API) functionality. Typically these are used for inter-process communications (IPC) processes. Every Linux application including interpreters of other languages (Python, PHP) is linked with glibc library.
Popov found “two situations where the Linux Kernel would use the message NOTIFY_REMOVED while passing copied thread attributes along the way in the data.attr field. Unfortunately, a host application is able to pass a NULL value there if it wants glibc to spawn a thread with default attributes. In this case, glibc would dereference a NULL pointer in pthread_attr_destroy, leading to a crash of the entire process.”
The C programmers among you are already closing their eyes and shaking their heads ruefully. One of the common rules of C programming is to never, ever dereference a null pointer. The question isn’t “Will it crash the program?” It’s “How badly will it crash the program?”  
The good news is both the vulnerability and code fix have been submitted to the glibc development team. It has already been incorporated into upstream glibc.
In addition, a new test has been submitted to glibc’s automated test suite to pick up this situation and prevent it from happening in the future. The bottom line is sometimes changed in unrelated code paths can lead to behaviors changing elsewhere without the programmer realizing what’s going on. This test will catch this situation.
The Linux distributors are still working out the best way to deploy the fix. In the meantime, if you want to be extra careful — and I think you should be — you should upgrade to the newest stable version of glibc 2.34 or higher. 
Related Stories:
Red Hat Enterprise Linux 9: Security baked in

Ransomware is a national security threat, so please tell us about attacks, says government

Hackers used the Log4j flaw to gain access before moving across a company’s network, say security researchers

A security researcher easily found my passwords and more: How my digital footprints left me surprisingly over-exposed

The 6 best gaming monitors: Prepare for a world of hertz

The 6 best rewards credit cards: Big spenders need big rewards

Mechanical keyboards: A comprehensive guide

How to clean a mechanical keyboard

The best Android phones: Better than the iPhone?

Please review our terms of service to complete your newsletter subscription.
You agree to receive updates, promotions, and alerts from You may unsubscribe at any time. By joining ZDNet, you agree to our Terms of Use and Privacy Policy.
You agree to receive updates, promotions, and alerts from You may unsubscribe at any time. By signing up, you agree to receive the selected newsletter(s) which you may unsubscribe from at any time. You also agree to the Terms of Use and acknowledge the data collection and usage practices outlined in our Privacy Policy.
© 2022 ZDNET, A RED VENTURES COMPANY. ALL RIGHTS RESERVED. Privacy Policy | Cookie Settings | Advertise | Terms of Use


We will be happy to hear your thoughts

Leave a reply

Compare items
  • Total (0)