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 > Security Update 2006-002

Security Update 2006-002
Thread Tools
Sophus
Mac Enthusiast
Join Date: Nov 2001
Location: Norway
Status: Offline
Reply With Quote
Mar 13, 2006, 05:17 PM
 
Security Update 2006-002 is recommended for all users and improves the reliability and security of the following components:
apache_mod_php
CoreTypes
LaunchServices
Mail
rsync
Safari


In SU. Seems to work well. No problems so far for me...
     
threestain
Mac Elite
Join Date: Mar 2003
Location: London/Plymouth, England
Status: Offline
Reply With Quote
Mar 13, 2006, 05:20 PM
 
ok, good, thanks.

however, I can no longer burn dvds using dvd2onex or disk utility. annoying.
     
Sophus  (op)
Mac Enthusiast
Join Date: Nov 2001
Location: Norway
Status: Offline
Reply With Quote
Mar 13, 2006, 05:30 PM
 
Originally Posted by threestain
ok, good, thanks.

however, I can no longer burn dvds using dvd2onex or disk utility. annoying.
You probably should state what kind of hardware you have. Would make it easier on others who might be in doubt.
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 13, 2006, 05:48 PM
 
That damn Heise shell script that looks like a JPEG still opens in the Terminal when you double-click on it.

Why can't Apple just fix this?

In other news, this security update seems to have broken the Shiira browser...

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
TETENAL
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
Mar 13, 2006, 05:56 PM
 
Originally Posted by CharlesS
That damn Heise shell script that looks like a JPEG still opens in the Terminal when you double-click on it.

Why can't Apple just fix this?
I guess the behavior is as desired. The shell script was set to open by Terminal with the Finder Get Info dialog. At least you get a warning if you have "Open safe files after download" turned on in Safari. What I don't understand is why Safari doesn't do the download validation when that setting is turned off.
     
Person Man
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
Mar 13, 2006, 06:01 PM
 
Originally Posted by TETENAL
I guess the behavior is as desired. The shell script was set to open by Terminal with the Finder Get Info dialog. At least you get a warning if you have "Open safe files after download" turned on in Safari. What I don't understand is why Safari doesn't do the download validation when that setting is turned off.
I, for one, would HATE it if every time I tried to download something, Safari told me that "the file I'm about to download contains an application." I know better than to double click on something suspicious.

"Open safe files" is on by default, and the people who benefit the most from that warning probably won't turn it off, either.

It's just fine the way it is, thank you.
     
MartiNZ
Senior User
Join Date: Aug 2002
Location: Auckland, NZ
Status: Offline
Reply With Quote
Mar 13, 2006, 06:09 PM
 
Not security related, but they haven't fixed the iTunes widget crash in 5 point-point updates, so I figure I'm grateful for pretty much any fixes .

With iTunes not open, open Dashboard and click play on the iTunes widget - when play starts, click shuffle on the widget. Up comes a Report/Reopen dialog - I've sent them the report after every single 10.4 update.
     
rickey939
Addicted to MacNN
Join Date: Jul 2005
Location: Cooperstown '09
Status: Offline
Reply With Quote
Mar 13, 2006, 06:21 PM
 
Hmm, so what is different from Security Update 2006-001 exactly?
     
OAW
Addicted to MacNN
Join Date: May 2001
Status: Offline
Reply With Quote
Mar 13, 2006, 06:27 PM
 
Ok. We still have the issue of an executable file being disguised as an image, movie, or text file. Custom icons allow for that. But OTOH, custom icons have legitimate purposes so we don't want to throw the baby out with the bath water. So what should be done to catch the Trojans out there?

What if OS X simply warned the user and prompted him/her to continue or cancel the first time any executable ... application or script .... runs? It already does this when an application is launched remotely so why not do it when a user manually launches it? Perhaps the warning message can be more alarming if the file extension doesn't correspond to the file being launched (i.e. "*.jpg" extension on an application)? Wouldn't this effectively address the problem?

