How to evade Apple's anti-malware Gatekeeper in OS X and really ruin a fanboy's week The myth that Macs are inherently more secure than Windows PCs has taken another hit. Patrick Wardle, a former NSA staffer who now heads up research at crowdsourced security intelligence firm Synack, has found a new route around Apple's defensive Gatekeeper technology. Apple's Gatekeeper utility is built into OS X, and is …
The whole fake XCode thing is clearly something that only competitors would do to damage Apple. And to work it needed some criminal employee inside Apple working for them to validate the illegal keys and let the illegally compiled apps to bypass all security checks with no warnings during the review and test phase.
And clearly anyone that downloaded XCode not from Apple servers directly is a criminal as well and Apple should sue all of them.
Any legit developer would have no reason to download XCode or any other Apple tool from non Apple servers.
This post has been deleted by its author
A bit redundent given El Reg's concise explanation of a very simple concept - but one that worryingly wasn't picked up by the Gatekeeper team at 1Infinite Loop.
If software does have an external dependency (that isn't just input, conditions or settings) then it shouldn't be a mystery and so can't it just be given to Gatekeeper as well?
The picture I drew in my minds eye was based on my previous experience of copying older/patched DLLs into install/Env paths to get things working on various Windows versions!
I don't believe there's currently a way to sign dynamic libraries (basically the same as a UNIX .so).
It's an interesting one to fix because .apps have a directory structure with a manifest, resources, certificate, and so on which Gatekeeper needs whereas a dynamic library is just a single file.
Could the manifest not list a checksum of the dependent libraries required by the application?
e.g. (okay this is done on Linux but you get the idea)
RC=0 stuartl@rikishi ~ $ ldd /usr/bin/gimp | grep =\> | sed -e 's:^.*=> \([^ ]\+\) *.*$:\1:g' | xargs sha256sum
ad17d2a39d837d3a0441ff42b9cb806a2ec3541b68d4d140cb46320ae7086011 /usr/lib64/libgimpwidgets-2.0.so.0
…
707eeeabc0ca8a4ee4dfd808861c57be3e3401815d24c64bfed30b5a820e40ee /usr/lib64/libXxf86vm.so.1
You could "normalise" the paths in that list, and throw that in with the manifest to be signed with the rest of the bundle. As for library updates, it ships with a signed manifest of compatible previous version checksums which can be checked.
>>As for library updates, it ships with a signed manifest of compatible previous version checksums which can be checked.
>Quite different to statically linking.
I asked about future versions, not past versions; e.g. a new version of OpenSSL is issued because of a bug. Assuming the OpenSSL people have done their homework, it should be compatible. But now we have to wait for manifests to be updated and then download the app.
Or, the people packaging the updated OpenSSL can release a manifest of checksums that that OpenSSL build should be backward-compatible with.
i.e. the application nominates that it is compatible with library with checksum X.
Library version A (with checksum X) gets updated. New version has checksum Y. They ship a manifest that states that library is also compatible with version having checksum X.
When launched, OS loader sees application needs library with checksum X, looks up its database, finds that Library version B provides a version with checksum Y, that is backward compatible with X, loads Y instead as a compatible substitute.
All blobs are checked for compatibility and integrity. ABI changes are handled, as is, unauthorised edits to the binaries.
I don't believe there's currently a way to sign dynamic libraries (basically the same as a UNIX .so).
There may not currently be a way, but it's a trivial problem that's already been solved for dynamic libraries on other platforms (e.g. signed assemblies in Microsoft .NET).
I don't see anything preventing Apple from defining another segment type for the Mach-O file format, which is what OS X uses for dynamic libraries (aka shared objects), and putting the signature and whatever else you might want in it. Compound file formats that contain the signature of the file itself are widely used.
In fact, if the dynamic loader already ignores segment types it doesn't recognize, anyone should be able to implement this now, without any changes to OS X. Obviously they'd also have to supply the code that checks for and verifies the signature - but the app that uses the dynamic library could do that, after explicitly loading the library. It's more work, but it's not complicated.
"The myth that Macs are inherently more secure than Windows PCs has taken another hit."
The myth takes a hit because it is not a myth. It is difficult for anything to be as insecure as Windows. Like many products, Windows base is insecure. This is fixed by putting security layers on top of it.
OS X however, starts with a much more secure base, so is inherently more secure.
However, it is true that most of OS X is, like Windows, also written in C. C is the cause of most of our security woes, so even Apple must work to overcome this, but not to the extent of Windows. Problem with C is it makes it too easy to subvert systems written in C. It is an old language with many flaws (flaws which weren't in other languages of the 1960s) and it is about time it was retired.
The cynical might say that Gatekeeper is not just about security per se but to prevent "side loading" of apps i.e. any app not in the sanctioned app store
The app store "vetting" process is heavily hyped for efforts to try & spot & stop malware including apps, which is a good thing.
However, apps can also be rejected for a variety of other non security related reasons - some censorious, but many of which are to stop cash getting away from Apple e.g. bypassing apples payment methods to buy extra in app functionality, buttons that link to external websites to buy things.
Various ill defined censorship related restrictions on apps with violence, offensive content, offensive commentary (unless you are a sufficiently well known enough satirist / comedian then you can say what you like) .. and obv no hard pr0n apps & bizarrely no emulators.
.. whose software you can never check because all you download yourself is an installer.
They really ought to stop that crap, but I suspect they never will. As soon as the BBC gets their HTML 5 act together, the last remnants of Adobe will be gone from my machine.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
