SoylentNews is people
SoylentNews
Ten-Year Old Sudo Vulnerability Gives Root Privileges on Host:
A major security hole in the Sudo utility could be abused by unprivileged users to gain root privileges on the vulnerable host, Qualys reports.
Designed to allow users to run programs with the security privileges of another user (by default superuser, hence the name, which is derived from 'superuser do'), Sudo is present in major Unix- and Linux-based operating systems out there.
Tracked as CVE-2021-3156, the recently identified vulnerability, which Qualys refers to as "Baron Samedit," was introduced in July 2011, and can be exploited to gain root privileges using a default Sudo configuration.
This means that an attacker able to compromise a low-privileged account on the machine could abuse the vulnerability to gain root access.
All legacy versions of Sudo, from 1.8.2 to 1.8.31p2, as well as the utility's stable releases from 1.9.0 to 1.9.5p1 are affected, in their default configuration.
[...] Qualys, which provides an in-depth technical analysis of the vulnerability, has published a proof-of-concept video to demonstrate how the issue can be exploited.
Also at Bleeping Computer.
CVE-2021-3156: Heap-Based Buffer Overflow in Sudo (Baron Samedit)
(Score: 1, Insightful) by Anonymous Coward on Thursday January 28 2021, @11:09AM (6 children)
I disagree, the exploitability of bugs like these are inherent to how computers work — it’s not specifically a problem with C. When you use a language like Go or Rust you are simply offloading this responsibility to someone else (the developers of that language).
(Score: 2) by engblom on Thursday January 28 2021, @12:04PM (3 children)
Of course a compiler will translate everything to "insecure" machine language, but those writing compilers are in general better programmers than Random Joe who just learned to program in C/C++ begun contributing to open source projects that I end up using. The fewer that have to touch C/C++ the better. My point is that there will always be bad programmers using C/C++ and even good programmers do occasionally a mistake. If we can reduce the places where these kind of bugs are, then we are better off.
(Score: 2) by HiThere on Thursday January 28 2021, @02:59PM (2 children)
C++ certainly has its problems, but Rust isn't that great a solution. Perhaps it depends on what you're doing.
For my taste the best programming language I ever encountered was version 1 of the D language shortly before those folk who like Java's style of I/O got their mitts into it. Version 2 is not nearly as good. (Others seem to like version 2 much better.)
Part of my problem is that there doesn't seem to be any language that really supports immutable message passing between threads that doesn't require everything to be immutable...which is a really bad idea for many purposes. Erlang is close, but mutating local data is a real PITA. (Basically you need to stick everything that needs to mutate into a hash table or database. Ugh.)
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by engblom on Thursday January 28 2021, @04:30PM (1 child)
My whole point in the OP of this thread was that we should put all effort to find a good solution. This problem with C/C++ is nothing new. We have had C for almost a half century and these problems with security been known for many decennials. It is an unforgivable situation that we still have not solved this. As I said earlier, if Rust is not good enough then efforts need to be put in making it good or then efforts needs to be put towards creating a better language that is still compatible with C, so you can replace part of the code without having to rewrite everything from scratch. Even Rust is several decennials too late as we have had this problem for so long time.
Why do big companies create programming language after programming language without caring about this? If we could sue MS, Apple, Google etc for shipping these kind of security problems in their OS I bet they would create a language that solves these problem. But now as they are not accountable for their products they do not care enough.
(Score: 2) by hendrikboom on Friday January 29 2021, @08:57PM
There are alternatives to Rust.
Consider Scheme. Specifically, the Gambit [umontreal.ca] implementation [umontreal.ca] of Scheme.
Its compiler generates C code from Scheme source, and explicitly permits you to specify what C code is to be generated for any new functions you define in your program should you wish to.
Compatible with C? Yes. You can even use it as a scripting language for existing C code if you desire. And it can be efficiently compiled all the way to machine code if you have a C compiler on hand.
(and it can also generate C++ if you need that)
Now I grant that this is a completely different kind of language from Rust, and is not likely to appeal to a lot of Rust programmers.
But it's clear that the space of potential C-compatible safe programming languages is vast and has hardly been explored.
(Score: 5, Insightful) by Grishnakh on Thursday January 28 2021, @05:43PM (1 child)
When you use a language like Go or Rust you are simply offloading this responsibility to someone else (the developers of that language).
Yes, and that's a good thing. The people writing compilers are generally much better programmers than the average programmers using those languages, and when the language devs fix a bug, suddenly that whole class of problem or vulnerability is eliminated for *all* programs compiled with that compiler, instead of countless average programmers having to go check their code manually.
(Score: 2, Insightful) by Anonymous Coward on Friday January 29 2021, @01:46AM
https://gcc.gnu.org/bugzilla/ [gnu.org]
Look here prior to fantasizing.
Note that some bugs in there stay unfixed for a decade or more.
Also note that people who modify sudo of all things, are *supposed* to be even more qualified, and more careful, than those who hack at compilers. Observe the fat lot of good it has done.
The ONLY way for such vulnerabilities not to crop up, is for people to STOP MONKEYING WITH THINGS THAT WORK and STOP PILING UP COMPLEXITY FOR THE SAKE OF IT.
Behold the commit that caused all this:
https://github.com/sudo-project/sudo/commit/8255ed69 [github.com]
" Go back to escaping the command args for "sudo -i" and "sudo -s"
before calling the plugin. Otherwise, spaces in the command args
are not treated properly. The sudoers plugin will unescape non-spaces
to make matching easier."
Plugins. In sudo. Need anything more be said?