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

41–50 of 63 posts

Re: Sudo-rs' first security audit

#41

Post by ncallaway »

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…

> It's almost as if changing to an entirely new programming language and ecosystem isn't enough to make a secure application, and that you still have to try hard to secure it, regardless of the language.

Has anyone argued that switching to Rust alone is sufficient to stop all security vulnerabilities?

Has anyone suggested that switching to Rust means you no longer need to do any work to write secure applications?

It seems to me you're arguing against a totally self-constructed straw-man.

Re: Sudo-rs' first security audit

#42

Post by viraptor »

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.

Re: Sudo-rs' first security audit

#43

Post by codetrotter »

mtlmtlmtlmtl wrote: post #33
comex wrote: post #16

> Description: The cargo release build does not strip symbols, so they will be included in the final binary. (..) Impact: Since the code is open source, there is not much information to be gained, but removing these symbols might make reverse engineering of the binary harder. What a ridiculous finding. I can try to steelman the argument. Sure, maybe "reverse engineering of the binary" is useless most of the time for…

If you can apt-get stuff, why would you be trying to exploit sudo? Even assuming apt-get was the only thing you could run as root, that would essentially allow arbitrary filesystem changes anyway. Escalating to full root from that would be trivial.

You don’t need to be root to retrieve the debug symbols from apt if the debug symbols were in the apt repository

Something like

    apt-get download sudo-rs-dbgsym

    mkdir -p ~/tmp/

    dpkg -x sudo-rs-dbgsym.deb ~/tmp/
should provide what you need I think

Re: Sudo-rs' first security audit

#44

Post by GauntletWizard »

kaba0 wrote: post #40
comex wrote: post #16

> Description: The cargo release build does not strip symbols, so they will be included in the final binary. (..) Impact: Since the code is open source, there is not much information to be gained, but removing these symbols might make reverse engineering of the binary harder. What a ridiculous finding. I can try to steelman the argument. Sure, maybe "reverse engineering of the binary" is useless most of the time for…

> 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.

Re: Sudo-rs' first security audit

#45

Post by RcouF1uZ4gsC »

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).

That vulnerability seems like something added to adhere to the rule of 3. In at least Western culture, we have this ingrained thing for groups of 3 - for example Trinity, 3 point outline, 3 sentences in a paragraph etc.

It seems like this was picked to end up with 3 vulnerabilities so the security researchers can feel they did a complete job.

Re: Sudo-rs' first security audit

#46

Post by yjftsjthsd-h »

eep_social wrote: post #12
codetrotter wrote: post #4

Earlier quoted context omitted.

> the doas comparison doesn’t really follow The real question is, do you really need everything that sudo can do? Or would doas be sufficient? On my FreeBSD servers, I install doas instead of sudo, and I have never once found myself missing any features in spite of having completely replaced sudo with doas on my FreeBSD servers. Replaced as in, I no longer even have sudo installed on my FreeBSD servers. I switched fr…

Right, I’d speculate that removing sudo for doas is a heavy but feasible lift at the distro level. But as I said elsethread, I’m also very interested in an as-safe-as-possible replacement between now and then. Removing the need entirely (as they are both conceptually broken) seems like a huge lift that’s probably not feasible without fundamental changes. Could it be done within POSIX? IDK but I’d guess not.

> Right, I’d speculate that removing sudo for doas is a heavy but feasible lift at the distro level.

Not that heavy a lift, at least as a default. AIUI Alpine switched to doas and moved sudo to the community repo, Arch supports both, Void supports both, and NixOS supports both. I wouldn't be surprised if there are more. Although, RHEL and SUSE would probably have a harder time because their customers are more likely to use sudo's long tail of features.

Re: Sudo-rs' first security audit

#47

Post by pixl97 »

eep_social wrote: post #14
technion wrote: post #10

Earlier quoted context omitted.

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…

Funny enough, my iphone has an emoji-only name and everything seems to work. I haven’t dared try with a machine I might want to ssh into though.

An emoji SSID can be hit and miss at times on what can detect it.

Re: Sudo-rs' first security audit

#48

Post by eep_social »

yjftsjthsd-h wrote: post #46
eep_social wrote: post #12

Earlier quoted context omitted.

Right, I’d speculate that removing sudo for doas is a heavy but feasible lift at the distro level. But as I said elsethread, I’m also very interested in an as-safe-as-possible replacement between now and then. Removing the need entirely (as they are both conceptually broken) seems like a huge lift that’s probably not feasible without fundamental changes. Could it be done within POSIX? IDK but I’d guess not.

> Right, I’d speculate that removing sudo for doas is a heavy but feasible lift at the distro level. Not that heavy a lift, at least as a default. AIUI Alpine switched to doas and moved sudo to the community repo, Arch supports both, Void supports both, and NixOS supports both. I wouldn't be surprised if there are more. Although, RHEL and SUSE would probably have a harder time because their customers are more likely…

I’m only vaguely aware of Alpine but that’s pretty neat!

Re: Sudo-rs' first security audit

#49

Post by eep_social »

pixl97 wrote: post #47
eep_social wrote: post #14

Earlier quoted context omitted.

Funny enough, my iphone has an emoji-only name and everything seems to work. I haven’t dared try with a machine I might want to ssh into though.

An emoji SSID can be hit and miss at times on what can detect it.

This is the actual device name, not just the network but that’s a good point. Tethering via the network manager GUI from a macbook works as expected with the network name same as device.

You got me curious so I checked arp -a which shows host name as a ?. Nmap also isn’t able to resolve the emoji name, neither is host, and I don’t think dns-sd either, though my mdns-fu is poor. I did test Terminal.app and I can echo an emoji so I’m guessing this is mostly a limitation of some of the ancient bsd utils that are packed with macos.

Thanks for the little rabbit hole!

Re: Sudo-rs' first security audit

#50

Post by ahefner »

biorach wrote: post #17
cedws wrote: post #2

I just ran tokei in the sudo-rs repository and there's over 28,000 lines of code not including whitespace. The Rust rewrite is a good step forward but we should really be asking ourselves if we need all this complexity in something so critical. OpenBSD's doas is 108 lines of C. sudo and doas are not equivalent in functionality, but it shows how simple things can really be. https://github.com/openbsd/src/blob/master/d…

> 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 eventually fixed the /etc/hosts file which the systemd thing had failed to do, and I still don't know why sudo wanted to look up this hostname over the network, or what bad things could've happened if one of the configured DNS servers had maliciously replied for it.
Post reply on HN