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).
Sudo-rs' first security audit
11–20 of 63 posts
Re: Sudo-rs' first security audit
#12Earlier 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…
> 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.
Re: Sudo-rs' first security audit
#13Earlier quoted context omitted.
>Which parts are you thinking of removing? All of it. Seriously. doas demonstrates that sudo's primary function (running commands as another user) can be achieved in an order of magnitude less code and a significantly smaller attack surface. 90% of people don't need more than that, they don't need all the bells and whistles that sudo offers. We aren't in the 90s running on mainframes anymore. As an aside, doas and su…
> conceptually broken I agree, but the goal of this particular project is to make sudo as safe as possible. Within the stated goal, I don’t think significant LOC reduction is a feasible side quest. Evangelizing the removal of sudo entirely is an interesting thought but given how widely deployed it is, I see a ton of value in having a sudo-rs stopgap between now and then.
Sorry, yes, I think this work is useful, but I also think that sysadmins and distro maintainers should be starting to think about dropping sudo in favour of something simpler. Those who need sudo can still reach for it.
Re: Sudo-rs' first security audit
#14Earlier 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…
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.
Re: Sudo-rs' first security audit
#15Earlier 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.
>Removing the need entirely (as they are both conceptually broken) seems like a huge lift that’s probably not feasible without fundamental changes
A sort of workaround is that you can log in as the desired user from a TTY. Of course, this gets tricky if you don't have physical access or a remote serial connection. And you probably wouldn't want to log in as root over SSH. I don't have real solutions in mind but it's ticking over in my head. Might have some ideas later on.
Re: Sudo-rs' first security audit
#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 an open source project because you can just look at the source code. But if there were hypothetically a memory corruption vulnerability in sudo-rs, then an attacker would want to identify the specific machine code corresponding to the vulnerable source, in order to determine how it could be exploited. That wouldn't be too hard to achieve without symbols, but symbols would definitely make it easier.
Except… even if the binary has symbols stripped, you can just `apt install sudo-rs-dbgsym`, or use debuginfod, to get the full debug info including symbols and DWARF records. Because distros provide that for all their packages. As a feature. To assist debugging.
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.
So while it might save a tiny bit of disk space to strip the symbols, the security benefit is absolutely nil.
…Well, in theory anyway. In practice, Debian's sudo-rs package seems to be missing both a dbgsym package and reproducible build info. But that's a bug!
Re: Sudo-rs' first security audit
#17I 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?
Re: Sudo-rs' first security audit
#18Earlier 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.
>Removing the need entirely (as they are both conceptually broken) seems like a huge lift that’s probably not feasible without fundamental changes A sort of workaround is that you can log in as the desired user from a TTY. Of course, this gets tricky if you don't have physical access or a remote serial connection. And you probably wouldn't want to log in as root over SSH. I don't have real solutions in mind but it's…
Aye, but then we are (I think) sharing credentials so we can both log in as the user with specific (read: elevated) permissions, and we lose any ability to know who the “real” person-user is on top. So it’s a different problem and we’re starting to talk about threat models and such..
Re: Sudo-rs' first security audit
#19I 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?
Good question, never used it.
Re: Sudo-rs' first security audit
#20> 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…
That is what "low" means as a vulnerability severity! "Low" means "you totally don't need to do anything about this".
The reported property does make the attacker's job slightly harder, after all, since they need to go and work out where the symbols are rather than just having them right there in front of them.