OS X Vulnerability Can Allow Superuser Access to Unauthorized Users

[bradl]

I will also point out that this vulnerability is very useful to people who have run sudo but forgot their account password!

If they forgot their account password, they wouldn't be able to get onto the box to begin with.. as we all know, sudo requires the account's password to be used, not the root password.

BL.

 

[bin00]

If they forgot their account password, they wouldn't be able to get onto the box to begin with.. as we all know, sudo requires the account's password to be used, not the root password.

BL.

They can log in as another administrative user, also useful when (this is what I was thinking of) they recently changed their password and forgot it before locking the screen/shutting down.

Edit; although if they can login as another admin user, they can get root and change their other accounts password, so that case is not really useful

 

[teknishn]

Yawn,

So I guess if I happen to somehow have a cyber criminal in my house, leave my machine unattended for him, and happen to have run sudo before.... he could sneak in there and compromise my system. OMFG, I don't know how I'm going to sleep tonight.

 

[V.K.]

If they forgot their account password, they wouldn't be able to get onto the box to begin with.. as we all know, sudo requires the account's password to be used, not the root password.

BL.

many people have automatic login enabled (I think it's on by default for the first user created) so they don't need to remember the password. I once had to help somebody like that who also had a firmware password set. He then needed his admin password to install something and couldn't remember it and also couldn't remember the firmware password. that made for a tricky situation as the firmware password makes it impossible to boot from the install DVD (without knowing that firmware password) or in single user mode.

 

[fr33 loader]

This thread conversation with their facy wordings is giving me a headache. Can we please just go back to "I love my iPhone" and "Samsung and Google is the Devils' spawn" topic?

 

[jameslmoser]

Lots of people have their mac set up to login to their account automatically on boot. Also if you steal someones computer when it is in sleep mode and still logged in there you go.

If you have physical access to a machine, then THIS exploit is the least of your problems.

 

[Mac_Max]

Sudo 1.8.6p7 is available and seems to fix the vulnerability. I installed it via macports on my machines.

 

[bradl]

many people have automatic login enabled (I think it's on by default for the first user created) so they don't need to remember the password. I once had to help somebody like that who also had a firmware password set. He then needed his admin password to install something and couldn't remember it and also couldn't remember the firmware password. that made for a tricky situation as the firmware password makes it impossible to boot from the install DVD (without knowing that firmware password) or in single user mode.

Fair enough.

The sysadmin in me (been one for 20 years) always has me working by the top 2 following rules:

1. Never, EVER log in directly as root. If needing superuser access, log in as your normal user and su to root (su or su -). Sudo doesn't cut it, for reasons like this.

2. Never leave an account on a machine without a password. you are asking for trouble if you do so. For any non service-running account, slap a password on it.

That's simple Unix Security, Chapter 1.

BL.

 

[RabidMacFan]

Sudo 1.8.6p7 is available and seems to fix the vulnerability. I installed it via macports on my machines.

Installing sudo with MacPorts does not replace the sudo installed with OS X. You would need to upgrade the version of sudo within /usr/bin.

This bug is fixed in OS X 10.9 Mavericks. It's unclear at this time if 10.8 will get a similar update.

 

[bananas]

Make sudo require password everytime

Sounds like this can be prevented by a simple alias in .profile which makes sudo require password each time it's run:
alias sudo="sudo -k"

 

[Negritude]

Installing sudo with MacPorts does not replace the sudo installed with OS X. You would need to upgrade the version of sudo within /usr/bin.

And that was going to be my question, having already been using an upgraded sudo via MacPorts, is there anything special about the Apple provided sudo, which would advise against me doing this:

sudo chmod u+w /usr/bin/sudo
sudo cp -p /opt/local/bin/sudo /usr/bin
sudo chmod a-w,go-r /usr/bin/sudo

In other words, can I just simply install my own copy of sudo and overwrite the one in /usr/bin, without causing any problems? Does OS X need the Apple provided sudo, or will any sudo do?

Here's the situation currently for me:

[Negritude] /usr/bin/sudo -V
Sudo version 1.7.4p6

[Negritude] /opt/local/bin/sudo -V
Sudo version 1.8.6p7

 

[Dalton63841]

Installing sudo with MacPorts does not replace the sudo installed with OS X. You would need to upgrade the version of sudo within /usr/bin.

This bug is fixed in OS X 10.9 Mavericks. It's unclear at this time if 10.8 will get a similar update.

How is it fixed in Mavericks? I'm curious. systemsetup still does not require a password, and sudo -V outputs Sudo version 1.7.10p7

 

[munkery]

Here's the point of the exploit:

1. Attacker gets a shell on your user account, perhaps by exploiting a browser vulnerability (CVE-2013-0983) or by emailing you a crafted image (CVE-2013-0975). Yes they are real, and those are only two that we know about. This is the hard part of exploitation.

2. Attacker can now read all your files, perform any actions that your user account can normally do. Usually attacker will stop here. Without knowing the system password, he can't perform system actions, primarily: can't read root-owned files, can't read files owned by other users, can't install kernel extensions, install hard-to-detect persistence, can't change passwords of other users, etc etc.

This is where the vulnerability comes in handy. if you just so happened to have ever run the "sudo" cmd successfully (as many devs do), and you are an administrative user (as the default user is in osx), the attacker can easily upgrade to a "root" shell. That's a bummer, and apple really should have patched this already, the sudo update has been around for 6 months or so now at least.

Despite those vulnerabilities being found, no methods have been developed to reliably bypass the runtime security mitigations that prevent those vulnerabilities being exploited.

This means that those vulnerabilities only produce a denial of service condition unless by very slim random chance (much less than %1) code execution occurs because the attacker can not increase the likelihood of code execution because of the runtime security mitigations present in more recent versions of OS X.

These runtime security mitigations are the reason why Mac OS X hasn't been compromised at the last 2 pwn2own hacking contests.

 

[Negritude]

How is it fixed in Mavericks? I'm curious. systemsetup still does not require a password, and sudo -V outputs Sudo version 1.7.10p7

1.7.10p7 is not vulnerable:

http://www.sudo.ws/sudo/alerts/epoch_ticket.html

 

[keysofanxiety]

They can log in as another administrative user, also useful when (this is what I was thinking of) they recently changed their password and forgot it before locking the screen/shutting down.

Edit; although if they can login as another admin user, they can get root and change their other accounts password, so that case is not really useful

Easier way: hold 'Alt' on startup, boot into Recovery HD. When in recovery HD, open Terminal, type 'resetpassword'.

Boom.

 

[gnasher729]

Admin and root are two different levels of access. You can do some things with root that you cannot do with admin. Root is the deepest access one can have - but it's not really the goal of most hackers. An administrator account is probably the most that an attacker really needs since they can pretty much do anything they need with that account.

So an exploit that needs admin rights access and one that rehires you to have used sudo isn't one that is high priority. The number of users that run sudo at all is really small, and from a security standpoint, if you have admin rights, all security goes out the window. In other words, you don't have security.

In other words, if you rent a room in my house, and I have the keys to the house, and keys to all the rooms in the house, then your things are not safe from me when I'm at home.

----------

sorry, I take it back. if a remote attacker gains user level access somehow and that user happens to be an admin user then the attacker can use this vulnerability to get full root access without ever having an admin password. this does make it somewhat serious.

And since many Macs are single user, someone getting user level access already has access to anything that is interesting.

 

[munkery]

And since many Macs are single user, someone getting user level access already has access to anything that is interesting.

Protected data entry, such as masked text entry, and protected data storage, such as keychain items, are not accessible with only user level access.

These are the types of data that malware targets to be profitable when the target of the malware is the typical computer user.

 

[touko]

Just click on the lock in Date & Time Preferences with "Set date and time automatically" checked and you're safe.

$ systemsetup -setusingnetworktime Off
2013-08-29 02:59:20.391 systemsetup[90875:707] Cannot call setInetDServiceEnabled:enabled without first being authenticated
setUsingNetworkTime: Off

 

[conradwt]

Easier way: hold 'Alt' on startup, boot into Recovery HD. When in recovery HD, open Terminal, type 'resetpassword'.

Boom.

One can simply set the Firmware Password to prevent this type of attack very easily by doing the following:

a) Reboot machine holding down the Command + R keys
b) Set the Firmware Password Utilities menu

