New Attack Bypasses Mac OS X Gatekeeper 66
msm1267 writes: Mac OS X's Gatekeeper security service is supposed to protect Apple computers from executing code that's not signed by Apple or downloaded from its App Store. A researcher, however, has built an exploit that uses a signed binary to execute malicious code. Patrick Wardle, a longtime Apple hacker, said Gatekeeper performs only an initial check on an application to determine whether it came from an untrusted source and should not be executed. Using a signed binary that passes the initial check and then loads a malicious library or app from the same or relative directory, however, will get an advanced attacker onto an OS X machine. Wardle disclosed his research and proof of concept to Apple, which said it is working on a patch, and may push out a short-term mitigation in the meantime.
Re:Gateskeeper (Score:4, Informative)
I get that this is possible and all, but I think I'm failing to understand the threat posed by it that's any different from what was possible already by design. Gatekeeper has three settings (paraphrasing; #2 is the default, from what I recall):
1) Mac App Store only
2) Apps from registered developers only
3) Anything goes
It's already quite possible for a ($99/year) registered app developer to release a trojan and distribute it via the Internet to anyone using settings #2 and #3, but if they do so, Apple has been quick to revoke their certs (preventing all of their apps from installing on anyone's Mac using settings #1 or #2), pull their apps from the Mac App Store, and add the malware to OS X's built-in malware blocker that gets updated nightly.
This attack seems to rely on the actual bulk of the malware being downloaded separately from the main app that's been signed, which means that, as has been the case up until now, the user still needs to be coerced into downloading the malware themselves somehow. The only difference I can see (besides the addition of a lot of complication that makes the attack more difficult to accomplish) is that if the dummy app is able to be distributed via the Mac App Store, this may be a way to target users with setting #1, since otherwise the malicious payload would need to get through Apple's app review process. But if that's all that this attack brings to the table, it isn't much, since setting #2 is the default, meaning the target audience for this attack is particularly limited and that (by design) there are already easier ways to hit the bulk of users. Moreover, Apple's response would no doubt be exactly what we'd expect: to revoke the certs, pull the apps from the Mac App Store, and add the app to their malware blocker, meaning that the attack will stop working overnight.
Am I missing something more sinister here?
Bug is I can modify code signed by Apple (Score:5, Informative)
The exploit is for users with #2, registered developers. A bad guy who is not a registered developer can publish code which appears to be signed by a trusted developer.
The root of the problem is that it checks a signature on the -executable-, not the -package-. A typical package has a setup executable, which we'll call setup.exe. That's signed by Apple, Adobe, or whoever the developer is.
Setup.exe loads whattodoo.dll and runs some functions in it, then runs register_filetypes.exe, does some other stuff, then runs photoshop.exe. Neither whattodo.dll, register_filetypes.exe, photoshop.exe, nor the package the came in need to be signed. MOST of the executable code isn't signed.
A bad guy can download the Photoshop package and replace whattodo.dll and register_filetypes.exe with code of their choosing. Just rename backdoor.dll and botnet.exe. Mac treats it as signed because setup.exe is signed.
So the victim would download a malicious package and because setup.exe is signed, OSX would run it by default- thereby running backdoor.dll (renamed as whattodo.dll) and botnet.exe (renamed as register_filetypes.exe).
This is normally avoided on Linux by signing / hashing the entire package, not just one file in the package.
Re: (Score:2)
Gotcha, thanks for the explanation. That clears up my misunderstanding quite a bit. I appreciate it!
Re: (Score:1)
What kind of crack are you smoking? There are no .exe files in OS X.
No shit, Sherlock; it also doesn't have Windows DLLs, either, but he didn't say either thing. He implied he was using hypothetical terms and names with the first sentence he said "setup.exe" in: " A typical package has a setup executable, which we'll call setup.exe."
What he did is similar to using pseudocode to explain logic concepts without requiring understanding of a specific programming language. In this case, he just used Windows terminology to explain a general computing concept. I use Linux and s
I can name it .exe if I want to. (Score:2)
On real operating systems, including OS X, the executable can have any name I want it to have. If I want to name it setup.exe, I will.
I -could- have named the exectuable icon.png, but that would make the explanation much harder for idiots like yourself to follow.
Re: (Score:2)
I think you've got that ass-about-face. Gatekeeper only checks the signatures on .app files - Apps or Applications as downloaded from the App Store and various web sites. The .app files are essentially .zip archives containing a bunch of executables, library files, media content, configuration data, etc. Every other executable on the system is not even checked by Gatekeeper which is why people are still able to use
not downloaded , but included outside of signature (Score:3)
I simplified a bit. The malicious code can be inside of the .app package- it does not need to be downloaded separately. It LOOKS like the signature is on the package, but it's not. It's on some parts of the package. Here's a quote from the Apple developer documentation for you:
Changes That Don't Invalidate a Code Signature
There are a few changes you can make to a signed bundle that won't invalidate its signature.
If you have optional or replaceable content you wish to change without invalidating the co
There's an even greater flaw here. (Score:5, Interesting)
Re: (Score:1)
Yet its still better than anything that Microsoft can come up with.
Re: (Score:1)
My niece switched to a Mac. Bam... Day one. She's seemingly got something called "MacHelper" or something akin to that. Sounds innocuous but it's really not - it's sort of ransom ware from what she described. She called me up wanting me to help. Good luck with that. I have no idea how to help except to follow directions at Google.
Re: (Score:2)
Yet its still better than anything that Microsoft can come up with.
System Integrity Protection is akin to Windows Resource Protection - which has been in Windows since Vista. Welcome to 2006.
Re: (Score:1)
What? The ability to run any application they want on a PC platform?
If MacOS is a Unix, then it shouldn't need to be treated like such a delicate flower. The user should be able to safely run programs without having them blessed by the OS vendor.
Re: (Score:3)
They have the ability to run anything, Gatekeeper is just there to stop an accidental run without some purposeful action to make sure you really want to run it... then after that it doesn't stop you because that would be stupid. After all, you already indicated you wanted to run it by specifically telling Gatekeeper to allow it.
Re: (Score:3)
You can disable the check, you know.
Re: (Score:1)
He's already a fucking idiot, because OS X doesn't prompt for files, only executables.
Re: (Score:3)
I think it's starting to be proven that an axiom like that about Unix systems is not entirely accurate.
Re: (Score:2)
How does one "safely" run any program? That's a question we've been trying to answer since the dawn of programs.
virtual machine. That's how we run malware on purp (Score:2)
We run malware on purpose. In a simple virtual machine. Simple matters - when you do tricky stuff like sharing storage between the VM and the host, it may open vulnerabilities.
yes one bug, fixed years ago. Compare Windows (Score:2)
Yes, virtualization isn't guaranteed to always be 100% perfect. There was one bug that was fixed years before it became public. Compare the number of bugs in Windows over the last 10 pr 20 years. I'd say running within the hypervisor is several orders of magnitude safer.
As I mentioned, that's one reason we use the simplest practical virtualization- to avoid bugs in hypervisor features or related utilities. It's pretty darn effective, though not 100% perfect.
Air gaps and disposable images can of cours
Re:There's an even greater flaw here. (Score:5, Insightful)
Huh?
Gatekeeper is not meant to block any unsigned code execution. It's meant to stop you accidentally running malware. If you want to bypass it you can just right click on a .app and click "open", or you can disable it in System Preferences. The "attack" you just described is no attack at all.
It's not even clear to me that what's being described in the article is even an attack. OK, you can bypass Gatekeeper by finding an app that blindly runs code it knows nothing about. That's like complaining that if you run a signed browser and then it executes a malicious web page, bad things happen. That's not a bug in Gatekeeper. That's a bug in the browser.
Re: (Score:2)
I'd think the only solution would be to make every single executed snippet of code signed. I don't really know if that's possible though.
Re: (Score:2)
It's not even clear to me that what's being described in the article is even an attack.
Then what is Apple patching?
Re: (Score:2)
Yeah. Seeing a gatekeeper bypass I was expecting, well, you know, something that actually *bypassed* gatekeeper. This in no way shape or form is a bypass.
It *would* be considered a bypass on iOS, but that is because that platform attempts to prevent any unapproved code from executing. That is not a design goal of OS X. Irrelevant.
Re: (Score:3)
I hate it when I accidentally copy the contents of an apps package contents to another folder, renamed it with a .app extension, and execute it only to find there is malware inside.
Re: (Score:1)
Re: (Score:1)
I use Linux and, sometimes, BSD. I kind of like having to enter a password to do shit. I like needing sudo gksudo su etc... I don't mind the extra time. I do like the extra safety. I don't even venture out of the blessed repositories much these days. I prefer signed code and, in Linux, it's usually all signed but, honestly, I seldom check anything as I don't really stray far from the nest any more. I like my stuff to just work. I have some very complicated stuff at home and, yet, it generally always just wo
History repeats itself? (Score:4, Funny)
Re: (Score:2)
cuda_7.5.18_linux.run (md5sum: b22ef6bc073f7cf767f547a84fb0e3c2)
(see https://developer.nvidia.com/c... [nvidia.com] for more versions)
If your unfamiliar with how to use a checksum, I suggest reading http://lifehacker.com/247262/h... [lifehacker.com]). Basically though, if they don't match, don't trust it.
Re: (Score:2)
On Linux the installation packages are signed (by third-party), not the executables.
Signed executables pose two serious problems:
1.The developers are effectively signing by themselves. Windows malware authors have no problem buying keys from Microsoft to sign their rookits as certificated drivers - until they're found.
2.Non-executable parts (anything non-ELF on Linux) are left for developers themselves to verify: such as VIM plugins/scripts. Most of them would never bother to develop comprehensive system fo
Re: (Score:1)
I don't see Macs4All or CanadianMacFan in here, either. There's usually a few more. Anyhow, Gibson, of GRC fame, is pretty level headed. I admire his work greatly. He's also a very eloquent conversationalist though much of what he says goes a bit over my head. He's pretty bright or I'm pretty stupid - both could be true.
Re: (Score:2)
I don't see Macs4All or CanadianMacFan in here, either. There's usually a few more. Anyhow, Gibson, of GRC fame, is pretty level headed. I admire his work greatly. He's also a very eloquent conversationalist though much of what he says goes a bit over my head. He's pretty bright or I'm pretty stupid - both could be true.
Honestly, I didn't see this article until just now.
.app Package, rather than just the Launch executable. But without digging into it, it seems like Gatekeeper was designed to strike a reasonable balance between "utterly safe" (which NOTHING is) and making Developers have to re-sign code every single time they update something in the App Bundle.
Gatekeeper isn't perfect, and I agree that if it were me designing the feature, it would have signed the
My feeling is that Apple may change that policy, though;
Gatekeeper (Score:5, Interesting)
was there responsible disclosure? (Score:2)
Did they notify Apple of the problem and wait before publishing the details on the exploit, to give them a chance to push a fix before releasing the information to the public? It looks like they threw out the details of the hole into the wild before giving anyone a chance to patch it?