Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > macOS > Local root vuln in OS X

Local root vuln in OS X
Thread Tools
Angus_D
Addicted to MacNN
Join Date: Mar 2000
Location: London, UK
Status: Offline
Reply With Quote
Jan 25, 2005, 04:03 PM
 
http://www.securityfocus.com/archive...1/2005-01-27/0

spiffy:~ finlayd$ gcc -o root-osx root-osx.c
spiffy:~ finlayd$ ./root-osx
sh-2.05b#

Bad.
     
waffffffle
Mac Elite
Join Date: Sep 2000
Status: Offline
Reply With Quote
Jan 25, 2005, 04:17 PM
 
I tried compiling and running the program but nothing happens. I don't get a root shell like you do, just another prompt at my current shell.
     
Angus_D  (op)
Addicted to MacNN
Join Date: Mar 2000
Location: London, UK
Status: Offline
Reply With Quote
Jan 25, 2005, 07:02 PM
 
Works for everyone else I've talked to.
     
TETENAL
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
Jan 25, 2005, 07:46 PM
 
I don't understand the problem. Can you describe it in laymen's terms?

Is this fixed by today's security update?
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Jan 25, 2005, 08:16 PM
 
Basically, it's a buffer overflow vulnerability in iSync. If you run one of the tools iSync uses (called mRouter) and pass certain data to it in the environment, it'll run that code as root.

EDIT: It doesn't look like the security update would fix it. It doesn't affect iSync. I'll test once get the chance.
( Last edited by Chuckit; Jan 25, 2005 at 08:36 PM. )
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
Chuckit
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status: Offline
Reply With Quote
Jan 25, 2005, 09:20 PM
 
Security Update 2005-001 doesn't fix it.
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
     
Angus_D  (op)
Addicted to MacNN
Join Date: Mar 2000
Location: London, UK
Status: Offline
Reply With Quote
Jan 26, 2005, 01:13 PM
 
Originally posted by TETENAL:
I don't understand the problem. Can you describe it in laymen's terms?
Any local user can bypass the permissions and security model and become root, the super-user. They can read files, screw with settings, delete stuff...

This is very bad in, say, lab settings.
     
KraziKid
Dedicated MacNNer
Join Date: Dec 2003
Status: Offline
Reply With Quote
Jan 26, 2005, 04:54 PM
 
Originally posted by waffffffle:
I tried compiling and running the program but nothing happens. I don't get a root shell like you do, just another prompt at my current shell.
Works for me, and I have every update installed.
15 inch MacBook Pro 2.16 GHz, 2 GB RAM, 7200 RPM 100GB HDD.

Dual 2.5 GHz Power Mac G5, 1 GB RAM, 250 GB HDD, ATI Radeon X800XT.
     
Person Man
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
Jan 26, 2005, 07:26 PM
 
Originally posted by Angus_D:
This is very bad in, say, lab settings.
Until Apple comes out with a fix, couldn't one disable iSync and remove the mRouter file? Or are there other things besides iSync that rely on mRouter?

What purpose (besides keeping lab computers' bookmarks and address books, etc in sync) would iSync have to end users in a computer lab?
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
Jan 26, 2005, 11:17 PM
 
Originally posted by Angus_D:
http://www.securityfocus.com/archive...1/2005-01-27/0

spiffy:~ finlayd$ gcc -o root-osx root-osx.c
spiffy:~ finlayd$ ./root-osx
sh-2.05b#

Bad.
Interesting.

I tried it here both before and after the most recent security update (Security Update 2005-001) and it only seems to work for a user with uid=501. I usually login as myself (non-admin) with uid=502. The only user on my Macs with uid=501 is the admin user.

I tried creating another user (uid=511 in my test), gave that user admin priveleges, and the PoC code failed.

I disabled admin privs for my regular admin user (uid=501) and ran the PoC code again and it succeeds.

In summary: The PoC code seems to only succeed if run by a user with uid=501 whether that user is an admin user or not. If the PoC code is run by a user with a uid != 501 then it fails.

On most peoples systems, if they are the primary user, they are most likely to have a uid=501.... they are also most likely the admin user. So the PoC doesn't really gain any privs that user didn't already have.

As far as I can tell from my tests the simplest and quickest current workaround for computer labs is to disable the account with uid=501. If that is your main user account on your own system just be careful what you run because this code could conceivably be used as part of a trojan and do rootly things without asking for authentication. IOW just use the usual caution. If it is not practical to disable the user with uid=501, at the very least, disable remote login for that user.
-DU-...etc...
     
fitter
Senior User
Join Date: Jan 2000
Status: Offline
Reply With Quote
Jan 27, 2005, 10:50 AM
 
That's a little misleading. I think you may be able to say that the shellcode provided in the sample exploit has specific requirements (I'd like to see the source that produced the shellcode), but better exploits will become available. The flaw allows arbitrary command execution with euid 0. That the sample doesn't work in all cases is beside the point. As Angus_D makes clear, the flaw shouldn't affect single-user machines, but when you start allowing remote access, or begin talking about public workstations, then the flaw is severe.
     