Boom.

 

[conradwt]

Installing sudo with MacPorts does not replace the sudo installed with OS X. You would need to upgrade the version of sudo within /usr/bin.

This bug is fixed in OS X 10.9 Mavericks. It's unclear at this time if 10.8 will get a similar update.

Yes, I can confirm that this issue has been fixed.

 

[Dalton63841]

One can simply set the Firmware Password to prevent this type of attack very easily by doing the following:

a) Reboot machine holding down the Command + R keys
b) Set the Firmware Password Utilities menu

Boom.

If your Mac is older than a 2011 model it is still ridiculously easy to get around the firmware password. All you have to do is remove one of the sticks of ram, and perform a PRAM reset. That has been fixed since the 2011 models though so if you have a newer system you are safe.

 

[ValSalva]

Installing sudo with MacPorts does not replace the sudo installed with OS X. You would need to upgrade the version of sudo within /usr/bin.

This bug is fixed in OS X 10.9 Mavericks. It's unclear at this time if 10.8 will get a similar update.

Good to know. Is updating 10.8 a resource problem for Apple or are there technical limitations? It seems like this should be a priority.

 

[MH01]

Exactly. It's effectively a NON-issue, especially considering that the garden variety Mac user has never even opened Terminal. That having been said it still needs to be fixed. Who knows what fancy method they might find to exploit it if they don't fix it.

