Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Thursday January 28 2021, @07:31AM   Printer-friendly
from the hiding-in-plain-site dept.

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)

CVE-2021-3156


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by engblom on Thursday January 28 2021, @11:57AM (4 children)

    by engblom (556) on Thursday January 28 2021, @11:57AM (#1106016)

    Looked at the code. If the person who wrote it would have used std::string [cplusplus.com] he wouldn't have made the mistake. But having to use a C++ compiler or even linking with libstd++ is considered evil in the silly ideological minds of some C people.

    It's why they make stupid insecure code all the time: ideology.

    This is one of my points in the OP of this thread. There will always be C/C++ fans defending their programming language by telling that wrong technique or wrong library was used, but the reality is that as long as the compiler allows everything, then there will be people making the system insecure.

    Thus I stand by my view that I wish C would die out and that real effort would be put into replacing C and C++.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 3, Informative) by pvanhoof on Thursday January 28 2021, @12:09PM (3 children)

    by pvanhoof (4638) on Thursday January 28 2021, @12:09PM (#1106026) Homepage

    That real effort is called C++11 [wikipedia.org], C++14 [wikipedia.org] and C++17 [wikipedia.org].

    The C++ standards committee have adopted a gradual path towards a better C++.

    This isn't and easy hype or sell like "just do Rust" - whatevers. That doesn't work with a huge existing code base to continue supporting. Many of the new things in C++ are all about replacing old crap with much better techniques.

    In the field I do indeed see improvement in the overall code quality.

    I do know that there are people who want less features and less specification and whatnot. But they should indeed probably use C or just plain assembler. Plain assembler is the most easy programming language you can think of. Also Brainfuck [wikipedia.org] is quite nice having just eight points of specification. This entire specification fits on a 3M Post-IT note. Therefor it is the best programming language. Because its specification is super small. And that is good. Always good. Never bad. /sarcasm.

    • (Score: 3, Insightful) by HiThere on Thursday January 28 2021, @02:51PM (2 children)

      by HiThere (866) on Thursday January 28 2021, @02:51PM (#1106086) Journal

      Whether C++ is good or not depends on what you're doing. If you need bytes aligned in a struct (say for binary I/O) you need to go outside the specs to write the program. I think that there are always ways to specify alignment, but they aren't standard.

      It's also got the problem that it's insanely poorly documented. Not that it isn't documented exactly or completely, but that the documentation is poor. Python, Java, C, and several others have much better documentation. Even Ada is better. (With assembler you need to specify which assembler for which CPU, but some of them have better documentation...though usually less complete.) I've got 10 different C++ books, and sometimes I need to search through all of them, and also do a few web searches, to figure out how to use some part of C++. And occasionally the answer is "there is no standard way, but if you use this compiler, then you can use this approach".

      --
      Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
      • (Score: 2) by unauthorized on Thursday January 28 2021, @09:51PM

        by unauthorized (3776) on Thursday January 28 2021, @09:51PM (#1106302)

        There is a core language standard if cumbersome way to align data by manually packing and unpacking it into a byte buffer using bitwise operators to extract individual bytes from multibyte sequences. The actual "standard" way is to use Boost.

      • (Score: -1, Flamebait) by Anonymous Coward on Saturday January 30 2021, @03:03AM

        by Anonymous Coward on Saturday January 30 2021, @03:03AM (#1106788)

        Maybe you're just to stupid to understand a real language. Stick with your toy languages. They are easier. Oh, and only fucktard MORONS say "assembler." It's "assembly language." Assembler is a tool. What, do you call C, "compiler"?