Q: Security issue? Gaining root is ridiculously easy.

Well, this is a standard user. The first user created when installing OS X has the ability to use sudo to elevate privileges.

Jesse, did you try reproducing this? AFAICT, this was not due to me having brewed coreutils or anything, but I do have a ton of custom stuff on my system, so it might just be my bad OS.

Judging from your response, you're a power user, so if you could replicate my findings, that'd be awesome

Thanks!

Okay, my bad for improper semantics. What I meant by "standard" was that it's the type of user that is created whenever someone starts using their Mac.

So, to put it properly: Everyone will have this type of user after setting up their computer, and unless they're extremely vigilant and want to jump through hoops on a daily basis, they'll also be logged in as this user

Hi etresoft,

The sudo command isn't just for advanced users. It is also indirectly called by apps that require root access to do stuff (e.g. write images to USB sticks, mount encrypted partitions, etc.). The fact that it does this via a graphical user interface doesn't change the fact that it triggers a sudo session in the background which can be hijacked very easily (if you're logged in the way that arguably 99+% of Mac users are).

Also, I don't agree with you that, "the expectation is that they know what else is running on their system at all times." That would just be a blanket excuse someone could apply anywhere to not bother dealing with security in one's own code. I don't remember sudo behaving this way when I used to run Linux as a desktop OS.

Don't know what you mean by, "There are timestamp directories in /var/db/sudo as expected. There just isn't any $username variable."?

Cheers

Okay, first of all, let's get real here. I know of zero Mac users (including everyone at every place I've ever worked) who have created an extra, underprivileged user after having set up their Mac and logged in with the sudo-enabled user that is created by default, and is currently using that user to log in with. The majority of people don't know how to do that, let alone why they might want to.

I know how to do that, but seriously can't be bothered having to deal with user switching throughout the day while developing and whatnot. And I shouldn't have to to avoid the issue I'm talking about right here. We can agree all day that your using a less privileged user for your sessions is more secure. But the reality is, that pretty much no one is. And if I'm interested in exploiting a vulnerability to get access to sensitive data en masse, I'm much more interested in the majority and the defaults than I am about seeking out people utilizing better practices.

Now, back to the actual point.

Barney-15E wrote:

 

However, how does this become an exploit. You have the ability to elevate your user's privileges. How does another user (i.e. Hacker) use your user to exploit this. Another user (i.e. Another process running on the Mac) can't exploit this so I'm not sure how it is a problem. If someone hacks into your Mac and logs in as your user, it doesn't matter whether there is a timeout or not.

No — that's exactly what I'm describing. The way sudo works (at least on my Capitan installation, which is why I'm posting here, since I haven't ruled out that it's just my system that's broken (please replicate if you can, and report back )) is that the "no-password-reprompt timeout period" is global. It's not local to whichever process owns the initial sudo elevation.

In your example script, your user is still running that script, it is not some rogue process.

No. My user is running the script, but once it detects that that user has successfully executed sudo anywhere else, it immediately issues a now password-prompt-free sudo elevated command which writes, as root:wheel, to the root of the filesystem. Any running app can monitor the syslog and issue shell commands as the user it runs under with the user being none the wiser. By waiting for the right time, it can gain root control without triggering any flags.

I haven't actually tested if a privilege elevation in a GUI app might somehow be exempt from this behavior, but I suspect not. I'll try right now with TrueCrypt.

Please, if you don't mind, do try to replicate the behavior from my original post on your system to see if it's just local to my installation. I really hope it is

EDIT: I just tried to piggy-back from Terminal on a sudo which is executed through the TrueCrypt GUI. If you tell TC to mount an encrypted device, it'll prompt for your password in order to get the required root privileges to access block devices. Interesting result (although it makes perfect sense):

TrueCrypt will first try to use sudo without a password. This generates a syslog sudo incident about "1 incorrect password attempt". TrueCrypt reacts on that by showing the dialog box prompt to input your password. Once you do that, I can steal root privileges from my script running in Terminal in the background without providing the password.

My little script did react on the failed sudo attempt in syslog, which triggered a password prompt, but working around that is trivial — just do it properly using more than 30 seconds to write your code, or add a grep -v 'incorrect password attempt' filter to the watch command.