
Sudo vulnerability - breadandcrumbel
https://www.openwall.com/lists/oss-security/2019/10/14/1
======
marcan_42
This is already two week old news, and it affects an extremely limited number
of systems. Almost nobody should be using a configuration that is vulnerable,
so the number of impacted systems is negligible. You don't have to care about
this bug, really.

The bug can be more simply restated as follows: if you allow a user to sudo to
the unnamed user ID '-1', you also allow them to sudo to root.

Since the user ID -1 isn't a real thing, this only ever happens if you allow a
user to sudo as _anyone_ , including root. Then for the bug to matter, you
have to _explicitly exclude_ root. This is an extremely weird configuration.
It makes little to no sense.

In fact, it's quite likely that if you're using such a config, you're already
vulnerable to privilege escalation anyway, without any sudo bugs. For example,
on many systems, the 'adm' user can write to raw disk devices, and thus give
itself root access by directly modifying the filesystem. If you use an 'anyone
but root' rule on such a system, then it's trivial to escalate to root anyway.

------
slovenlyrobot
For anyone with a modicum of C spending any amount of time in the sudo
codebase, this isn't much surprise. It's the scariest piece of organically
grown security-sensitive code I'm aware of still in popular use. It's jam-
packed with features you've never even heard of, and has quite surprising
functional changes across versions that never make the changelog and require
diffing to discover.

It's hard to quantify that "this code is obviously wrong" feeling, for example
liberal intermixing of concerns within a single procedure in many places of
the code. Options with little to no security value (requiretty) documented as
if they do, the ability to pass control to user-supplied policy plug-ins from
a setuid binary, etc. There is just far too much going on to expect it not to
regularly break

Ignoring the implementation, I think it's fair to say sudo is broken in
concept, simply by trying to have this kind of expressive policy language in
the first place. The set of skills required to safely expose some subset of
functionality to an untrustworthy user is perfectly distinct from those
involved in typical sysadmin.

~~~
mehrdadn
> Ignoring the implementation, I think it's fair to say sudo is broken in
> concept

IMO you're not going far enough. The whole UNIX setuid notion is fundamentally
broken to me. The ability to execute a file should logically have nothing to
do with the permissions granted to you when doing so. Windows gets this right.

~~~
iancarroll
How does Windows get it right? Windows has User Account Control for UI apps,
which is a “security” feature that they refuse to fix bypasses in.

~~~
minitech
Which UAC bypasses have they refused to fix?

~~~
mehrdadn
He's probably referring to [1], but he's wrong about UAC (note the sentence _"
UAC is not a security feature"_ on that post—the fact that he himself had to
put quotes around "security" is itself telling), and moreover, I never claimed
anything about UAC in the first place. He's ignoring my point and changing the
topic, so I'm not inclined to reply.

[1]
[https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94...](https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94105)

~~~
iancarroll
I don't know why this reply is so hostile, but I was curious what part of
Windows you were referring to if not UAC, because I don't know of anything
else.

There is an almost comical list of bypasses in built-in AutoElevate programs
that Microsoft does not triage as security bugs because as you note they don't
call UAC a security feature. I think this is a rather silly deflection that
users are unlikely to understand, for good reason.

~~~
mehrdadn
I wasn't referring to a "part" at all. What I said Windows gets right was a
very fundamental _architectural design_ : the decision to _not_ grant
privileges to a process based on the file it's executing (the callee), but
rather based on the caller's execution context.

Note, in particular, that there was _nothing_ in my comment that depended on
the existence of UAC. Had I written my comment before UAC even existed (say,
in the XP era), it would've been exactly the same.

Yet somehow you managed to change the subject of discussion to a very specific
feature UAC, a feature that was only introduced around the Vista era and which
I had not even mentioned in my comment once. Then you bashed it based on a
premise that you already _knew_ was incorrect and therefore had to put in
quotes, and then continued as if the point I had been making in my comment all
along was to somehow _endorse_ the use of this controversial feature I never
mentioned for a purpose that it itself had _not_ been intended. This is _not_
a faithful representation of what I wrote.

------
Exuma
I love the logo for Sudo

