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

The first stable release of a memory safe sudo implementation

memorysafety.org

Post reply on HN
Print view View original

131–140 of 260 posts

Re: The first stable release of a memory safe sudo implementation

#131

Post by db-interface »

steveklabnik wrote: post #116
0xbadcafebee wrote: post #109

Earlier quoted context omitted.

[flagged]

> Recently a Rust sudo replacement (maybe this one?) got a security audit. It is the same one. It's weird because, this article is from August. But the one you're referencing is from three days ago: https://ferrous-systems.com/blog/sudo-rs-audit/ > the severity was worse in the Rust version. I am unsure where you got this. It's the same vulnerability.

The link you cite says it was worse in the Rust version:

> During the audit, it came to light that the original sudo implementation was also affected by [CLN-001: relative path traversal vulnerability], although with a lower security severity due to their use of the openat function.

Re: The first stable release of a memory safe sudo implementation

#132

Post by steveklabnik »

db-interface wrote: post #131
steveklabnik wrote: post #116

Earlier quoted context omitted.

> Recently a Rust sudo replacement (maybe this one?) got a security audit. It is the same one. It's weird because, this article is from August. But the one you're referencing is from three days ago: https://ferrous-systems.com/blog/sudo-rs-audit/ > the severity was worse in the Rust version. I am unsure where you got this. It's the same vulnerability.

The link you cite says it was worse in the Rust version: > During the audit, it came to light that the original sudo implementation was also affected by [CLN-001: relative path traversal vulnerability], although with a lower security severity due to their use of the openat function.

Thank you. I literally re-read it to try and find this, and missed it somehow. Guess I need to drink even more coffee.

Re: The first stable release of a memory safe sudo implementation

#134

Post by jwilk »

ndr wrote: post #126
tptacek wrote: post #99

Earlier quoted context omitted.

Whatever else happened in those 43 years, we had a widely-exploitable memory corruption vulnerability (Baron Samedit) as recently as 2021.

And it looks like it was a buffer overflow: https://blog.qualys.com/vulnerabilities-threat-research/2021... Would Rust prevent this?

Discussed on HN:

https://news.ycombinator.com/item?id=25919235 (321 comments)

Re: The first stable release of a memory safe sudo implementation

#135

Post by jwilk »

db-interface wrote: post #131
steveklabnik wrote: post #116

Earlier quoted context omitted.

> Recently a Rust sudo replacement (maybe this one?) got a security audit. It is the same one. It's weird because, this article is from August. But the one you're referencing is from three days ago: https://ferrous-systems.com/blog/sudo-rs-audit/ > the severity was worse in the Rust version. I am unsure where you got this. It's the same vulnerability.

The link you cite says it was worse in the Rust version: > During the audit, it came to light that the original sudo implementation was also affected by [CLN-001: relative path traversal vulnerability], although with a lower security severity due to their use of the openat function.

I don't see how openat() would help.

Re: The first stable release of a memory safe sudo implementation

#136

Post by jwilk »

steveklabnik wrote: post #116
0xbadcafebee wrote: post #109

Earlier quoted context omitted.

[flagged]

> Recently a Rust sudo replacement (maybe this one?) got a security audit. It is the same one. It's weird because, this article is from August. But the one you're referencing is from three days ago: https://ferrous-systems.com/blog/sudo-rs-audit/ > the severity was worse in the Rust version. I am unsure where you got this. It's the same vulnerability.

The audit discussed on HN:

https://news.ycombinator.com/item?id=38131442

Re: The first stable release of a memory safe sudo implementation

#137

Post by vlovich123 »

yakubin wrote: post #89
quotemstr wrote: post #48

Earlier quoted context omitted.

> Essentially what you really want is the sudo command to acquire a temporary capability token to edit that specific file. This should be doable with an XDG portal model, right?

It's doable by opening the file in a privileged process (sudo) and passing the file descriptor to a non-privileged process. Maybe one could make a sudoedit that opens a file in sudo process and then spawns a non-privileged editor process which inherits the file descriptor and is given the /dev/fd/ path on the command line, so it stays none the wiser about the whole process.

Sounds like a bit of recipe for accidentally handing access to an unintended privileged fd through inheritance (ignoring the /dev/fd one) such that a compromised unprivileged SUDO_EDITOR value gives you sudo access. Maybe not likely, but I’d really be hesitant about any feature that relies on implicit fd inheritance…

Re: The first stable release of a memory safe sudo implementation

#138

Post by __turbobrew__ »

yesimahuman wrote: post #82
nolok wrote: post #65

Earlier quoted context omitted.

The key is in "on the surface". While the common usage of sudo is fairly straightforward, you me and most people use like 5% of it. The trick is in all the side shows.

Makes you wonder then why it does so much, if those rarely used features increase the surface area of possible exploits? This is just a question I’ve had about *nix utilities in general, since sudo is hardly the only tool with obscure flags and features

This is part of what the openbsd ‘doas’ was trying to solve. They drastically reduced the functionality to reduce the attack surface.

Re: The first stable release of a memory safe sudo implementation

#139

Post by das_keyboard »

steveklabnik wrote: post #116
0xbadcafebee wrote: post #109

Earlier quoted context omitted.

[flagged]

> Recently a Rust sudo replacement (maybe this one?) got a security audit. It is the same one. It's weird because, this article is from August. But the one you're referencing is from three days ago: https://ferrous-systems.com/blog/sudo-rs-audit/ > the severity was worse in the Rust version. I am unsure where you got this. It's the same vulnerability.

Re: I am unsure where you got this. It's the same vulnerability.

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

Re: The first stable release of a memory safe sudo implementation

#140

Post by sgerenser »

coggs wrote: post #60

As one of the original creators of sudo ( https://en.wikipedia.org/wiki/Sudo ) I've witnessed it getting nearly totally rewritten and then incrementally bug-fixed over the last 43 years. It must take the prize for the UNIX command most highly-scrutinized for security flaws. Flaws which have been identified and fixed. Thousands of developers and security experts have gone over it. So part of me wonders - how is it pos…

It can eliminate many bugs, but it certainly wouldn’t eliminate all bugs. During implementation they realized they were not implementing sudo’s (undocumented) feature of failing to run if the sudoers file is world-writable: https://ferrous-systems.com/blog/testing-sudo-rs/.

Of course they did find and fix the bug, but in general Rust isn’t going to protect you from bugs like this that are essentially logic errors.

Post reply on HN