Angus_D  (op)
Addicted to MacNN
Join Date: Mar 2000
Location: London, UK
Status: Offline
Reply With Quote
Jan 27, 2005, 12:16 PM
 
Originally posted by Person Man:
Until Apple comes out with a fix, couldn't one disable iSync and remove the mRouter file? Or are there other things besides iSync that rely on mRouter?
Oh, sure. You can just change the permissions on mRouter, and you'll be fine (except you won't be able to sync to symbian phones any more). It's just bad that Apple hasn't rolled out that workaround or a fix, and it's been >2 weeks.
     
chris v
Addicted to MacNN
Join Date: Jan 2001
Location: The Sar Chasm
Status: Offline
Reply With Quote
Jan 27, 2005, 01:03 PM
 
If a malicious person with the kind of knowledge it takes to run this vulnerability is sitting at your computer, you're going to have problems no matter what.

When a true genius appears in the world you may know him by this sign, that the dunces are all in confederacy against him. -- Jonathan Swift.
     
Mithras
Professional Poster
Join Date: Oct 1999
Location: :ИOITAↃO⅃
Status: Offline
Reply With Quote
Jan 27, 2005, 01:51 PM
 
Is iSync installed on OS X Server?
     
utidjian
Senior User
Join Date: Jan 2001
Location: Mahwah, NJ USA
Status: Offline
Reply With Quote
Jan 27, 2005, 01:52 PM
 
Originally posted by fitter:
That's a little misleading. I think you may be able to say that the shellcode provided in the sample exploit has specific requirements (I'd like to see the source that produced the shellcode), but better exploits will become available. The flaw allows arbitrary command execution with euid 0. That the sample doesn't work in all cases is beside the point. As Angus_D makes clear, the flaw shouldn't affect single-user machines, but when you start allowing remote access, or begin talking about public workstations, then the flaw is severe.
I had/have no intention of misleading anyone. But thanks for bringing up the point.

I do not know why the PoC code only seems to be effective if run by a user with uid=501... those were just my findings. The uid=501 might have to do with the shellcode[] or it might have to do with something else external to the PoC code.

You could ask nemo @ felinemenace.org who wrote the PoC for details on the shellcode.

Incidentally... http://felinemenace.org/exploits/fm-iSink.c is the original PoC source file. One thing that was left out of the OP listing is this line:
Code:
* NOT public. Please do not distribute.
So much for that idea... the cat is out of the bag. According to the View Page Info in Firefox that page was last modified on Jan 22 2005. I wonder how long ago they told Apple about it.
-DU-...etc...
     
Person Man
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
Jan 27, 2005, 01:57 PM
 
Originally posted by Angus_D:
...you'll be fine (except you won't be able to sync to symbian phones any more).
Why would you need to sync your Symbian phone to a public, lab computer?
     
Angus_D  (op)
Addicted to MacNN
Join Date: Mar 2000
Location: London, UK
Status: Offline
Reply With Quote
Jan 27, 2005, 05:41 PM
 
Originally posted by Person Man:
Why would you need to sync your Symbian phone to a public, lab computer?
You wouldn't. But iSync is installed out of the box with Panther, right?
     
Boondoggle
Grizzled Veteran
Join Date: May 1999
Location: Seattle
Status: Offline
Reply With Quote
Jan 27, 2005, 08:03 PM
 
is this strictly a local problem?
1.25GHz PowerBook


i vostri seni sono spettacolari
     
TETENAL
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
Feb 22, 2005, 05:59 PM
 
Security Update 2005-002 says nothing about iSync so doesn't appear to fix this.
     
   
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 07:20 AM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,