That's the right attitude, NON-issue!!! But if I am not a Garden variety user.... ???

 

[dyn]

"For one, the end-user who is logged in must already have administrator privileges. And for another, the user must have successfully run sudo at least once in the past."

I'm not too sure why a user who already has admin access would bother using an exploit to gain admin privilege - an access level he already has.

Only admin users are allowed to use sudo. A normal user account can't use it. Not by default as it is not put in the sudoers file; you can do this manually and for those who did, you'll have the same problem as those with an admin account.
As bin00 explained you need sudo to do commandline work with admin privileges. Having the admin user isn't enough. Obviously if you have the password of an admin account this exploit isn't needed since you can do anything.

Since sudo allows an ordinary user account to do powerful stuff it is always a very wise idea to check the sudo settings. Don't give out too much privileges and don't set the timeout too long. If you disable the timeout altogether and you find yourself typing a lot of commands that require root privileges it is helpful to start a "root" shell (sudo bash, sudo -i, etc. depending on what you need/is more convenient to you). Saves you 4 additional characters in each command as well (sudo ). Do know that the timeout option is there for a good reason. It's about a good mix between security and convenience!

 

[haravikk]

The number of users that run sudo at all is really small, and from a security standpoint, if you have admin rights, all security goes out the window. In other words, you don't have security.

I think it's worth noting that a majority of Mac users are likely using a default admin account for their day to day use, as OS X doesn't really encourage you to set up a separate admin account; it's one of those thing that it should really do as part of the initial setup otherwise casual users will just setup their admin account with their details and stick to that. So a user running an admin account is a fairly common vulnerability, common enough to possibly exploit.

Secondly, many users may have indirectly used sudo without realising it, as some applications use commands run via sudo to do various tasks, usually utility programs so still not the most likely of use-cases, but it does mean that never having opened Terminal and run a command via sudo isn't a guarantee that you're safe.

I think the more important requirement for this attack is the physical or remote access to the machine; the majority of users shouldn't have remote access turned on unless they've specifically needed it for something. So those casual users who are admins without realising it's not the best idea should still be safe.


Even so, for those of you with a single user account that is an admin I'd still recommend adding a new admin account with a nice strong password and downgrading your account to a standard one, as it's just good security practice. You should also probably prevent that account from logging in (as it shouldn't need to since you can enter its details from any account via the admin prompt) though I don't think it's important to do so, I can't remember how