Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sudo-rs' first security audit

ferrous-systems.com

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Sudo-rs' first security audit

#51

Post by g-b-r »

ahefner wrote: post #50
biorach wrote: post #17

Earlier quoted context omitted.

> we should really be asking ourselves if we need all this complexity in something so critical What is all the complexity? What is all the extra functionality that sudo offers?

So I inherited a machine in our lab last week (not a "production" or "test" server, just a random machine being used as a dev environment) and decided to change its hostname using systemd's hostnamectl. Subsequently every attempt to execute a command via 'sudo' caused it to hang for multiple tens of seconds before declaring it couldn't resolve the new (nonexistent, entirely local) hostname. This persisted until I eve…

Have you checked the sudoers?

Re: Sudo-rs' first security audit

#52

Post by kaba0 »

GauntletWizard wrote: post #44
kaba0 wrote: post #40

Earlier quoted context omitted.

> Even if distros didn't distribute debug symbols, today's security best practices include reproducible builds, which means you should be able to rebuild the package yourself and get the exact same binary, plus the symbols Well, that’s why binary randomization/fuzzing is an important security research topic. If everyone would be running semantically identical, but not binary-identical programs, a ROP-based vulnerabil…

This is the very definition of security through obscurity. If everyone were running "semantically identical, but not binary-identical programs" there would be debugging tools to automatically patch your patches for each target device.

How would that work with fuzzing at the compiler step, say, inlining a non-critical function at a place in one place but not in the other?

This is a real security topic, don’t handwave it away without knowing about it.

Re: Sudo-rs' first security audit

#54

Post by GauntletWizard »

kaba0 wrote: post #52
GauntletWizard wrote: post #44

Earlier quoted context omitted.

This is the very definition of security through obscurity. If everyone were running "semantically identical, but not binary-identical programs" there would be debugging tools to automatically patch your patches for each target device.

How would that work with fuzzing at the compiler step, say, inlining a non-critical function at a place in one place but not in the other? This is a real security topic, don’t handwave it away without knowing about it.

The same way any decompilation works - By looking at patterns, understanding how the original compiler worked, and following the execution path as it runs. Antimalware analysts have been doing far more complex for many years, including packed, encrypted, and self-modifying code. It temporarily obfuscates what's going on, but execution tells all. Not that you'd need anything that advanced, when you have the source code and can compare possible fuzzed outputs.

ASLR is a real technique that can make targets harder to pop on the first try, giving you time to detect the problem. It does not prevent bugs from being exploited, at least not reliably and for long. This is not a real security topic, this is minor roadbumps, urban myth, and quackery.

Re: Sudo-rs' first security audit

#55

Post by thiht »

aliceryhl wrote: post #11

I'm surprised that CLN-003 made the list even as low severity. It's intended to make reverse engineering of the binary harder, but the code is already freely accessible (and CLN-003 also acknowledges this).

I see it as a note to be exhaustive. It’s the kind of thing if you don’t add it to your report, some smart ass WILL say something like « actually they forgot about the bin symbols, how could they miss this? ». There’s always someone like this.

Re: Sudo-rs' first security audit

#56

Post by kaba0 »

GauntletWizard wrote: post #54
kaba0 wrote: post #52

Earlier quoted context omitted.

How would that work with fuzzing at the compiler step, say, inlining a non-critical function at a place in one place but not in the other? This is a real security topic, don’t handwave it away without knowing about it.

The same way any decompilation works - By looking at patterns, understanding how the original compiler worked, and following the execution path as it runs. Antimalware analysts have been doing far more complex for many years, including packed, encrypted, and self-modifying code. It temporarily obfuscates what's going on, but execution tells all. Not that you'd need anything that advanced, when you have the source cod…

So with some insane amount of reverse engineering you can exploit a vulnerability on a single instance of the target program, which same exploit won’t run on another.

You can, starting from essentially scratch, also create a vulnerability for a separate instance, but it literally stops the spreading of a same malware exploiting multiple computers. How is that not security, and just obscurity? Is this not a valid threat model?

Re: Sudo-rs' first security audit

#57

Post by Karellen »

technion wrote: post #10
eep_social wrote: post #3

Earlier quoted context omitted.

Which parts are you thinking of removing? The goal is “to build a drop-in replacement for all common use cases of sudo” so the doas comparison doesn’t really follow. The fabulous article mentions that, “sudo-rs only has 3 dependencies in its dependency graph” so maybe they could trade loc for deps but that doesn’t seem wise to me. The audit found one moderate path traversal vulnerability which was also present in og…

I think the one moderate vulnerability is an example of this. I have serious doubts about anyone having wanted to use that remove timestamps parameter in 2023. I'd be surprised if many people know it exists. I more surprised an os would let you make a user with "../../" in the name though. I'd bet a heap of things would break. A while back I saw a guy name his windows desktop with an emoji and all sorts of software f…

> I more surprised an os would let you make a user with "../../" in the name though.

There may be protections at some levels, but eventually a username is just an entry in a database. Admittedly, you do have to be on the other side of the airtight hatchway to do it, but modifying a line in /etc/passwd to have the field before the first ":" be "../../" is something the os can't really do much about once it's there.

Re: Sudo-rs' first security audit

#58

Post by mtlmtlmtlmtl »

g-b-r wrote: post #53

The arbitrary delete vulnerability scared me at first, but are there really situations where a non-root user can create a new user??

In practice, I doubt it. But sudo offers highly granular permission controls. You can permit a user to only run certain commands as root. So it is a real vuln in the sense that if you give someone that ability, you've now given them more than intended.

Re: Sudo-rs' first security audit

#59

Post by 0xbadcafebee »

viraptor wrote: post #42
0xbadcafebee wrote: post #28

CLN-001: relative path traversal vulnerability (moderate) During the audit, it came to light that the original sudo implementation was also affected by this issue, although with a lower security severity due to their use of the openat function. I thought Rust was secure? How is it possible to write a program in Rust and still have the same security vulnerabilities, and actually be higher severity? It's almost as if c…

That's a low quality troll. Nobody was saying rust solves all security issues.

It's hilarious that people invented an entirely new language to prevent a single attack vector. That's like learning Perl because it has no buffer overflows.

Re: Sudo-rs' first security audit

#60

Post by viraptor »

0xbadcafebee wrote: post #59
viraptor wrote: post #42

Earlier quoted context omitted.

That's a low quality troll. Nobody was saying rust solves all security issues.

It's hilarious that people invented an entirely new language to prevent a single attack vector. That's like learning Perl because it has no buffer overflows.

Come on, you're not even good at this. Have you considered doing something productive with your time instead?
Post reply on HN