A new Linux vulnerability known as 'Looney Tunables' enables local attackers to gain root privileges by exploiting a buffer overflow weakness in the GNU C Library's ld.so dynamic loader.
It’s always memory management
It’s always memory management
No wonder everyone's crazy about Rust.
It's certainly why it is being used to build browsers and OSs now. Those are places were memory management problems are a huge problem. It probably doesn't make sense for every match 3 game to be made in Rust, but when errors cause massive breaches or death, it's a lot safer than C++, taking human faulability into account.
Question would be rather: why is something like C++ needed for such simple apps?
C++ seems to be in that weird in-between place of offering high level features to be reasonable productive, but still doesn't enforce/guarantee anything to make these features safe. I'd argue, very few programs need that. Either you're writing business stuff, then you want safety (Java, C#, rust), or you're writing embedded/low level stuff, then you want control (C, ASM).
The room for "productive, but not interested in safety" is basically just AAA games, I guess.
C is almost the old "steady" standard now it feels like. It's so flexible and the frameworks are already built..
...except that we also end up with cracks in our foundations like this exploit constantly being exposed as a result of all that C
Well you're not going to write asm if you want your code to be portable at all, and believe it or not C++ has a lot of features to help you not shoot yourself in the foot that C doesn't have (ex. OOP, RAII, smart pointers).
C wasn't really designed with dynamic memory management in mind. It was designed for someone who has absolute control over a machine and all the memory in it. malloc() and free() are just functions that some environments expose to user mode processes, but C was never designed to care where you got your memory or what you do with it.
What makes rust so resiliant against these types of atacks?
The short answer is Rust was built with safety in mind. The longer answer is C was built mostly to abstract from assembly without much thought to safety. In C, if you want to use an array, you must manually request a chunk of memory, check to make sure you are writing within the bounds of your array, and free up the memory used by your array when completely done using it. If you do not do those steps correctly, you could write to a null pointer, cause a buffer overflow error, a use-after-free error, or memory leak depending on what step was forgotten or done out of order. In Rust, the compiler keeps track of when variables are used through a borrowing system. With this borrowing system the Rust compiler requests and frees memory safely. It also checks array bounds at run-time without a programmer explicitly needing to code it in. Several high-level languages have alot of these safety features too. C# for example, can make sure objects are not freed until they fall out of scope, but it does this at run-time with a garbage collector where Rust borrower rules are done at compile-time.
C was built mostly to abstract from assembly
That’s actually not true; rather, many modern architectures are designed to allow languages like C to be compiled more easily. Old architectures don’t even have a built-in stack.
The compiler enforces "aliasing XOR mutability"; utilizes "move semantics"; has a "borrowing and ownership" model; and requires the programmer to tag their references with "lifetimes". Array accesses are checked at runtime if they cannot be guaranteed safe at compile-time. Variables passed by value (moved) cannot be reused. Variables cannot be moved or mutated if any borrow to them exists. You may either have only one mutable borrow, or many immutable borrows, but never both. Therefore you cannot mutate an array while iterating on it, and you cannot have two separate unchecked references to the same array. Every function or type that accepts a borrow must be able to annotate the lifetimes of references to ensure that references are always dropped in the correct order to prevent dangling references. Rust requires developing software with discipline using patterns that satisfy all of these constraints.
That was the what I was thinking of when I wrote the comment. The CTO of Azure also said that he deems C++ in it’s entirety to be deprecated. I felt it was an exaggeration at first but I’ve started to agree with him recently.
Google also noticed a 33% decrease in Google Home crashes caused by NullPointerExceptions after switching to Kotlin. They have also declared Kotlin to be the preferred language for android.
It seems like the industry is shifting towards “safer” languages.
I'm not in America but the organisation for NIST recommends it in guidance now and its getting backing by the nsa
I see this becoming required in the future for new projects and solutions when working for new governnent solutions. The drum is certainly beating louder in the media about it.
Thanks! Not just for notifying about the fix but also showing me where package revisions are built from! I just love the transparency of Arch.
Arch is a meme, but it is honestly really cool too.
Makes me wonder. LMDE got a glibc update too and Mint is very much not leading edge when it comes to non-critical updates.
Case in point, at roughly the same time as the glibc update, we (LMDE users) were upgraded to the latest Thunderbird, 115.3.1, four or five days after that sub-version came out. That's the sort of lag we generally see. (115.x was a bit of a surprise too as we've been on 102.x, but that's not strictly relevant here.)
Ran nala after seeing this post and got a libc update on Debian myself
Wonder if musl is fine. If so,Void people are certainly having fun now.
Sometimes I wonder if vulnerability research teams do more harm than good. This vulnerability became possible due to a commit in 2021, but no one has seen it exploited before. But, now that it's been widely announced, it "creates" a new surface vector for malicious actors to attack that previously wouldn't have been known to exist.
That being said, I know that more sophisticated attackers have entire arsenals of vulnerabilities not yet publicly discovered that they keep close to their chest, and this could've been one of them. Cybersecurity is an exhausting field.
Typically there's a period of responsible disclosure to give the software maintainer an opportunity to fix it before it's widely announced. After that period is up or the fix has been released the vulnerability discoverer is able to announce it and take credit for finding it.
I know that's what usually occurs, I just didn't notice that mentioned in the article for this particular vuln. Good to know they did that in this instance.
Qualys and Red Hat are pretty big names, so they'd be likely to follow the typical process.
Distro developers were notified a month ago. At least Redhat and Debian have have published fixed versions. This is common procedure.
Security through obscurity is never good.
It's better that vulnerabilities be discussed openly. In general, people knowing the truth allows them to make better decisions.
It's not only the good guys that find vulnerabilities. There're many states and companies (selling to those governments) as well as regular criminal organizations paying people for vulnerabilities and exploits.
If the issue wasn't reported, it is likely that it would have been found by someone else at some point. It might even be known already, but just not reported.
It’s always memory management
No wonder everyone's crazy about Rust.
It's certainly why it is being used to build browsers and OSs now. Those are places were memory management problems are a huge problem. It probably doesn't make sense for every match 3 game to be made in Rust, but when errors cause massive breaches or death, it's a lot safer than C++, taking human faulability into account.
Question would be rather: why is something like C++ needed for such simple apps?
C++ seems to be in that weird in-between place of offering high level features to be reasonable productive, but still doesn't enforce/guarantee anything to make these features safe. I'd argue, very few programs need that. Either you're writing business stuff, then you want safety (Java, C#, rust), or you're writing embedded/low level stuff, then you want control (C, ASM).
The room for "productive, but not interested in safety" is basically just AAA games, I guess.
C is almost the old "steady" standard now it feels like. It's so flexible and the frameworks are already built..
...except that we also end up with cracks in our foundations like this exploit constantly being exposed as a result of all that C
Well you're not going to write asm if you want your code to be portable at all, and believe it or not C++ has a lot of features to help you not shoot yourself in the foot that C doesn't have (ex. OOP, RAII, smart pointers).
C wasn't really designed with dynamic memory management in mind. It was designed for someone who has absolute control over a machine and all the memory in it.
malloc()andfree()are just functions that some environments expose to user mode processes, but C was never designed to care where you got your memory or what you do with it.What makes rust so resiliant against these types of atacks?
The short answer is Rust was built with safety in mind. The longer answer is C was built mostly to abstract from assembly without much thought to safety. In C, if you want to use an array, you must manually request a chunk of memory, check to make sure you are writing within the bounds of your array, and free up the memory used by your array when completely done using it. If you do not do those steps correctly, you could write to a null pointer, cause a buffer overflow error, a use-after-free error, or memory leak depending on what step was forgotten or done out of order. In Rust, the compiler keeps track of when variables are used through a borrowing system. With this borrowing system the Rust compiler requests and frees memory safely. It also checks array bounds at run-time without a programmer explicitly needing to code it in. Several high-level languages have alot of these safety features too. C# for example, can make sure objects are not freed until they fall out of scope, but it does this at run-time with a garbage collector where Rust borrower rules are done at compile-time.
That’s actually not true; rather, many modern architectures are designed to allow languages like C to be compiled more easily. Old architectures don’t even have a built-in stack.
The compiler enforces "aliasing XOR mutability"; utilizes "move semantics"; has a "borrowing and ownership" model; and requires the programmer to tag their references with "lifetimes". Array accesses are checked at runtime if they cannot be guaranteed safe at compile-time. Variables passed by value (moved) cannot be reused. Variables cannot be moved or mutated if any borrow to them exists. You may either have only one mutable borrow, or many immutable borrows, but never both. Therefore you cannot mutate an array while iterating on it, and you cannot have two separate unchecked references to the same array. Every function or type that accepts a borrow must be able to annotate the lifetimes of references to ensure that references are always dropped in the correct order to prevent dangling references. Rust requires developing software with discipline using patterns that satisfy all of these constraints.
Didn't Microsoft do a study on security vulnerabilities and found that the overwhelmingly number of bugs was due to memory management?
I think you're referring to this: https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
That was the what I was thinking of when I wrote the comment. The CTO of Azure also said that he deems C++ in it’s entirety to be deprecated. I felt it was an exaggeration at first but I’ve started to agree with him recently.
Google also noticed a 33% decrease in Google Home crashes caused by NullPointerExceptions after switching to Kotlin. They have also declared Kotlin to be the preferred language for android.
It seems like the industry is shifting towards “safer” languages.
I'm not in America but the organisation for NIST recommends it in guidance now and its getting backing by the nsa
https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3215760/nsa-releases-guidance-on-how-to-protect-against-software-memory-safety-issues/
https://www.zdnet.com/article/nsa-to-developers-think-about-switching-from-c-and-c-to-a-memory-safe-programming-language/ https://www.malwarebytes.com/blog/news/2022/11/nsa-guidance-on-how-to-avoid-software-memory-safety-issues
I see this becoming required in the future for new projects and solutions when working for new governnent solutions. The drum is certainly beating louder in the media about it.
See? All code sucks.
It says "sysadmins should prioritise patching", but... has it been patched yet?
Just like…make a patch. It’s not that hard lol /j
To show you the power of Flex Tape, I sawed this library in half!
Yes, most of the major distributions have package updates with the fix. A few people have mentioned updates for Arch, Debian, and RedHat already.
Ubuntu released an update yesterday as well:
https://launchpad.net/ubuntu/+source/glibc/2.35-0ubuntu3.4
Ubuntu derivatives such as Pop!_OS should have also received this update, along with the X11 patches.
I wonder if this could be used to root previously unrootable Android based devices.
Android doesn't use glibc, but Bionic, a C standard library developed by Google. So I don't think this vulnerability affects Android.
What the heck. I thought, they were using musl.
Certainly seems like this has rather similar goals to musl...
That's no reason for Google not to reinvent the wheel....
They did the same with dalvik and ART now. JVMs, but more googlier!
And Quic, and Pony express, and GFS...
Think Android uses Bionic instead of glibc (where the vulnerability is being exploited).
Just got some glibc updates in Arch yesterday. I wonder if they contain fixes for this.
Yep.
Thanks! Not just for notifying about the fix but also showing me where package revisions are built from! I just love the transparency of Arch.
Arch is a meme, but it is honestly really cool too.
Makes me wonder. LMDE got a glibc update too and Mint is very much not leading edge when it comes to non-critical updates.
Case in point, at roughly the same time as the glibc update, we (LMDE users) were upgraded to the latest Thunderbird, 115.3.1, four or five days after that sub-version came out. That's the sort of lag we generally see. (115.x was a bit of a surprise too as we've been on 102.x, but that's not strictly relevant here.)
Ran nala after seeing this post and got a libc update on Debian myself
Wonder if musl is fine. If so,Void people are certainly having fun now.
It is
Edit: "Alpine Linux remains an exception due to its use of musl libc instead of glibc."
Sometimes I wonder if vulnerability research teams do more harm than good. This vulnerability became possible due to a commit in 2021, but no one has seen it exploited before. But, now that it's been widely announced, it "creates" a new surface vector for malicious actors to attack that previously wouldn't have been known to exist.
That being said, I know that more sophisticated attackers have entire arsenals of vulnerabilities not yet publicly discovered that they keep close to their chest, and this could've been one of them. Cybersecurity is an exhausting field.
Typically there's a period of responsible disclosure to give the software maintainer an opportunity to fix it before it's widely announced. After that period is up or the fix has been released the vulnerability discoverer is able to announce it and take credit for finding it.
I know that's what usually occurs, I just didn't notice that mentioned in the article for this particular vuln. Good to know they did that in this instance.
https://blog.qualys.com/vulnerabilities-threat-research/2023/10/03/cve-2023-4911-looney-tunables-local-privilege-escalation-in-the-glibcs-ld-so#disclosure-timeline
Qualys and Red Hat are pretty big names, so they'd be likely to follow the typical process.
Distro developers were notified a month ago. At least Redhat and Debian have have published fixed versions. This is common procedure.
Security through obscurity is never good.
It's better that vulnerabilities be discussed openly. In general, people knowing the truth allows them to make better decisions.
It's not only the good guys that find vulnerabilities. There're many states and companies (selling to those governments) as well as regular criminal organizations paying people for vulnerabilities and exploits.
If the issue wasn't reported, it is likely that it would have been found by someone else at some point. It might even be known already, but just not reported.