Slashdot Mirror
New Attack Bypasses Mac OS X Gatekeeper
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.
OSX only checks the verification of the app if it sees that it is downloaded from a nonlocal source. If you download an unverified application, view package contents, and copy the files within to another folder and rename it with the .app extension, you can open anything! No admin rights required unless it requires an install!
So even without the little pi symbol Gatekeeper is still full of holes.
It's not signed code per-se, but nvidia does provide checksums from the website:
cuda_7.5.18_linux.run (md5sum: b22ef6bc073f7cf767f547a84fb0e3c2)
(see https://developer.nvidia.com/c... for more versions)
If your unfamiliar with how to use a checksum, I suggest reading http://lifehacker.com/247262/h...). Basically though, if they don't match, don't trust it.
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?
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 for that.
The current solution of signing by third-party is not without drawback: time/delay is a key issue as they cannot possibly verify any software that is just released a few days ago, and commercial softwares are self-signed since they wouldn't allow their softwares to be distributed freely. Also they don't really verify new versions of existing softwares.
But it's still far more suitable than having developers doing all the signings by themselves.
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.
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.
If a user doesn't know how and can't figure out or google how to bypass Gatekeeper, they shouldn't be bypassing Gatekeeper. I'm a Mac developer and I work on a commercial application that uses a privileged helper tool which the app loads using SMJobBless and that tool is managed by launchd and executed as root. We are an identified developer and we sign our app as such. We don't distribute via the App Store and we are about to ship a new version that adds a kernel extension that I wrote. In recent versions of MacOS X, kernel extensions must be signed and they have to at least by signed by an identified developer who has applied for a kernel extension signing certificate. One of the scenarios that I pay attention to as far as security goes is that our daemon (aka "privileged helper tool") executes other processes and also controls the loading and unloading of our kernel extension. Most of those processes, and our kernel extension, are located in our application bundle. I wanted to avoid making dumb assumptions like that our application is running from a particular path, so the app communicates to the daemon via XPC and tells the daemon where the app bundle is located. The daemon doesn't just trust the app. It verifies that the app is code signed and that it is our app and that it hasn't been modified before it starts executing things or loading kernel extensions from inside the app bundle. I can easily imagine a scenario where an app could call our daemon and tell it some other location and cause us to execute malware if we didn't do this. Since I'm not a security expert, I constantly worry that someone will find a way to do this and I just hope we never become an attack vector. I do not want my product on Slashdot because of a security problem.
Avoid Missing Ball for High Score
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 works.
"So long and thanks for all the fish."
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.
"So long and thanks for all the fish."
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.
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 code signature, nested code can be replaced ... without disturbing the outer signature.
Throughout the Apple documentation, you will find references to the "main exectuable ". This is the file that's primarily protected. In my example above, that's setup.exe.
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 course be pretty safe too. If you're paranoid, you can keep the test hardware only for malware testing - never move a box from testing to production. That adds a layer of protection against damage from firmware exploits.
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?
I work for the Department of Redundancy Department.
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; since it does seem like a somewhat exploitable hole.