OAW
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 13, 2006, 06:49 PM
 
I say we should make the "Open with custom application" setting specific to the user that set it. It would open with the custom application when running under the user who set it that way, and would open with the default for everyone else. It would solve the problem of someone disguising a shell script as a JPG file and setting it to open with the Terminal, but it would also give specific benefits to the users - two different users could each set a file to open with a different application. Why should all users get stuck with opening a certain file with a certain app just because one user prefers it that way, anyway?

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
moodymonster
Mac Elite
Join Date: Sep 2003
Location: London
Status: Offline
Reply With Quote
Mar 13, 2006, 06:51 PM
 
Originally Posted by CharlesS
That damn Heise shell script that looks like a JPEG still opens in the Terminal when you double-click on it.

Why can't Apple just fix this?

In other news, this security update seems to have broken the Shiira browser...
same here with heise and ditto shiira
     
alphasubzero949
Mac Elite
Join Date: Jan 2003
Location: 127.0.0.1
Status: Offline
Reply With Quote
Mar 13, 2006, 07:32 PM
 
Originally Posted by TETENAL
I guess the behavior is as desired. The shell script was set to open by Terminal with the Finder Get Info dialog. At least you get a warning if you have "Open safe files after download" turned on in Safari. What I don't understand is why Safari doesn't do the download validation when that setting is turned off.
And if you download the same file through...say...Firefox you get absolutely NO warning.

Not to worry if you use Apple's wonderful OEM software.
     
Big Mac
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Mar 13, 2006, 08:03 PM
 
Originally Posted by CharlesS
I say we should make the "Open with custom application" setting specific to the user that set it. It would open with the custom application when running under the user who set it that way, and would open with the default for everyone else. It would solve the problem of someone disguising a shell script as a JPG file and setting it to open with the Terminal, but it would also give specific benefits to the users - two different users could each set a file to open with a different application. Why should all users get stuck with opening a certain file with a certain app just because one user prefers it that way, anyway?
Until Apple gets its act together, perhaps you or another developer could rig up a folder action that would strip downloads of their custom application associations. Possible?

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 13, 2006, 08:24 PM
 
Originally Posted by alphasubzero949
And if you download the same file through...say...Firefox you get absolutely NO warning.

Not to worry if you use Apple's wonderful OEM software.
Don't forget if someone sends something through e-mail or iChat... or you get something on a CD-R...

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
TETENAL
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
Mar 13, 2006, 08:41 PM
 
