I'll go out on a limb here and guess you're a Windows user or a Mac user who barely, if ever, opened Terminal.
Glassed Silver:mac
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
OS X Vulnerability Can Allow Superuser Access to Unauthorized Users
- Thread starter MacRumors
- Start date
- Sort by reaction score
I'll go out on a limb here and guess you're a Windows user or a Mac user who barely, if ever, opened Terminal.
Glassed Silver:mac
The flaw may allow someone with physical access to a machine that is not password-protected to run sudo commands without knowing the logged in user's password. On systems where sudo is the principal way of running commands as root, such as on Ubuntu and Mac OS X, there is a greater chance that the logged in user has run sudo before and thus that an attack would succeed.
So Admin user A sets things up so sudo doesn't time-out. Random user B comes up to computer which is still logged in with A's account and can use sudo without a password.
So random user B can type sudo -s and go nuts.
So basically the "exploit" requires you to intentionally f- your own computer first. This is a non-issue.
So Admin user A sets things up so sudo doesn't time-out. Random user B comes up to computer which is still logged in with A's account and can use sudo without a password.
So random user B can type sudo -s and go nuts.
So basically the "exploit" requires you to intentionally f- your own computer first. This is a non-issue.
I've run sudo a number of times, so I think I'm vulnerable; but I don't yet fully understand sudo, all its switches, how it controls the clock, and how all this impacts security (vis-a-vis the vulnerability allowing intruders to upgrade to root access or other).
Can I just run "sudo -K" to fix the problem for now? I.e., does running that command then force someone infiltrating my machine remotely to know my password in order to run the "sudo" command?
Both my Macs are pre-20111, running 10.8.4; one is File Vaulted.
Can I just run "sudo -K" to fix the problem for now? I.e., does running that command then force someone infiltrating my machine remotely to know my password in order to run the "sudo" command?
Both my Macs are pre-20111, running 10.8.4; one is File Vaulted.
That won't work. The command:
Code:
sudo -kWhat you actually want is:
Code:
alias sudo="sudo -K; sudo"So that the timestamp file is removed, requiring a password regardless of the timestamp file vs. date comparison.
----------
Not really - this exploit does not require that an admin "sets things up so sudo doesn't time-out". All it requires is that:
1) Admin user A has run a sudo command at least once in the past, even if it was 5 years ago. (Thus a timestamp file exists.)
2) The system date/time can be changed by Admin user A.
Fairly common situation. Now, if I'm user B and I stroll by and see that Admin user A's desktop is not locked, all I have to do is:
1) Run 'sudo -k' to reset the timestamp file to the Unix epoch.
2) Change the date/time of the machine to the Unix epoch.
I can now, as user B, run a 'sudo' command and either run with privileged access, or potentially just 'sudo su' and become root, without needing Admin user A's password.
Last edited:
It is fixed in Mavericks, via version 1.7.10p7.
The commit with the fix: http://www.sudo.ws/repos/sudo/rev/ddf399e3e306
And the updating of the release notes, indicating the change: http://www.sudo.ws/repos/sudo/rev/d95631aa92d9
If that were the case, then why bother distinguishing between admin and root? I disagree - I have to use sudo from time to time to modify system files, and I'm generally happy that someone without the root password couldn't access those files.
The bad guy needs to be logged into your machine (physically or remotely) under a username that has admin privileges.
If they got that far by knowing your password (which would apply to most remote logins) then you're humped anyway.
Basically, if a bad guy is in a position to use this exploit then you're already in a pretty bad position.
This is a bug that needs to be fixed, but its not something for the typical user to lose sleep over.
ouch, that's a bad news for apple. wasn't expecting this fro a company like apple. i hope they're working on this.
Wait... there are users out there who are savvy enough to ever need to run "sudo" who perform their everyday work in an account with Administrator access? I mean, I imagine it happens because it's the "easy" way, but my Mac has one "Administrator" account and several user accounts (one each for me, my wife, and our eldest child), and no one ever logs in as Administrator -- even I, who configured and maintain the system, have only logged in as Administrator once, and just long enough to perform the initial setup of the system. Otherwise, I run from my own account and provide admin credentials when necessary.
No. I think what they're saying is that IF the attacker has access to your machine, AND you run as an administrator account, OR you are running as a non-administrator account that has opened Terminal and run sudo, THEN they may gain root access.
But none of use run as an admin account, do we kids? And we all log in to an admin account from a non-admin account within Terminal, don't we kids?
The good news is that I suspect the fast majority of machines running OS X only have one user and one user account anyway. Maybe two, a day to day account and a privileged administrator for maintenance. Even in the two account case, both generally correspond to the same real person.
However, I have worked places (education organizations) that use OS X on servers, as a "friendlier" way to run a multi-user unix system. There is a risk here of a rogue admin going snooping, in limited circumstances. Of course, in a physical access scenario, there are always ways to get to retrieve everything on disk if you are determined enough. This always more surreptitious access, as well as remote access.
However, I have worked places (education organizations) that use OS X on servers, as a "friendlier" way to run a multi-user unix system. There is a risk here of a rogue admin going snooping, in limited circumstances. Of course, in a physical access scenario, there are always ways to get to retrieve everything on disk if you are determined enough. This always more surreptitious access, as well as remote access.
If you're not a programmer that symbol might confuse the average user. This one is more common ≠
----------
Your default account has admin access (as in the one who initially set up the machine).
You did not get the memo then: the real "fun" part about this story is that for every damn other Unix/Linux system this security hole (not "flaw": security hole!) was fixed from literally day one it was made "public"! Except... oh wait... err.. y'know... Apple....
This "vulnerability" is so stupid. Give me physical access to ANY computer and I can hack it.
Case in point (although quite some time ago): I was on an overseas flight to Singapore and my PowerBook G4 had just been upgraded to 10.5. Unfortunately, in the middle of the flight, my PowerBook decided that I didn't need administrator access. (Demotion of users is a known bug in 10.5.)
I restarted my computer in single user mode, edited the necessary files (I'm not being specific for a reason), rebooted, promoted my access level by launching the appropriate application as "root", and gave myself back admin access. All while flying over the Pacific Ocean without Internet access.
Case in point (although quite some time ago): I was on an overseas flight to Singapore and my PowerBook G4 had just been upgraded to 10.5. Unfortunately, in the middle of the flight, my PowerBook decided that I didn't need administrator access. (Demotion of users is a known bug in 10.5.)
I restarted my computer in single user mode, edited the necessary files (I'm not being specific for a reason), rebooted, promoted my access level by launching the appropriate application as "root", and gave myself back admin access. All while flying over the Pacific Ocean without Internet access.
I would think you'd want it to be the opposite way.
Code:
alias sudo="sudo; sudo -K"This way you run sudo, and then remove the timestamp file. Otherwise someone could just to go /usr/bin/sudo directly and still have access because you left around the last timestamp file. The only thing to remember is after creating the alias would be to run sudo -K by hand to remove the current timestamp file.
As others have mentioned, being logged in as an administrator account and actually having root (think "Run as administrator" in Windows Vista/7/8, not Windows XP where this is not true) privileges are not the same.
You do not need physical access to the machine to exploit the vulnerability. You can obtain shell access remotely by SSH (if, of course, that's available on the machine), and one worry is that security flaws in, e.g., a browser (which could allow shell access) could be combined with this vulnerability.
I wouldn't be so sure that most people haven't run sudo, either. I'm not sure the OS X authentication GUI runs sudo underneath the hood, though I wouldn't be surprised (does anyone know?), but it's entirely possible some installer you've run has a script that does it as part of the install. This probably also affects many OS X servers, as they are highly likely to have public SSH access as well as previous sudo usage.
The solution at the moment seems to be not to log on to an admin account except when absolutely necessary or to disable SSH (assuming physical access is not a problem, because you still have to worry about that). It also is related to Apple's allowing regular users to modify the system time, but Apple changing that would really just work around the problem rather than fixing it. It's already fixed in newer versions of sudo, and Apple appears to have included in Mavericks. Hoepfully they'll issue a patch for 10.7 and 10.8 soon.
root can do dangerous things without password. admin can do dangerous things after typing their password. There is no difference from the point of view of a malicious attacker; there is a huge difference because of the danger of messing up your own system. root is driving without seat belt. admin is driving with seat belt.
oh please. you can't do much of anything useful on a "regular" mac account without constantly typing in an admin name and password, and that's part of the problem. I TRIED to do the "best practice" with this latest mac of not using an admin account for daily computing, and I lasted less than a day. If you ever install or update anything, or live in a world with multiple network environments, you can't reasonably get any work done on a regular user account.
That, and the fact that OS X defaults to Admin users, is probably a good reason why I've never actually seen a real-life Mac owner with a "standard" user account as their day-to-day account.
You are in the vast minority. I have one "standard" account set up for my kids to use, and otherwise it's admin.
It is more often than not these "security researchers" make a big deal out of issues that are not such a big deal to make headlines.
Reminds me of the whole Bitlocker-key-can-be-recovered-from-RAM-if-frozen deal.
Reminds me of the whole Bitlocker-key-can-be-recovered-from-RAM-if-frozen deal.
Not only is it a pain, but part of it is broken in the name of security. I just tried the setup by adding a dedicated admin account, enabling the root user, and removing admin rights from my normal account. What I expected was that I couldn't use sudo (fine), but I could use su. Wrong. Under this config:
1. GUI based admin changes require me to type admin account name and password. NO problem for me. I can live with it.
2. I constantly change my /etc/hosts file to test new apache configs that I stage on one of our load-balanced servers before I run the script that copies the configs to the rest of the servers. vi is my editor of choice. Here is the problem - as a regular user account, I am locked out of both sudo AND su even if I know the root password. For it to work, I have to su to the admin account, then su again to root. Mac OS is configured to allow only %admin and %wheel groups access to the su command.
I would have to play around with the directory service to add my account to %admin or %wheel (info from the man page for su). So, I've just went around a bumpy circle since this would be the same as simply checking "allow this account to be an administrator."
Update - more thoughts - my situation is special. I'm a sysadmin/engineer by trade and I know the risks. For the everyday user, a regular account and dedicated admin account can be the better way to go. It's just not easy to do that for some types of power users.
Last edited:
I do useful stuff - including installs and updates - all of the time as a "standard" user providing admin credentials when needed. It's recommended practice for a reason. If I am in the distinct minority, that just reflects on poor practices generally.
That said, I can see where the inability to use "sudo" and "su" without the runaround of having to su as "admin" (or whatever you call your admin account) first would be a hassle for a subset of power users (as in the post before this one). But I fail to see the significant security risk here (yes, there's a hole, and it needs to be patched) if the user is following the principle that elevated privileges are to be used only for specific tasks, and that you should try to run with the minimum privileges necessary.
That means running your day-to-day stuff as a standard user, routine system administration tasks (and only admin tasks) as an admin user, and specialized root-required tasks as root (preferably through sudo). If you're running day-to-day tasks with admin (or higher!) privileges, you are exposing yourself to considerably more risk than you need to.