[HN Gopher] Sudo-rs' first security audit
___________________________________________________________________
Sudo-rs' first security audit
Author : Argorak
Score : 41 points
Date : 2023-11-03 16:51 UTC (6 hours ago)
(HTM) web link (ferrous-systems.com)
(TXT) w3m dump (ferrous-systems.com)
| cedws wrote:
| 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/distrib/special/d...
| eep_social wrote:
| 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 sudo, so I'm not sure how your
| suggestion could be made practical.
| codetrotter wrote:
| > 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 from sudo to doas cold turkey
| years ago and haven't looked back.
|
| (On Linux I still use sudo, but that is simply because it
| comes pre-installed on the Linux distros I use so I haven't
| bothered to install doas instead there.)
|
| doas does exactly what I need; run the following command as
| root.
| eep_social wrote:
| 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.
| cedws wrote:
| >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.
| eep_social wrote:
| 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..
| cedws wrote:
| > we lose any ability to know who the "real" person-user
| is on top
|
| It's a complex topic probably best suited for discussion
| elsewhere, but do we even need to discern that anymore?
| Statistically most Linux systems running now are single-
| seat (as in, one _real_ user).
|
| A big corp with thousands of servers and employees might
| want to know this stuff for audit logging, but if
| employees have root access, they can already fake
| everything at ring 3. Big corps use security software
| that do that stuff in ring 0.
| e12e wrote:
| > if employees have root access
|
| The main usecase of sudo over su (or suid binaries) is
| limited access (clear/re-run the mail queue - not
| reconfigure the mail daemon)
| inferiorhuman wrote:
| On FreeBSD the only thing I miss from sudo is the
| credential caching. I believe opendoas uses the same fairly
| portable method that sudo does. doas uses an OpenBSD-
| specific API.
| e12e wrote:
| Users and groups (auth/autz) via kerberos/ldap/active
| directory? Radius?
|
| Not something "most users" would need - and probably
| handled in Pam, not sudo - but it's one thing that comes to
| mind.
| cedws wrote:
| >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 sudo are conceptually broken from a
| security POV because the user's shell can be played with to
| elevate privileges. The real fix is dump doas and sudo
| entirely.
| eep_social wrote:
| > 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.
| cedws wrote:
| 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.
| technion wrote:
| 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 fell over.
| eep_social wrote:
| 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.
| cedws wrote:
| >A while back I saw a guy name his windows desktop with an
| emoji and all sorts of software fell over.
|
| Presumably all of it was written in languages built on old
| assumptions that a single character is one byte.
| wrs wrote:
| It would be great to have an educational effort to that effect:
| if you don't need sudo, use doas.
|
| However, there are about six billion* things in existence right
| now that use sudo, so it's a good idea to make sudo safer as
| well.
|
| * rhetorical statistic
| xerxes901 wrote:
| This doesn't really change your conclusion, but I think that's
| the wrong file. This is the real doas afaict:
| https://github.com/openbsd/src/blob/master/usr.bin/doas/doas...
|
| Still just a tidy 1072 lines in that folder though.
|
| I spent 5 minutes staring at your file trying to understand how
| on earth it does the things in the man page, but of course it
| doesn't.
| cedws wrote:
| Thanks, you're right. I was surprised how sparse it was.
| biorach wrote:
| > 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?
| cedws wrote:
| Good question, never used it.
| trclst wrote:
| sudoedit would be an example.
| Karellen wrote:
| The ability to specify limited groups of commands that a
| subset of users can run, among other things.
|
| The "Examples" section of the sudoers(5) man page is probably
| a good place to start to get an idea of the sorts of ways it
| can be configured
|
| https://manpages.debian.org/bookworm/sudo/sudoers.5.en.html#.
| ..
| 0xbadcafebee wrote:
| You can live a _really_ simple life if you just stop using
| computers.
|
| Simple isn't always better.
| aliceryhl wrote:
| 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).
| comex wrote:
| > 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!
| Smaug123 wrote:
| 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.
| 3c6bYDXLMj wrote:
| Come off it. That's what the severity rating is for. Anyone
| used to reading these sorts of reports comes to expect these
| things. And someone saying "all you have to do, is simply..."
| doesn't change the fact that there's suddenly more effort
| involved.
| 0xbadcafebee wrote:
| 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 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.
|
| How interesting.
___________________________________________________________________
(page generated 2023-11-03 23:00 UTC)