Originally Posted by CharlesS
Don't forget if someone sends something through e-mail or iChat... or you get something on a CD-R...
Mail and iChat use the same download validation system as Safari does according to the tech notes of the latest two security updates (unfortunately I couldn't find which API that is, if somebody knows please tell).

Shiira still works fine for me.
( Last edited by TETENAL; Mar 13, 2006 at 08:55 PM. )
     
OAW
Addicted to MacNN
Join Date: May 2001
Status: Offline
Reply With Quote
Mar 13, 2006, 09:26 PM
 
Originally Posted by alphasubzero949
And if you download the same file through...say...Firefox you get absolutely NO warning.

Not to worry if you use Apple's wonderful OEM software.
Hence my suggestion above. The OS simply needs to warn the user the first time any executable launches .... and prompt the user to continue, cancel, or perhaps even trash the file. Problem solved.

OAW
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 13, 2006, 09:29 PM
 
Originally Posted by Big Mac
Until Apple gets its act together, perhaps you or another developer could rig up a folder action that would strip downloads of their custom application associations. Possible?
This is not an ideal solution, but I whipped up a quick-and-dirty droplet for you. Dragging a file onto this droplet should remove any "Open With" information that the file has. It should work, but keep in mind I put this together in about 30 minutes.

You could probably rig up a folder event to open all downloaded files with this droplet...

http://www.charlessoft.com/StripOpenWith.zip

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
rickey939
Addicted to MacNN
Join Date: Jul 2005
Location: Cooperstown '09
Status: Offline
Reply With Quote
Mar 13, 2006, 10:12 PM
 
I think Unsanity's solution is the best one...

http://www.unsanity.com/haxies/pa
     
mishakim
Forum Regular
Join Date: Oct 2000
Location: Boston
Status: Offline
Reply With Quote
Mar 13, 2006, 10:14 PM
 
Just a warning, this fails to update Safari if it isn't in /Applications. Just puts the updated components in a non-functional folder. Just like 5 years ago. Easy enough to fix, but a completely ridiculous flaw. How hard is it to make it SOP to NEVER hard-code where an app is when the OS is perfectly capable of finding it? It makes no sense to me that Apple's QC doesn't catch this - it slips through in about one update a year.
     
Hi I'm Ben
Mac Elite
Join Date: Dec 2001
Location: Chicago
Status: Offline
Reply With Quote
Mar 13, 2006, 10:33 PM
 
All my menu items went away. Crappy. Been trying to get my stuff working. It's not happening.
     
Big Mac
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Mar 14, 2006, 03:01 AM
 
Originally Posted by CharlesS
This is not an ideal solution, but I whipped up a quick-and-dirty droplet for you. Dragging a file onto this droplet should remove any "Open With" information that the file has. It should work, but keep in mind I put this together in about 30 minutes.

You could probably rig up a folder event to open all downloaded files with this droplet...

http://www.charlessoft.com/StripOpenWith.zip
Charles to the rescue!

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
rickey939
Addicted to MacNN
Join Date: Jul 2005
Location: Cooperstown '09
Status: Offline
Reply With Quote
Mar 14, 2006, 08:29 AM
 
Originally Posted by Hi I'm Ben
All my menu items went away. Crappy. Been trying to get my stuff working. It's not happening.
Do you have hacked version of Front Row on your machine? If so, remove it.
     
pastusza
Mac Enthusiast
Join Date: Nov 1999
Location: Bensalem, PA
Status: Offline
Reply With Quote
Mar 14, 2006, 01:56 PM
 
Originally Posted by rickey939
Do you have hacked version of Front Row on your machine? If so, remove it.
I opened the package in Pacifist and it does not update BezelServices.framework, which is what Front Row Enabler hacks. So I am at a loss as to why this would be an issue.

I have not installed the update yet, because I don't want to lose Front Row and of the other problems listed. Is the Front Row fix as easy as reinstalling BezelServices and rehacking it, or are there other issues?
Andy Pastuszak
amp68(spammenot)-at-verizon.net
     
Sophus  (op)
Mac Enthusiast
Join Date: Nov 2001
Location: Norway
Status: Offline
Reply With Quote
Mar 14, 2006, 04:00 PM
 
Originally Posted by pastusza
I opened the package in Pacifist and it does not update BezelServices.framework, which is what Front Row Enabler hacks. So I am at a loss as to why this would be an issue.

I have not installed the update yet, because I don't want to lose Front Row and of the other problems listed. Is the Front Row fix as easy as reinstalling BezelServices and rehacking it, or are there other issues?
I had the same. Reinstalling the combo update fixed it. Give it a try.
     
Hi I'm Ben
Mac Elite
Join Date: Dec 2001
Location: Chicago
Status: Offline
Reply With Quote
Mar 14, 2006, 07:43 PM
 
Originally Posted by rickey939
Do you have hacked version of Front Row on your machine? If so, remove it.
I did, and I didn't. But I did get it working.
     
pastusza
Mac Enthusiast
Join Date: Nov 1999
Location: Bensalem, PA
Status: Offline
Reply With Quote
Mar 15, 2006, 01:18 AM
 
Originally Posted by Sophus
I had the same. Reinstalling the combo update fixed it. Give it a try.
I had an issue with my menu extras after I installed Photoshop Elements 4. So I went to this web page and followed the instructions:

http://voice.firefallpro.com/2006/03...back-your.html

That got my menu extras back.

Just now I installed the security update and I did not have any problems with menu extras. My Front Row (hacked with Enabler 1.2.1) still works.

But I did get the following odd behavior:

My menu extras are in a slighty different order. The bluetooth extra is between my name and the spoltlight search. It used to be right next to the airport strength indicator.

My desktop preferences got blown away. My desktop icons were back to the default size and the desktop was not sorted.

Other than that, everything seems to be OK.

Andy
Andy Pastuszak
amp68(spammenot)-at-verizon.net
     
pastusza
Mac Enthusiast
Join Date: Nov 1999
Location: Bensalem, PA
Status: Offline
Reply With Quote
Mar 15, 2006, 01:18 AM
 
Originally Posted by Sophus
I had the same. Reinstalling the combo update fixed it. Give it a try.
I had an issue with my menu extras after I installed Photoshop Elements 4. So I went to this web page and followed the instructions:

http://voice.firefallpro.com/2006/03...back-your.html

That got my menu extras back.

Just now I installed the security update and I did not have any problems with menu extras. My Front Row (hacked with Enabler 1.2.1) still works.

But I did get the following odd behavior:

My menu extras are in a slighty different order. The bluetooth extra is between my name and the spoltlight search. It used to be right next to the airport strength indicator.

My desktop preferences got blown away. My desktop icons were back to the default size and the desktop was not sorted.

Other than that, everything seems to be OK.

Andy
Andy Pastuszak
amp68(spammenot)-at-verizon.net
     
alphasubzero949
Mac Elite
Join Date: Jan 2003
Location: 127.0.0.1
Status: Offline
Reply With Quote
Mar 15, 2006, 06:21 AM
 
Holy fscking sh!t.

http://www.rixstep.com/1/20060314,01.shtml

I got it to work on my machine running 10.4.5 with Security Updates 2006-001 and 002. The method may or may not work if you use the Finder (it didn't work for me). I used Xfile and the Terminal to both reproduce this POC.

Also works under 10.3.9, although I haven't personally tried it.

What makes this worse? You can EASILY make your own new preference file and reference it to arbitrary code without ever being asked to authenticate.
     
alphasubzero949
Mac Elite
Join Date: Jan 2003
Location: 127.0.0.1
Status: Offline
Reply With Quote
Mar 15, 2006, 06:21 AM
 
dp.
     
Big Mac
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Mar 15, 2006, 06:50 AM
 
Originally Posted by alphasubzero949
I don't feel like testing this POC (proof of concept for those wondering), but the page says to make sure you only have read access to loginwindow.plist. I'm on my iBook right now (10.3.9), and as admin I have only read access. Unless I'm missing something, the POC should not work.

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 15, 2006, 07:29 AM
 
You're missing something. Although the file is read-only to you, its enclosing folder (/Library/Preferences) is still writable to you, which means you can pretty much override the file's permissions with no trouble. You can rename the file, delete it and create a new one, etc. without root access.

The thing is, though, in Tiger (at least on my machines), login hooks don't run if they're specified in /Library/Preferences/com.apple.loginwindow.plist. They have to be specified in /var/root/Library/Preferences/com.apple.loginwindow.plist instead, which you don't have write access to in any way without root. I've tried this numerous times since Tiger came out (yes, I was actually quite upset and vocal about this bug when it still worked), and I just tried his example again, just in case something changed, and the result is the same as always - no file in /Users/Shared. I also remember seeing some forum posts on various forums shortly after Tiger came out from people complaining about how Tiger broke their login hooks, without realizing that they could still do it, but just needed to edit a different plist file.

So this also, unless I'm missing something, is something that was fixed long ago.

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
TETENAL
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status: Offline
Reply With Quote
Mar 15, 2006, 08:01 AM
 
Originally Posted by TETENAL
What I don't understand is why Safari doesn't do the download validation when that setting is turned off.
OK, it seems like I was wrong here. Sorry. The download validation is done regardless.
     
Person Man
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
Mar 15, 2006, 09:34 AM
 
Originally Posted by TETENAL
OK, it seems like I was wrong here. Sorry. The download validation is done regardless.
Oh, that's going to piss me off. They're treating us users like babies. Worse still, people will just click through it without reading it, and it won't be effective.
     
alphasubzero949
Mac Elite
Join Date: Jan 2003
Location: 127.0.0.1
Status: Offline
Reply With Quote
Mar 15, 2006, 12:55 PM
 
Originally Posted by CharlesS
You're missing something. Although the file is read-only to you, its enclosing folder (/Library/Preferences) is still writable to you, which means you can pretty much override the file's permissions with no trouble. You can rename the file, delete it and create a new one, etc. without root access.

The thing is, though, in Tiger (at least on my machines), login hooks don't run if they're specified in /Library/Preferences/com.apple.loginwindow.plist. They have to be specified in /var/root/Library/Preferences/com.apple.loginwindow.plist instead, which you don't have write access to in any way without root. I've tried this numerous times since Tiger came out (yes, I was actually quite upset and vocal about this bug when it still worked), and I just tried his example again, just in case something changed, and the result is the same as always - no file in /Users/Shared. I also remember seeing some forum posts on various forums shortly after Tiger came out from people complaining about how Tiger broke their login hooks, without realizing that they could still do it, but just needed to edit a different plist file.

So this also, unless I'm missing something, is something that was fixed long ago.

It's definitely NOT fixed in Tiger because using something other than the Finder to create the new com.apple.loginwindow.plist I was able to get the hooks to execute and have the rooted.txt file waiting for me in /Users/Shared. If you go through the Finder, for some reason the POC doesn't work.

I'm still investigating why or what it is about the Finder that the POC didn't work but this is certainly not my day job.
     
alphasubzero949
Mac Elite
Join Date: Jan 2003
Location: 127.0.0.1
Status: Offline
Reply With Quote
Mar 15, 2006, 01:33 PM
 
Originally Posted by Person Man
people will just click through it without reading it, and it won't be effective.
Just like Paranoid Android.
     
alphasubzero949
Mac Elite
Join Date: Jan 2003
Location: 127.0.0.1
Status: Offline
Reply With Quote
Mar 15, 2006, 01:35 PM
 
Okay guys, the Rixstep POC was updated with new instructions. He also now has a tidbit about MasterPasswordHint, which I stumbled on while going through the plist on my own machine (with the master password set).

     
Person Man
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
Mar 15, 2006, 01:37 PM
 
Originally Posted by alphasubzero949
Just like Paranoid Android.
Exactly.

This kind of hand-holding for people who are vulnerable to social engineering is not needed for the more knowledgeable, less-trusting folks in the first place. There should be a way to turn those warnings off.
     
Person Man
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
Mar 15, 2006, 01:42 PM
 
Originally Posted by alphasubzero949
Okay guys, the Rixstep POC was updated with new instructions. He also now has a tidbit about MasterPasswordHint, which I stumbled on while going through the plist on my own machine (with the master password set).

So don't give yourself an easily guessable hint.

For example, my password hint is "(greek word) + Old high school ID number."

Only I remember what my high school ID number is, and the word I use is the english translation, with some letters changed to other characters (like ! or 1 for i, @ for a, etc).

A random hacker stumbling across my hint won't be any wiser in obtaining the password.
     
alphasubzero949
Mac Elite
Join Date: Jan 2003
Location: 127.0.0.1
Status: Offline
Reply With Quote
Mar 15, 2006, 02:36 PM
 
Okay, here's why the POC will not work through the Finder.

If you duplicate com.apple.loginwindow.plist through the Finder, you get a binary plist file (indicated by bplist00). At first, the rooted.txt would not appear even though I followed the instructions as I tried using the Finder to carry out the instructions. Once I converted the plist to XML, well...

In order for the POC to work, you have to have a XML formatted plist.

Bottom line: If you do NOT have to authenticate AT ALL in (a) substituting your 'new' com.apple.loginwindow.plist file or (B) placing those hooks into /Library/Preferences, you've proven that the exploit works.

It seems that if you're running 10.4.0 or 10.4.1, you're 'safe' (notwithstanding the widget exploit).
( Last edited by alphasubzero949; Mar 15, 2006 at 02:53 PM. )
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 15, 2006, 04:09 PM
 
Just tried it, still no rooted.txt in my /Users/Shared.

Moving the com.apple.loginwindow.plist file to /var/root/Library/Preferences, though, does create the rooted.txt, even if the file is in binary format. So I don't think that's it.

Could you please post the exact, step-by-step process that led to the rooted.txt showing up on your machine?

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Big Mac
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Mar 15, 2006, 04:30 PM
 
Originally Posted by alphasubzero949
It seems that if you're running 10.4.0 or 10.4.1, you're 'safe' (notwithstanding the widget exploit).
To which widget exploit are you referring?

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
alphasubzero949
Mac Elite
Join Date: Jan 2003
Location: 127.0.0.1
Status: Offline
Reply With Quote
Mar 15, 2006, 05:06 PM
 
Originally Posted by CharlesS
Just tried it, still no rooted.txt in my /Users/Shared.

Moving the com.apple.loginwindow.plist file to /var/root/Library/Preferences, though, does create the rooted.txt, even if the file is in binary format. So I don't think that's it.

Could you please post the exact, step-by-step process that led to the rooted.txt showing up on your machine?
This is how I made it work on my system, although I used Xfile instead of the Finder. The key is that the substituted plist be in XML instead of binary:

1. Duplicate /Library/Preferences/com.apple.loginwindow.plist. Rename your original plist to something like com.apple.loginwindow.plist.old. Take the duplicated plist and rename it to com.apple.loginwindow.plist. This should be owned by you. If the plist is binary, convert it to XML (plutit -convert xml1).

2. Add the two hook files to /Library/Preferences and make sure that they are marked 0755 (again, with you as the owner).

3. Edit com.apple.loginwindow.plist to add the keys and values as described in the README supplied with the POC.

4. Reboot.

5. com.apple.loginwindow.plist will now be marked root:admin. You may already have the rooted.txt file there but if not, reboot once more (to ensure that both hooks are activated).

Although the substituted plist needs to be XML-formatted instead of binary, that doesn't change the idea that anyone can substitute in their own plist file, create hooks, and have the code run as root without any user authentication required whatsoever.
     
Big Mac
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status: Offline
Reply With Quote
Mar 15, 2006, 05:33 PM
 
Now Alpha, you just described three complex steps required for this vulnerability. Could a malicious application really secretly do all of those things? Apple can only lock things down so much. If one has to jump through hoops to allow an exploit to function, it does not seem like a vulnerability to me.

"The natural progress of things is for liberty to yield and government to gain ground." TJ
     
alphasubzero949
Mac Elite
Join Date: Jan 2003
Location: 127.0.0.1
Status: Offline
Reply With Quote
Mar 15, 2006, 06:29 PM
 
Originally Posted by Big Mac
Now Alpha, you just described three complex steps required for this vulnerability. Could a malicious application really secretly do all of those things? Apple can only lock things down so much. If one has to jump through hoops to allow an exploit to function, it does not seem like a vulnerability to me.
There's no hoop jumping at all.

(A) You were able to replace the com.apple.loginwindow.plist with your own WITHOUT authentication, right? The POC merely had you replace com.apple.loginwindow.plist with one of your own, owned by YOU (and in the XML format). While you had to do a conversion, anyone with a pre-made XML formatted plist could have easily slipped it in the directory.

(B) You were able to sneak in those hooks without authentication, right?

(C) Reboot. Now the plist is root and those hooks are running. Nothing 'complex' about it.

Getting the POC to work and having rooted.txt appear wasn't the point, being able to do those 3 without any authentication was. Once you can sneak the new plist in, you're in.

Once I figured out what the hell was going on, I've been able to consistently reproduce the results since and have the POC running.
     
CharlesS
Posting Junkie
Join Date: Dec 2000
Status: Offline
Reply With Quote
Mar 15, 2006, 08:13 PM
 
Originally Posted by alphasubzero949
This is how I made it work on my system, although I used Xfile instead of the Finder. The key is that the substituted plist be in XML instead of binary:

1. Duplicate /Library/Preferences/com.apple.loginwindow.plist. Rename your original plist to something like com.apple.loginwindow.plist.old. Take the duplicated plist and rename it to com.apple.loginwindow.plist. This should be owned by you. If the plist is binary, convert it to XML (plutit -convert xml1).

2. Add the two hook files to /Library/Preferences and make sure that they are marked 0755 (again, with you as the owner).

3. Edit com.apple.loginwindow.plist to add the keys and values as described in the README supplied with the POC.

4. Reboot.

5. com.apple.loginwindow.plist will now be marked root:admin. You may already have the rooted.txt file there but if not, reboot once more (to ensure that both hooks are activated).

Although the substituted plist needs to be XML-formatted instead of binary, that doesn't change the idea that anyone can substitute in their own plist file, create hooks, and have the code run as root without any user authentication required whatsoever.
Just tried your steps, except:

a. I used the Finder and the Terminal instead of Xfile, because I don't know what Xfile is and can't find it using MacUpdate, VersionTracker, or Google (well, I did find something called Xfile, but it was a Photoshop plugin).

b. I only made the LoginHook, not the LogoutHook, since it didn't seem necessary to have both to demonstrate this.

The login hook was in the plist file, the plist file was in XML format, and the login hook was executable. I tried logging out then back in, and rebooting. In both cases, no rooted.txt shows up in /Users/Shared. It does, however, show up if I put the login hook in the plist file in root's home folder.

Weird.

Oh, and Big Mac: Hoop jumping isn't an issue for a computer program (like a virus). Computer programs, unlike humans, are great at doing extremely repetitive and complex things. The procedure could be much more complex than what was described above, and that wouldn't pose much of a problem for a computer program...

Ticking sound coming from a .pkg package? Don't let the .bom go off! Inspect it first with Pacifist. Macworld - five mice!
     
Hal Itosis
Grizzled Veteran
Join Date: Mar 2004
Status: Offline
Reply With Quote
Mar 16, 2006, 04:46 PM
 
-HI-
     
Person Man
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
Mar 16, 2006, 04:54 PM
 
Originally Posted by Hal Itosis
It's the same update as before, it just fixes a few bugs in the original update. That's why the number is still 002.
     
rickey939
Addicted to MacNN
Join Date: Jul 2005
Location: Cooperstown '09
Status: Offline
Reply With Quote
Mar 16, 2006, 04:54 PM
 
Originally Posted by Hal Itosis
I'm officially confused.® What does this v1.1 due/fix/break?

     
Person Man
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status: Offline
Reply With Quote
Mar 16, 2006, 05:30 PM
 
Originally Posted by rickey939
I'm officially confused.® What does this v1.1 due/fix/break?

Presumably corrects bugs in update 2006-002. It fixes nothing new. Otherwise the number would be 2006-003.
     
Morpheus
Forum Regular
Join Date: Jun 2002
Status: Offline
Reply With Quote
Mar 16, 2006, 05:34 PM
 
Maybe it just kills FrontRow anew...
     
 
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 12:54 PM.
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.,