Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

theheadguy

macrumors 65816
Apr 26, 2005
1,156
1,385
california
Since this is a "flaw" (to the extent it has been described) in sudo, it's not Mac-specific. Other flavors of UNIX are also affected. But it's more fun and gets more hits and attention when you call it an "OS X Vulnerability", as if it's Apple's mistake or fault and not due to an issue (if that's what it is) in one of several hundred non-Apple projects.
It just depends on whether you'll whine or not if the viewpoint is not your own. Allegedly, this is a Mac-centric site, so this OS X vulnerability was reported as such. Childishly pointing at the other kids saying they have the same problem too is pretty pathetic.

Grow up.
 

Lord Hamsa

macrumors 6502a
Jul 16, 2013
698
675
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:

...

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."

In this case, I would recommend using fast user switching and logging in as an Administrator account to perform this type of task, and then switch back to your standard account for anything other than a task that requires you to be actually logged in as administrator (most system admin tasks do not, just require you to provide credentials).
 

jc1350

macrumors 6502a
Feb 4, 2008
606
39
In this case, I would recommend using fast user switching and logging in as an Administrator account to perform this type of task, and then switch back to your standard account for anything other than a task that requires you to be actually logged in as administrator (most system admin tasks do not, just require you to provide credentials).

I'm so old school, I never think about fast user switching. Perhaps it's time I give it a try.
 

bin00

macrumors newbie
Aug 28, 2013
6
0
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.

That's one assumption. Here's another one: most of the time these "security researchers" actually care about security (who would have thought, they only spend most of their time doing it) and want to see vendors patch **** like this. If vendors don't patch, your best bet is to make a lot of noise.

----------

This is dumb... if they have physical access to your machine then you are already vulnerable. Physical access doesn't count.

reread, this is remotely exploitable. see my previous comment for an explanation of why this is useful to an attacker, and bad news to the consumer.
 

JAT

macrumors 603
Dec 31, 2001
6,473
124
Mpls, MN
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.
And if he's killed you and you are lying in a puddle of blood, you probably don't care so much about your computer, anyway.
 

JAT

macrumors 603
Dec 31, 2001
6,473
124
Mpls, MN
If you're not a programmer that symbol might confuse the average user. This one is more common ≠
That's more Mac vs PC. On the Mac it is easy to type the right symbol. On Windows you have to be a frickin' genius to find such things.
 

gnasher729

Suspended
Nov 25, 2005
17,980
5,565
reread, this is remotely exploitable. see my previous comment for an explanation of why this is useful to an attacker, and bad news to the consumer.

Only exploitable if an attacker already finds a massive vulnerability. Such a big vulnerability that one user account is already completely open. Many people have single user Macs, so if _one_ user account is cracked, there is nothing of value left.
 

ampfonseca

macrumors newbie
Aug 29, 2013
13
0
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.

Like the issue of OS X crashing every time that displays this String:

REMOVED

Sure, is a no issue too.

Source: https://zhovner.com/tmp/killwebkit.html

PS: Hope that you use Firefox.
 
Last edited:

Dalton63841

macrumors 65816
Nov 27, 2010
1,449
8
SEMO, USA
Like the issue of OS X crashing every time that displays this String:


Sure, is a no issue too.

Source: https://zhovner.com/tmp/killwebkit.html

PS: Hope that you use Firefox.

When does that string cause OS X to crash? I'm curious how to reproduce it. Im using Safari(on Mavericks to be fair) right now and nothing is crashing. And what I was saying was that for MOST of the Mac user base it IS a non-issue. However that post was also made on the assumption that the vuln is only exploitable with an admin account AND having used sudo. If that is in fact an OR, then the problem is significantly more of an issue.
 
Last edited by a moderator:

ampfonseca

macrumors newbie
Aug 29, 2013
13
0
When does that string cause OS X to crash? I'm curious how to reproduce it. Im using Safari(on Mavericks to be fair) right now and nothing is crashing. And what I was saying was that for MOST of the Mac user base it IS a non-issue. However that post was also made on the assumption that the vuln is only exploitable with an admin account AND having used sudo. If that is in fact an OR, then the problem is significantly more of an issue.

The bug is in coretext, so it's OS related. Probably the coretext in mavericks is updated, I will restart my Mac soon to check that. I've Mavericks on another partition.
A friend of mine sent me a iMessage some minutes ago, and my iMessage just crashed and I cant open it anymore. I have to clean the messages manualy in the filesystem, I will check how to do it in a moment.

Try to use OS X 10.8. Firefox is imune, probably doesn't use coretext to render the text.

But it's a pretty neat exploit, sadly Facebbok already blocked that string :p. I don't use Facebook, so I don't care.

EDIT: The first message was not a direct reply to you. I just wanted to say how easy this kind of exploits appear in all operative systems. No one can feel safe at any moment. I cannot steal any data from you, but it's a pretty damm good DOS atrack.
 
Last edited:

Negritude

macrumors 6502
Jul 14, 2011
297
199

Those do NOT patch the system sudo, they only install additional copies under /usr/local. The only way to patch this until Apple provides a security update is to install sudo via the above packages, MacPorts, Fink, Pkgsrc or whatever your favorite package manager is, and then overwrite the Apple provided binary.

If you're using MacPorts, it would look like 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

If you use the above packages, it would look like this:

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

Also, to maintain the best system compatibility, it might be advisable to install 1.7.10p7 instead of jumping all the way up to 1.8.7:

http://www.sudo.ws/sudo/download.html
 

mattysouthall

macrumors member
Jul 23, 2012
80
30
Like the issue of OS X crashing every time that displays this String:

<REMOVED>

Sure, is a no issue too.

Source: https://zhovner.com/tmp/killwebkit.html

PS: Hope that you use Firefox.

Remove the characters very hard to browse this thread


Those do NOT patch the system sudo, they only install additional copies under /usr/local. The only way to patch this until Apple provides a security update is to install sudo via the above packages, MacPorts, Fink, Pkgsrc or whatever your favorite package manager is, and then overwrite the Apple provided binary.

If you're using MacPorts, it would look like 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

If you use the above packages, it would look like this:

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

Also, to maintain the best system compatibility, it might be advisable to install 1.7.10p7 instead of jumping all the way up to 1.8.7:

http://www.sudo.ws/sudo/download.html

Ah yes this is true you do need to remove the sudo
 

Negritude

macrumors 6502
Jul 14, 2011
297
199
Install the latest version of sudo:

sudo port install sudo

Release notes are here

Wrong again. You have to overwrite the system sudo binary in order to fix the vulnerability. Simply installing an additional copy will not work.

Package managers on OS X install software under their own directory structure and do NOT overwrite system files.
 
Last edited:

munkery

macrumors 68020
Dec 18, 2006
2,217
1
reread, this is remotely exploitable. see my previous comment for an explanation of why this is useful to an attacker, and bad news to the consumer.

EDIT: The first message was not a direct reply to you. I just wanted to say how easy this kind of exploits appear in all operative systems. No one can feel safe at any moment. I cannot steal any data from you, but it's a pretty damm good DOS atrack.

Do you know of any documented methods to reliably bypass the runtime security mitigations in OS X Lion and Mountain Lion?

These versions of OS X haven't been compromised (meaning remote code execution hasn't been achieved) at any hacking contests or conferences.

