359
Root access vulnerability in glibc library impacts many Linux distros
(securityaffairs.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 31 Jan 2024
359 points (98.6% liked)
Linux
48335 readers
437 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Let's go Musl!
Doesn't compile where musl does.
While there may be challenges and specific configurations required, you absolutely can compile Rust on and targeting to a musl-based system.
I meant, Rust suppports vewer architectures.
Rust actually supports most architectures(SPARC, AMD64/x86-64, ARM, PowerPC, RISC-V, and AMDGPU*). The limitations are from LLVM not supporting some architects(Alpha, SuperH, and VAX) and some instruction sets(sse2, etc.); z/Architecture is a bit of an outlier that has major challenges to overcome for LLVM-Rust. This is not going to be a problem when GCC-Rust is finished.
AMDGPU, *Not 100%, but works well enough to actually use in production and gets better all the time.
Thanks! My bad, sorry.
Np. It's a common point of confusion.
You can use
rustup target listto see all available architectures and targets.Yeah Musl is pretty good to learn C libs but the main red flag is the MIT Licence
Why? MIT is more liberal than GPL. Why is it a red flag?
At a time where proprietary software is becoming more and more nasty and prevalent, on top of what has always accompanied it, we shouldn't be letting proprietary software developers take advantage of free code only to lock theirs away as proprietary. It advantages nobody except proprietary devs, who don't have the users at heart.
The goal of the GPL is to fight that.
The problem with pushover licenses like MIT in this case is that a lot of this software is designed to displace copylefted code. And when it does, you lose the protection of copyleft in that particular area and all of a sudden proprietary software gets a leg up on us. It's bad for software freedom and the users by extension, and good for proprietary software developers.
But the licence is chosen by the software author - unless that right to choose is taken away by a viral licence like the GPL, of course. In any case, I licence everything I write that I can as 3-clause BSD because I don't give a fuck. I wrote the software for me, and it costs me nothing if it's used by a shitty proprietary software stealer, or a noble OSS developer. Neither of them are paying me.
OSS should, is, and eventually will drive for-pay software to extinction, and it should do it through merit, not some legal trickery.
You're missing the point. Yes, the license is chosen by the author, but if that pushover licensed software becomes favoured over copyleft software, then proprietary software has a leg up as I explained. That's it.
GPL is also not a "viral" license, because that would imply that it seeks out and infects anything it can find. But developers choose which code they use, it doesn't just appear in their own code without permission. So a better analogy would be "spiderplant" license, since you're taking part of a GPL program (a spiderplant), and putting it in your own (where the GPLs influence "grows" to). That is completely the software developers decision and not like a virus at all.
It might not cost you anything personally if a proprietary developer usurps your code, but it does cost overall user freedom and increases proprietary dominance, where copyleft licenses would have done the opposite if your code was worth using. For that reason, I like strong copyleft. But by all means, keep using the license you want to, as long as it's not proprietary I won't judge. This is just my thoughts.
The point of free/open source licenses isn't to remove money from software either, it's perfectly possible to sell libre software. It's about what the recipients of that software have the freedom to do with it, and not giving the developer control over their users. We should serve the community, not betray them.
Lastly, although free alternatives are often technically superior to their closed-source competitors, at the end of the day, if you have a slightly faster program which does nasty spying, locking of functionality, etc, and a slightly slower program which does not, I'd be inclined to say that the slower program should be preferred by virtue that it does not do nasty things to it's users, and that then you won't be supporting such behaviour.
I am 100% in agreement with you here. While I'm not by any means a Libertarian, I prefer MIT and BSD licenses because they are truely free. The GPL is not: it removes freedoms. Now, you argue that limiting freedom can be a net good - we limit the freedom to rape and murder, and that's good. I don't agree that the freedoms the GPL removes are equivalent, and can indeed be harmful.
I don't mind others using the GPL, but I won't.
We can agree to disagree on the freedom point. The only "freedom" I see being taken away with the GPL is the removing of the freedom of other people.
I don't mind the MIT/BSD licenses, but I won't use them. We can agree on that.
I get is more liberal which I understand why. But that means that changes to the software do not need to be shared. Which for normal users it really does not matter. But again we are giving to multi corporations so much in exchange of nothing. When again they don't treat their users the same way.
MIT is a good licence as an idea. In reality, multi corporations are evil AF. The idea of free software in a sense is that free software can get so much better than privative one, eventually forcing privative companies to implement it them self on their programs.
If giving and taking was 1:1 in software community then again, MIT license is perfect. In reality it isn't. For major programs that have a lot of implication on new programs I do not recommend MIT and similar. For feature like projects is totally okay IMO.
I respect your opinion on this, and will say only one more thing: having worked in the corporate software space for decades, you don't want their software. Most of it is utter crap. It's a consequence of finance having too much indirect influence, high turnover, a lot of really uninspired and mediocre developers, and a lack of the fundamentally evolutionary pressures that exist in OSS. The only thing corporations do better is marketting.
The vulnerability is on logs, and that has nothing related to the library. Even less with the language...
The vulnerability is in the library's logging function, which is coded in the C language. musl is also C (afaik), it's just a more modern, safer rewrite of libc.
I'm not sure what you mean by a "vulnerability in the logs". In a logger or parser, sure, but did you think text data at rest was able to reach out and attack your system?
True, the logging is part of the library, but it's totally centered on what the developers are logging. It's a bad practice to log sensitive information, which can be used by someone with access to the logs for sure, but that doesn't mean the library is broken and has to be replaced. The library's logs need to be audited, and this as true for glibc as it is for musl, no exception, and it's not a one time thing, since as the libraries evolve, sensitive information can be introduced unintentionally (perhaps debugging something required it on some particular testing, and it was forgotten there).
BTW, what I meant with the language, is that no matter the language, you might unintentionally allow some sensitive information in the logs, because that's not a syntactic error, and it's not violating any compiling rules. It's that something is logged that shouldn't.
Also, the report indicates that the vulnerability can't be exploited remotely, which reduces the risk for several systems...
The vulnerability has nothing to do with accidentally logging sensitive information, but crafting a special payload to be logged which gets glibc to write memory it isn't supposed to write into because it didn't allocate memory properly. glibc goes too far outside of the scope of its allocation and writes into other memory regions, which an attacked could carefully hand craft to look how they want.
Other languages wouldn't have this issue because
they wouldn't willy nilly allocate a pointer directly like this, but rather make a safer abstraction type on top (like a C++ vector), and
they'd have bounds checking when the compiler can't prove you can go outside of valid memory regions. (Manually calling .at() in C++, or even better - using a language like rust which makes bounds checks default and unchecked access be opt in with a special method).
Edit: C's bad security is well known - it's the primary motivator for introducing rust into the kernel. Google / Microsoft both report 70% of their security vulnerabilities come from C specific issues, curl maintainer talks about how they use different sanitizers and best practices and still run into the same issues, and even ubiquitous and security critical libraries and tools like sudo + polkit suffer from them regularly.
I see, I didn't dig into the cause, being sort of a buffer overflow. Indeed that would be prevented by other languages, sorry for my misinterpretation. Other vulnerabilities unintentionally introduced by developers on logging what shouldn't are not dependent on anything other than auditing them, but that was not the case then.
musl is not a programming language
That's why I said library or language (someone else suggested rust).