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.
is a bad name then.
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!
Please can they put it in all Applications as Apple keeps resetting my security settings with each release of OS X - I now have to unlock and 'Allow from anywhere' several times a year.
0. bug found
1. bug reported
2. bug acknowledged (*)
3. bug fixed
4. bug fix in testing
5. fix scheduled for release TBA
(*) So the only newsworthy item is that Apple actually acknowledged they had a bug. Something they never do, having given them may test cases myself
AC: NDAs are legal you know.
So even without the little pi symbol Gatekeeper is still full of holes.
Does Linux have any concept of signed executables? It would be nice to know if ./nvidia_installer.run is an authentic NVIDIA binary, for example.
To tell us how this is overblown, don't get hysterical..
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
Ooops... 20 year old exploit that exists in most x86 chips that allows you to escape VMs/Hypervisors....
The Memory Sinkhole
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.