Vulnerabilities only produce denial of service in these versions of OS X.
 

ampfonseca

macrumors newbie
Aug 29, 2013
13
0
Remove the characters very hard to browse this thread

I've removed from my post, sorry.

Just wanted to make clear that all software contains bugs and we never should say "That's too hard to exploit, don't bother to fix it. Apple should instead focus on the new iOS 7 icons".

I've some experience with cryptography and I know that little problems in cryptographic implementations that appear to be to insignificant to be ever exploited are the worst ones.

Just look at BEAST attack on TLS 1.0. If you look at the exploit you see how was hard to discover and exploit it. A simple implementation error in TLS that used implicit IV's just left a small door open for a smart hacker.

Do you know of any documented methods to reliably bypass the runtime security mitigations in OS X Lion and Mountain Lion?

These versions of OS X haven't been compromised (meaning remote code execution hasn't been achieved) at any hacking contests or conferences.

Vulnerabilities only produce denial of service in these versions of OS X.

This is a simple DoS, like I said above I can't steal your data but I can send emails to everyone and crash their Apple Mail client. Same with iMessage, etc.

This was not relevant to this thread I know, I just don't like when the people say that a simple privilege escalation is not dangerous. For now it can only be exploited locally, but in the future maybe you can exploit it remotely. You don't know that, but to be sure it's better to fix it ASAP.
 

