Earlier quoted context omitted.
Poettering to save the day with systemd-sudo?
Polkit-exec (pkexec) already exists, has much better security, and integrates with your DE instead of expecting passwords on the terminal.
Does it work without GUI?
Heap-based buffer overflow in Sudo
261–270 of 328 posts
Re: Heap-based buffer overflow in Sudo
#262Earlier quoted context omitted.
I can't possibly see how PAM was ever considered a good idea.
I mean, it's literally in the name: Pluggable Authentication Module. It's a very good idea to expose a common interface for user authentication to hide the vagaries of the underlying authentication mechanisms. It's far more useful to explain why or how PAM is bad, because no one (sane) will agree that the idea of PAM is bad.
Module should be implemented as a separate process running under unprivileged user and communication should be done via pipes. It's UNIX-way. If I understand it correctly, currently module is implemented as a shared library executing under root sharing all the memory with other modules and main program. This exposes way too many opportunities to exploit any vulnerability.
Re: Heap-based buffer overflow in Sudo
#263All you need to know about sudo and frankly most other pieces of the Linux userspace is that it is undertested. The commit that added this flaw to sudo claims to fix a parser bug but includes no tests. There is no reason for the author, the reviewer (if there even was such a person), or anyone else to believe that the bug existed or was fixed by this change. The pull request that supposedly fixes this CVE also includ…
> people who stubbornly refuse to practice even the most basic good engineering practices, like testing and code review
That is not fair. This software is maintained by Todd Miller, the well known OpenBSD developer, and has both tests and certainly discusses code proposals. Not everyone has to use github or the language de jour to be useful.
Re: Heap-based buffer overflow in Sudo
#264One of those programs that you should not install unless you really need them.
It is installed in Debian-minimal by default. I guess it's the same with many other distros. I don't understand why "minimal" installs sudo.
Re: Heap-based buffer overflow in Sudo
#265Earlier quoted context omitted.
But if sudo were written in Rust, it could have the same level of complexity and not be vulnerable. Yes, it would still be vulnerable to logic errors, like the last famous sudo bug where you pass -1 as the UID. But it wouldn't be vulnerable to this. (And this isn't the first memory safety bug to be found in sudo.) Yes, sudo's complexity is useless for 99.99% of its users. But wouldn't it be nice if the result were me…
If sudo were written in Perl, it would also not be vulnerable.
I thought about that. But when using a higher-level language (that comes with a runtime), you need to give privileges to the whole runtime, which arguably has a much bigger attack surface, unless I am mistaken?
The kernel won't allow you to setuid scripts, there is a reason for this: it's very easy to leave glaring security holes while doing so.
Re: Heap-based buffer overflow in Sudo
#266Memory safety strikes again, it seems (overflow in a C string due to complex parameter parsing rules).
No, complexity strikes again. I haven't used sudo in years, preferring to use doas now. Its essential code is less than 500 lines and it does everything I've ever used sudo for, and that includes much more than `sudo `. $ man doas | wc -l 58 $ man doas.conf | wc -l 101 $ man sudo | wc -l 741 $ man sudoers | wc -l 3254 And a bonus: $ man sudoers | grep -C1 despair The sudoers file grammar will be described below in Ex…
I agree about your point on complexity, that was my second thought. Especially for such critical pieces of infrastructure. Thank you for mentioning doa, I will have a look.
But the two are pieces of the same puzzle (defence in depth). Ideally, SUID binaries should be formally specified/verified (ada+spark?), though you could still have bugs in the specification.
And I'd argue that if you need more specific features than just `sudo`'s core functionality, you should probably just make your own setuid binary. That still exposes you to making the same mistakes, so better keep the complexity low, and still rely on a memory-safe language. Using proved, lightweight libraries helps getting an implementation correct.
As much as I like C (which is the language I'm most proficient with), it just gives you too many ways to shoot yourself in the foot, and IMO isn't really the best suited for something where:
- performance doesn't really matter
- memory safety, typechecking are critical.
You could always get away with a transpiler for a DSL, or a compiler that injects more checks, but better suited tools are available anyway.
Re: Heap-based buffer overflow in Sudo
#267Earlier quoted context omitted.
Even if we run the same math with 7 out of 10 bugs being memory safety related, and assuming that Rust prevents all of them, those same example programs end up with 30 bugs in Rust and 10 bugs in C. There's another argument I could make, too. Look at the bug tracker for the program you want to rewrite in Rust, examining the historical bugs. You'll find that there are often hundreds or thousands of mistakes that they…
> " Even if we run the same math with 7 out of 10 bugs being memory safety related, and assuming that Rust prevents all of them, those same example programs end up with 30 bugs in Rust and 10 bugs in C. " Maybe but not necessarily; it's reasonable to assume that Microsoft and FaceBook put non-zero effort into designing around, programming around, testing, looking for and fixing memory safety related issues in their C…
Similarly, it is possible that they would use the time to add new features with new bugs. I'd personally suspect that to be the more common outcome.
Re: Heap-based buffer overflow in Sudo
#268Earlier quoted context omitted.
Perhaps indeed! But a crucial distinction is that I consider the complexity in the langauge, compiler, and standard library to all be influences on your program's total complexity as well. Using std::List (or whatever you call it) has the same total complexity as writing your own little growable array.
From the point of view of bugginess, complexity in the implementations of massively popular libraries is far less of an issue than code you just wrote yourself, because the code in those libraries will have received much more testing than the code you just wrote yourself. So it doesn't really make sense to just add the complexity of components up like that.
sudo is quite a popular utility, by the same logic it might be expected to be well tested...
Re: Heap-based buffer overflow in Sudo
#269Earlier quoted context omitted.
Todd Miller is a sharp developer and core OpenBSD contributor. I can only imagine the deluge of requests and pressure he faces to expand sudo. There's no end to the crazy stuff corporations demand, especially when it comes to integration--audit, logging, ldap, etc.
> Todd Miller is a sharp developer and core OpenBSD contributor. I wonder why OpenBSD wrote their own version. Could it be that, knowing how the sausage is made, they thought it was better to have a salad...?
> I wonder why OpenBSD wrote their own version.
With most other projects, I would smell a major case of Not-Invented-Here, but the OpenBSD developers seem to have an impressive track record of actually learning from mistakes, both from their own and those made by others.
> knowing how the sausage is made, they thought it was better to have a salad
I love that phrase! (Coincidentally, an engineer working in food processing once explained to me how chicken nuggets are made (while we were eating!), I have mostly avoided them ever since...)
Re: Heap-based buffer overflow in Sudo
#270"rewrite sudo in Rust" in 3,2...
Or just recompile sudo with -fsanitize=address
This guarantees you a local root exploit:
https://seclists.org/oss-sec/2016/q1/363