macOS X GateKeeper Bypass(fcvl.net)
fcvl.net
macOS X GateKeeper Bypass
https://www.fcvl.net/vulnerabilities/macosx-gatekeeper-bypass
51 comments
I don't believe this feature is specific to macOS and the zip format. I'm reasonably certain it's possible to `tar` a symbolic link in Windows, Linux, or macOS.
I can really not see any reason that NFS automounter should be enabled by default on a macOS system.
That should be disabled by Apple, if not removed completely.
That should be disabled by Apple, if not removed completely.
It is also specifically allowed outbound through Little Snitch 4 to the entire Internet by default which seems very insecure to me.
I may not be entirely right about this, but I believe that Gatekeeper relies on xattr to mark files as quarantined. This is a feature that I wouldn't expect to be available when mounting non-Apple filesystems.
If this is the case, a potential solution is to track external mounts and to prompt a user when accessing a new drive for the first time, especially in the case that the OS has read or written a new symbolic link pointing to an external file system.
I agree with other commenters who say that the NFS auto-mounter should likely default to off on fresh installs. If there is a concern about this breaking enterprise configurations, set NFS to default into a prompt before mounting mode.
As far as the issue of symbolic links in zip files, I'm not sure there's much to be done (except perhaps issuing a warning that would be difficult for most users to parse). I mentioned elsewhere that this functionality is not unique to macOS or to zip.
The final issue that I see is that Finder hides so much metadata (which could be useful for a reasonably sophisticated user). I'd like to see a prominent indication of a cross-filesystem symbolic link. Likewise, it'd be worthwhile to have a clear visual indication when browsing a remote file system.
If this is the case, a potential solution is to track external mounts and to prompt a user when accessing a new drive for the first time, especially in the case that the OS has read or written a new symbolic link pointing to an external file system.
I agree with other commenters who say that the NFS auto-mounter should likely default to off on fresh installs. If there is a concern about this breaking enterprise configurations, set NFS to default into a prompt before mounting mode.
As far as the issue of symbolic links in zip files, I'm not sure there's much to be done (except perhaps issuing a warning that would be difficult for most users to parse). I mentioned elsewhere that this functionality is not unique to macOS or to zip.
The final issue that I see is that Finder hides so much metadata (which could be useful for a reasonably sophisticated user). I'd like to see a prominent indication of a cross-filesystem symbolic link. Likewise, it'd be worthwhile to have a clear visual indication when browsing a remote file system.
Why are external drives and NFS shares considered trusted to begin with?
Internal drives are, too.
Gatekeeper (in a wider sense) actually is two things:
Firstly, it is a user setting choosing what software to trust: only software downloaded from the Mac App Store, everything that’s signed, or ‘everything’.
The first two settings require applications to be signed. That doesn’t say anything about whether they are safe to run, but it does allow Apple to find out who developed malware, if it is discovered.
Secondly, applications that download executables can opt in on signaling to Gatekeeper “the first time the user runs this executable, ask for user confirmation”. They do that by setting an extended file attribute on the executable. Gatekeeper removes it if the user indicates the executable can be run.
Neither feature cares from where the executable is launched. External drives are very common (think USB drives), so they ‘had’ to be included. I would guess NFS shares slipped through the net, but possibly, there are companies that use NFS shares.
Of course, that “opt-in” is a weak point. They couldn’t do a lot better because, when Gatekeeper was introduced, users already had lots of executables, and they didn’t want users to pick the ‘everything’ option after being bombarded with Gatekeeper dialogs.
Gatekeeper (in a wider sense) actually is two things:
Firstly, it is a user setting choosing what software to trust: only software downloaded from the Mac App Store, everything that’s signed, or ‘everything’.
The first two settings require applications to be signed. That doesn’t say anything about whether they are safe to run, but it does allow Apple to find out who developed malware, if it is discovered.
Secondly, applications that download executables can opt in on signaling to Gatekeeper “the first time the user runs this executable, ask for user confirmation”. They do that by setting an extended file attribute on the executable. Gatekeeper removes it if the user indicates the executable can be run.
Neither feature cares from where the executable is launched. External drives are very common (think USB drives), so they ‘had’ to be included. I would guess NFS shares slipped through the net, but possibly, there are companies that use NFS shares.
Of course, that “opt-in” is a weak point. They couldn’t do a lot better because, when Gatekeeper was introduced, users already had lots of executables, and they didn’t want users to pick the ‘everything’ option after being bombarded with Gatekeeper dialogs.
NFS as a technology is only supposed to be used between systems controlled by the same domain administrator. E.g. university lab computers mounting user home directories from said university's disk servers. Mounting an NFS share (or setting policy allowing an NFS share to be mounted) is an implicit grant of trust—in both directions.
I say "in both directions" because, even more crazily, unless the NFS server is just for anonymous guest access, it's trusting the client connecting to it to assert which users the client is operating on behalf of. Anyone who can connect to an NFS server as a non-"nobody" user, can create or modify files as if they were root or whichever other UID they like. (Basically, the only authorization ACLs the NFS server tracks are for the client device. Users don't log into NFS servers; devices do.)
NFS really only works securely, in use-cases where both sides of the NFS connection are managed devices that don't let anyone except the domain administrator (including people with physical access to the hardware!) become root on them. (Or, I guess, when you're just standing up a read-only disk server to serve a rootfs to a bunch of thin clients. "PXE boot to NFS" is a pretty cool setup, though one that's been mostly superceded by streaming big initramfs images to client memory on boot.)
The reason for the NFS automounter in macOS, is that macOS actually used to use NFS to implement Portable Home Directories (Apple's answer to Windows' Roaming User Profiles.) This feature would only even kick in if the user profile with the NFS path as its homedir, came from your network OpenDirectory domain. (I believe the NFS server and the OpenDirectory server had to both share the same Kerberos auth realm, too.) So, in other words, your device would have to be a fully "managed" one—one of the very devices mentioned above, that doesn't even let its physical possessor become root on it—before the OS would ever deign to provide the NFS automounter anything to chew on.
The automounter itself was never really secured, though; all the security was in the glue determining what the automounter could "see." (You can't really secure the automounter itself without breaking the semantics of "transparent access to NFS shares of your domain." And if you're not locked into legacy 1970s-timesharing-BSD-cluster network semantics, then you may as well just drop NFS and use a better technology like SMB.)
I say "in both directions" because, even more crazily, unless the NFS server is just for anonymous guest access, it's trusting the client connecting to it to assert which users the client is operating on behalf of. Anyone who can connect to an NFS server as a non-"nobody" user, can create or modify files as if they were root or whichever other UID they like. (Basically, the only authorization ACLs the NFS server tracks are for the client device. Users don't log into NFS servers; devices do.)
NFS really only works securely, in use-cases where both sides of the NFS connection are managed devices that don't let anyone except the domain administrator (including people with physical access to the hardware!) become root on them. (Or, I guess, when you're just standing up a read-only disk server to serve a rootfs to a bunch of thin clients. "PXE boot to NFS" is a pretty cool setup, though one that's been mostly superceded by streaming big initramfs images to client memory on boot.)
The reason for the NFS automounter in macOS, is that macOS actually used to use NFS to implement Portable Home Directories (Apple's answer to Windows' Roaming User Profiles.) This feature would only even kick in if the user profile with the NFS path as its homedir, came from your network OpenDirectory domain. (I believe the NFS server and the OpenDirectory server had to both share the same Kerberos auth realm, too.) So, in other words, your device would have to be a fully "managed" one—one of the very devices mentioned above, that doesn't even let its physical possessor become root on it—before the OS would ever deign to provide the NFS automounter anything to chew on.
The automounter itself was never really secured, though; all the security was in the glue determining what the automounter could "see." (You can't really secure the automounter itself without breaking the semantics of "transparent access to NFS shares of your domain." And if you're not locked into legacy 1970s-timesharing-BSD-cluster network semantics, then you may as well just drop NFS and use a better technology like SMB.)
The author says it works "<= 10.14.5", but no mention of the current beta available, 10.14.6. I wonder if the beta fixes this.
FWIW, on macOS Mojave 10.14.6 Beta (18G29g), /etc/auto_master still looks like this:
#
# Automounter master map
#
+auto_master # Use directory service
/net -hosts -nobrowse,hidefromfinder,nosuid
/home auto_home -nobrowse,hidefromfinder
/Network/Servers -fstab
/- -staticI noticed that automounter entry recently and was like "wait, why did I have this?"
OTOH I might have left it in there to make it easier to mount NFS volumes.
OTOH I might have left it in there to make it easier to mount NFS volumes.
[deleted]
The author disabled resizing (zooming) on mobile, leaving the text unreadable. Why do people do this at all? I've seen it happen so often.
Zooms fine for me on my iPhone 7. Reader mode also works, which is like a magic fix crappy website button nowadays.
Tangentially, had anyone noticed a weird zooming bug on mobile safari that appears to cancel a zoom gesture and jump back to the unzoomed view? Quitting the app from the app switcher appears to fix it.
Tangentially, had anyone noticed a weird zooming bug on mobile safari that appears to cancel a zoom gesture and jump back to the unzoomed view? Quitting the app from the app switcher appears to fix it.
Safari on iOS has been ignoring the user-scalable=no viewport setting since iOS 10. This was done to improve accessibility for the users.
> “Tangentially, had anyone noticed a weird zooming bug on mobile safari that appears to cancel a zoom gesture and jump back to the unzoomed view? Quitting the app from the app switcher appears to fix it.”
yes, it happens on my ipad pro running ios 12.2 (16E227). have been meaning to upgrade thinking that would fix it, but maybe that’s not the case?
yes, it happens on my ipad pro running ios 12.2 (16E227). have been meaning to upgrade thinking that would fix it, but maybe that’s not the case?
Happens on my iPad Pro in the latest 12.4 betas, I can only bypass it by slowing down as I’ve zoomed in, a quick gesture snaps back and is ignored, but a quick gesture followed by waiting a second seems to preserve the zooming in. It happens most often on this site, for me, probably because I’m trying to zoom in to click tiny links, even on an iPad Pro.
I had noticed that it appears to happen a lot here on HN but I didn’t want to say incase of confirmation bias.
What you are seeing is the default way a website looks on a mobile device, not anything that was opted into. The site does not 'disable resizing', it just doesn't have any mobile support. The author has chosen, thus far, not to put in the effort to support mobile sizes well.
Zooming works on both Chrome & Firefox for me. (Android)
Zooms just fine on Firefox 67.0 on Android. Even goes into 'reader mode' and is zoom-able there on the same.
What browser/mobile OS are you using?
What browser/mobile OS are you using?
My guess is they want it to look like man pages
The accessibility options of your browser should let you forcibly enable zooming regardless of what the author mandates.
jasonmp85(2)
This is an interesting bug. But is it a good idea for an attacker to allow for wide-open NFS mounting of their attack server?
It isn't really a problem. Attacker would probably not run it on their own computer but some other compromised computers instead. It also doesn't have to be full NFS server but only the minimal functionality to deliver single file.
“Since Apple is aware of my 90 days disclosure deadline, I make this information public.”
Great, so now, potentially, there are lots of people who will lose all of their baby photos, lose money or even their contact with people who are important to them just because of some arbitrary number of days you made up and because you feel slighted by apple.
This could have real consequences and you can’t expect a big company to move faster just because you want them to. I have now knowledge of the internals of the development of MacOS, but maybe this isn’t trivial to fix.
Great, so now, potentially, there are lots of people who will lose all of their baby photos, lose money or even their contact with people who are important to them just because of some arbitrary number of days you made up and because you feel slighted by apple.
This could have real consequences and you can’t expect a big company to move faster just because you want them to. I have now knowledge of the internals of the development of MacOS, but maybe this isn’t trivial to fix.
Being a big, bureaucratic leviathan of a company does not resolve you of the responsibility to protect your users. For all you know, hackers have already been exploiting this secretly, and being public, with a workaround now gives you a plausible chance to defend yourself where there was none before.
> Being a big, bureaucratic leviathan of a company does not resolve you of the responsibility to protect your users.
I never said they shouldn't do anything, I said that releasing this information before there is a patch for the vulnerability strikes me as wrong.
I never said they shouldn't do anything, I said that releasing this information before there is a patch for the vulnerability strikes me as wrong.
They didn't ask for an extension, and many vendors do ask for more time. they simply ignore a potentially massive issue.
"..This issue was supposed to be addressed, according to the vendor, on May 15th 2019 but Apple started dropping my emails."
I believe Apple could easily have asked for an extension, if solving it was complex.. Apple chose not to.
(from the information available to us..)
I believe Apple could easily have asked for an extension, if solving it was complex.. Apple chose not to.
(from the information available to us..)
Indeed, many security researchers are willing to extend their disclosure deadlines if the vendor gives good reason to and shows that they're taking it seriously.
"on May 15th 2019 but Apple started dropping my emails"
What does that mean? Is there proof? How long do you wait before you call not getting a response 'dropping'?
The potential consequences require more than this.
What does that mean? Is there proof? How long do you wait before you call not getting a response 'dropping'?
The potential consequences require more than this.
You would have a point if the exploit were more serious, and looked harder to fix than it does.
As is, this is a phishing type variant that it’s not at all clear gatekeeper was even designed to stop. However, the default behavior described (especially making symlinks to NFS shares without any sort of warning or special graphic when following them in Finder) seems sufficient for forceful language when complaining about it to Apple / giving a disclosure deadline then publishing.
As is, this is a phishing type variant that it’s not at all clear gatekeeper was even designed to stop. However, the default behavior described (especially making symlinks to NFS shares without any sort of warning or special graphic when following them in Finder) seems sufficient for forceful language when complaining about it to Apple / giving a disclosure deadline then publishing.
90 days is very reasonable for something like this.
> Great, so now, potentially, there are lots of people who will lose all of their baby photos, lose money or even their contact with people who are important to them just because of some arbitrary number of days you made up and because you feel slighted by apple.
For all we know this has already been happening since the gatekeeper was implemented in 2012.
> Great, so now, potentially, there are lots of people who will lose all of their baby photos, lose money or even their contact with people who are important to them just because of some arbitrary number of days you made up and because you feel slighted by apple.
For all we know this has already been happening since the gatekeeper was implemented in 2012.
And now all the 'hackers' who weren't smart/lucky enough to figure this out also know how to exploit this.
Well, the choices were:
A. Leave the hole open for all crackers who already figured it out, thereby leaving a security hole open for possibly all time. Apple apparently weren’t fixing it; they first said they were going to, but then didn’t do it, and then ceased all communication.
B. Tell the world, thereby forcing Apple to fix the issue. This leaves all Apple users vulnerable to more people than choice A, but only, one would assume, for a limited time.
The ideal situation would of course have been C: Apple promptly (or at least within 90 days) fixes the issue upon being informed of it, before the world at large was made aware of it. But Apple chose not to pick this option. Only option A and B remained.
A. Leave the hole open for all crackers who already figured it out, thereby leaving a security hole open for possibly all time. Apple apparently weren’t fixing it; they first said they were going to, but then didn’t do it, and then ceased all communication.
B. Tell the world, thereby forcing Apple to fix the issue. This leaves all Apple users vulnerable to more people than choice A, but only, one would assume, for a limited time.
The ideal situation would of course have been C: Apple promptly (or at least within 90 days) fixes the issue upon being informed of it, before the world at large was made aware of it. But Apple chose not to pick this option. Only option A and B remained.
There are plenty of fruitful conversations to be had WRT the concept of responsible disclosure, but a fundamental pillar is that vendors are held to some deadline so that they cannot hem and haw indefinitely while leaving their users vulnerable. It's certainly a valid argument to posit that 90 days may be too short of a deadline, but a valid counterargument is that if a company like Apple cannot ship a security patch within 90 days, then their process itself is broken.
Nit to pick. Prefer the term coordinated disclosure. Responsible disclosure puts things on an unnecessary moral dimension. It’s not irresponsible to disclose bugs ever, IMO. I have seen this debate a million times now, but I know it is new for someone.
Notice that Intel used the term "coordinated disclosure" for last week's new raft of microarchitecture bugs; "responsible disclosure" is on the way out for exactly the reason you stated.
That is neat, I actually didn’t even notice and I read the thing. Seems like progress on this topic to me.
Thanks for the tip, I didn't know there existed a better term for this. Indeed, I always felt that "responsible" was a loaded adjective in that context.
> some arbitrary number of days you made up
As a separate datapoint, Google's Project Zero has a default 90 day public disclosure period too.
Generally, it's highly likely that the (really) bad guys already know about the exploit. Leaving the exploit known only to them and the vendor doesn't help the most vulnerable (ie, those targeted by the (really) bad guys)
~3 months is also a reasonable amount of time for coding, review, testing, QA, etc. I don't know if the author was up front about the 90 day deadline with Apple, and if not, that's not particularly friendly, but it's not out of line with other major players in the space.
As a separate datapoint, Google's Project Zero has a default 90 day public disclosure period too.
Generally, it's highly likely that the (really) bad guys already know about the exploit. Leaving the exploit known only to them and the vendor doesn't help the most vulnerable (ie, those targeted by the (really) bad guys)
~3 months is also a reasonable amount of time for coding, review, testing, QA, etc. I don't know if the author was up front about the 90 day deadline with Apple, and if not, that's not particularly friendly, but it's not out of line with other major players in the space.
not only that but i've seen security people extend 90 days when the vendor asks.
Based on the information supplied, the vendor didn't ask.
As an Apple user, the only part about this situation that is disappointing is Apple.
Depressingly, there still isn't an overall competitor that can deliver products that meet my requirements as well as Apple can, so I remain stuck.
As an Apple user, the only part about this situation that is disappointing is Apple.
Depressingly, there still isn't an overall competitor that can deliver products that meet my requirements as well as Apple can, so I remain stuck.
Is that truly legit? It’s very similar to having web servers accept URL paths containing full paths or “../“, both of which have been the cause of many security vulnerabilities.