[https://www.sudo.ws/sudo/images/sudo-
logo-65.png](https://www.sudo.ws/sudo/images/sudo-logo-65.png)

~~~
bonoboTP
It's a reference to [https://xkcd.com/149/](https://xkcd.com/149/) right?

~~~
Exuma
Damn... that makes it even funnier.

------
newnewpdro
Sudo has too much surface area for a suid utility IMHO, unnecessary pile of
features, config parsing, etc.

I still just use `su` with the wheel group membership executable requirement
for gaining root privileges from my regular user.

But sudo has become quite entrenched, almost every software deployment guide I
see expects sudo, many scripts outright break on the assumption of sudo being
present.

Do you know the list of suid binaries installed on your machine?

`find / -perm -4000 -printf '%#m %u %p\n'`

~~~
isostatic
We have an ever changing group of about 60 engineers who need the ability to
do rooty style things on about 500 different machines (very few of which are
the same, so things like ansible don't work too well). While only a handful
actually do, the rest need to be able to, and they're trusted to make the
call.

However we still want to know what's going on, and sudo fires back a message
to syslog with who did it and what they did. Far more useful than "joebloggs
went to root at 03:14 and logged out at 09:15"

~~~
jlgaddis
If you take the time (once) to configure it correctly, _auditd_ can tell you
much, much more than just what commands were executed (and "hiding" the
commands you ran via _sudo_ is fairly trivial, if one is so inclined).

~~~
isostatic
Wouldn't that simply say "root did this at this time", and maybe "on this
pts", and then I'd have to marry that up with who was logged on at the given
pts at that time?

Either way we don't sue sudo to enforce security -- anyone could go and reboot
the machine physically in any case, we use sudo so we remember what we did, or
can quickly find the person who did it. Same with physical security, we don't
stop people from pulling the plug, but if the plug is pulled we can see who
was probably in the room at the time. You can work around it (by going in with
a colleague) if you wanted to hide your tracks, but people don't hide their
tracks.

Of course the other benefit of sudo is to reduce the number of terminals
logged in as root, where accidents can easilly happen.

------
tyingq
It's interesting to me that sudo is so ubiquitous versus the alternatives. I
remember "super" being a somewhat popular alternative in the 90's, but that
faded.

Some others: [https://www.sudo.ws/other.html](https://www.sudo.ws/other.html)

~~~
AdmiralAsshat
Company I used to work for had an elevated user they'd create on supported
customer systems literally called "backdoor". Needless to say, that raised
some eyebrows during the audits.

------
noncoml
For the curious, this is the patch that fixes it:
[https://www.sudo.ws/repos/sudo/rev/83db8dba09e7](https://www.sudo.ws/repos/sudo/rev/83db8dba09e7)

------
fortran77
I have a hard time understanding this explanation:

> For example, it can be used by a local user who wants to run commands as
> root — the windows equivalent of admin user.

"root" is the "windows equivalent" of "admin user"?

But then he talks about rules where you give someone the "sudo" permission to
run a command as anyone _other_ than root

> jacob myhost = (ALL, !root) /usr/bin/chmod

> This entry means that user jacob is allowed to run “chmod” as any user
> except the root user, meaning a security policy is in place in order to
> limit access — sounds good, right?

So that means "sudo" is a way to run a command as a different user, which may
or may not be root depending on policy.

~~~
jwilk
> "sudo" is a way to run a command as a different user, which may or may not
> be root depending on policy.

Correct.

Letting a normal user run commands as root is the most common use-case for
sudo, which is why it was mentioned as an example earlier.

The bug does not trigger in this common setup, only in a quite unusual one
mentioned later. Perhaps that should have been said explicitly.

------
commandersaki
The underlying issue in my opinion is the terrible interface of setresuid(2):
[http://man7.org/linux/man-
pages/man2/setresuid.2.html](http://man7.org/linux/man-
pages/man2/setresuid.2.html)

------
svnpenn
No date at all in the article. It helps to have that for context.

~~~
bad-joke
That confused me too. Internet Archive has earliest at 10/17/2019[1] and the
page contains a link[2] to the Sudo team security alert on 10/14/2019.

[1]
[https://web.archive.org/web/20191017233613/https://resources...](https://web.archive.org/web/20191017233613/https://resources.whitesourcesoftware.com/blog-
whitesource/new-vulnerability-in-sudo-cve-2019-14287) [2]
[https://www.sudo.ws/alerts/minus_1_uid.html](https://www.sudo.ws/alerts/minus_1_uid.html)

~~~
breadandcrumbel
Does Web Archive screenshoot all the webpages out-there every day? If there is
few days gap between each site screenshoot it might be the answer

------
ignoranceprior
How should Mac OS users update sudo?

~~~
stouset
I am pretty confident in stating that this bug impacts roughly zero macOS
systems globally.

------
kdbg
The original announcement email does a much better job of explaining the
actual vulnerability, and the configuration under which its an issue (using
ALL and !root in the runas part of the sudoers entry)

[https://www.openwall.com/lists/oss-
security/2019/10/14/1](https://www.openwall.com/lists/oss-
security/2019/10/14/1)

This writeup does little to explain the issue beyond showing a config line
that is vulnerable (but doesn't really explain which part makes it
vulnerable). It also incorrectly states the issue is sudo failing to parse the
value correctly.

> the function fails to parse all values correctly and when giving the
> parameter user id “-1” or its unsigned number “4294967295”, the command will
> run as root, bypassing the security policy entry we set in the example
> above.

Which is incorrect, sudo parses the value just fine, the issue comes from the
`setresuid` and `setreuid` calls. Both treat -1 as a special case that means
the corresponding value should not be modified.[0][1]

I mean, sure this article gets the key point that -u#-1 gets you root, but if
you're explaining a vulnerability I'd expect the technical details to be
correct.

[0] [http://man7.org/linux/man-
pages/man2/setresuid.2.html](http://man7.org/linux/man-
pages/man2/setresuid.2.html)

[1] [http://man7.org/linux/man-
pages/man2/setreuid.2.html](http://man7.org/linux/man-
pages/man2/setreuid.2.html)

~~~
breadandcrumbel
I googled the writer name ( Daniel Elkabes, Lead Security Researcher ) Found
his Linkedin and sent him a screenshoot of your feedback

That's the kind of feedback that can improve the writing skill of the author

Edit: Now I'm actually thinking that not every person know how to accept
negative feedback and see it as something positve

I know that I would like to see this feedback if I was the author so I felt
like sending it.

~~~
gregoryl
You should be safe to assume anyone sitting in a lead role should be very
comfortable with negative feedback, I'd not stress.

~~~
asveikau
It would be nice to imagine the world as it should be, but I don't think this
is actually super common.

------
WC3w6pXxgGd
Pretty big oversight to not handle -1 or 2³².

------
fortran77
How can bugs like this be prevented? Is Linix/Unix "sudo" security model
simply flawed?

~~~
asveikau
Not rust, but the OpenBSD folks wrote doas(1).

Also I am not sure how rust solves this bug, I don't think it's about memory
safety is it? This is about passing -1 from a config file to a syscall, and
sudo not validating the value or it being written without the understanding of
what -1 means to that syscall. Nothing is mis-parsed, no buffers overflowed,
etc.

~~~
marcan_42
It's a type confusion mistake (-1, meaning "no user ID", being the same type
as an actual user ID). Idiomatic Rust would largely prevent this kind of
mistake (you'd use an enum type, with a distinct value for "no user"), as long
as someone first writes an idiomatic Rust wrapper for the syscalls.

Obviously, if you write the Rust the same way you'd write the C, then yeah,
the mistake is equally likely to happen. Rust _encourages_ style that avoids
this kind of problem, but it can't enforce it.

~~~
asveikau
So supposing you have a type that can either be a uid_t or no value... Can you
specify that the high bit on the uid_t cannot be set? I.e. prevent an explicit
stuffing of negative values (or unsigned values that are bit-identical to
negative ones in the corresponding signed types) into such a type?

That is the most explicit way I can think of to block this with a type system.
If uid_t is 32 bits, you need a type that can either contain 31 bits or no
value, to prevent that 32nd bit being stuffed into the syscall somehow.

------
keyle
Personally I'm amazed that this is only discovered today. Wink wink nudge
nudge.