Negritude

macrumors 6502
Jul 14, 2011
297
199
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

What version of OS X are you using and did you enter that command from an admin account or non-admin account?

I have my settings such that accessing all preference panes requires authentication. In my case, I get a similar result, but a little different:

systemsetup -setusingnetworktime off
setUsingNetworkTime: Off

systemsetup -setdate 01:01:1970
setDate: Error, you cannot set the date while network time is running. Use '-setusingnetworktime' to turn network time off.

systemsetup -setusingnetworktime on
Network Time is already on.

So, in my case, without authentication, OS X lies and tells me that networktime has been turned off, when in fact, it hasn't. Same result as yours, just a little more confusing.
 

munkery

macrumors 68020
Dec 18, 2006
2,217
1
This is a simple DoS, like I said above I can't steal your data but I can send emails to everyone and crash their Apple Mail client. Same with iMessage, etc.

This was not relevant to this thread I know, I just don't like when the people say that a simple privilege escalation is not dangerous. For now it can only be exploited locally, but in the future maybe you can exploit it remotely. You don't know that, but to be sure it's better to fix it ASAP.

Local privilege escalation is definitely dangerous. More so than getting the initial remote access because privilege escalation allows the compromise of data, such as credit card numbers collected from masked text fields, that makes malware profitable.

It is rare to see a profitable malware that doesn't include some sort of privilege escalation; whether through exploitation or social engineering.

No one has demonstrated methods to reliably remotely bypass the runtime security mitigations in 64 bit Linux distros that use basically the same runtime security mitigations as OS X Lion and ML since at least 2007 when Ubuntu wasn't compromised at pwn2own. So, it's pretty safe to assume that these mitigations are fairly robust.

But, this privilege escalation exploit could be used in a Trojan that the user is tricked into actively installing. But, this exploit has limitations, such as the requirement of previously using Sudo in command line, that would mitigate it's effectiveness in the wild against the typical Mac user.
 

Mac_Max

macrumors 6502
Mar 8, 2004
404
1
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.

Really? Seriously?

(Note to those who didn't see my earlier post, this assumes you've installed another copy of sudo first)
Code:
$ sudo rm /usr/bin/sudo
$ sudo ln /opt/local/bin/sudo /usr/bin/sudo
$ /usr/bin/sudo -v
Sudo version 1.8.6p7
Sudoers policy plugin version 1.8.6p7
Sudoers file grammar version 42
Sudoers I/O plugin version 1.8.6p7

Or

Code:
$ sudo rm /usr/bin/sudo
$ sudo cp /opt/local/bin/sudo /usr/bin/sudo
$ /usr/bin/sudo -v
Sudo version 1.8.6p7
Sudoers policy plugin version 1.8.6p7
Sudoers file grammar version 42
Sudoers I/O plugin version 1.8.6p7

Because that's so difficult.

Or if we want to do things the old fashioned way....

Code:
$ cd /tmp && wget http://www.sudo.ws/sudo/dist/sudo-1.8.7.tar.gz && tar -xvf sudo-1.8.7.tar.gz && cd sudo-1.8.7 && ./configure --prefix=/usr && sudo make && sudo make install
$ /usr/bin/sudo -V
Sudo version 1.8.7
Sudoers policy plugin version 1.8.7
Sudoers file grammar version 43
Sudoers I/O plugin version 1.8.7
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.