Google Reveals ‘High Severity’ Flaw in macOS After Apple Fails to Patch

Posted on March 4, 2019 by Mehedi Hassan in Apple, Google, Mac and macOS with 17 Comments

Google’s Project Zero team has apparently disclosed a serious flaw in the macOS kernel. Google’s security engineers first discovered the flaw back in November of last year, reporting it to Apple. And after Cupertino failed to patch the issue within 90 days, the company has now made the flaw public.

A bug in macOS’ XNU kernel allows attackers to make changes to a mounted filesystem without the user or the filesystem actually being aware of the changes, reports Neowin. Google has provided a technical explanation behind the flaw — but in essence, the issue originates from the kernel’s copy-on-write behavior that allows the attacker to make changes to the mounted filesystem without the virtual management subsystem being notified.

Although Google has marked the issue as high-severity, the company still disclosed the flaw publicly after Apple failed to provide a fix in time. “We’ve been in contact with Apple regarding this issue, and at this point no fix is available. Apple are intending to resolve this issue in a future release, and we’re working together to assess the options for a patch. We’ll update this issue tracker entry once we have more details,” a Google engineer said.

This isn’t the first time the company has disclosed a serious bug publicly, and there’s been a lot of other controversies over the years about similar incidents.

It’s still unclear exactly how the flaw could impact end-users, and it seems like you would need deep access to the macOS kernel to actually exploit the bug. I could be wrong, however. If you think you may be impacted by the problem, I suggest looking at the technical explanation behind the flaw.

Tagged with , , ,

Join the discussion!


Don't have a login but want to join the conversation? Become a Thurrott Premium or Basic User to participate

Comments (17)

17 responses to “Google Reveals ‘High Severity’ Flaw in macOS After Apple Fails to Patch”

  1. RonH

    I have never understood how Google gets away with putting people at risk like this..

    This post is also interesting...

  2. dontbe evil

    LOL ... a big hug to apple fans that keep think "mac os is the most secure OS evaaaaaaaaaaaaa"

  3. Jack Smith

    Good on Google helping Apple. Saw this last weekend Microsoft is using Google Reptoline to help make Windows more secure without hurting performance.

    Love seeing Google put helping others with security issues over competition. Security should rise above competition. Hopefully Google lead will be followed by others.

  4. wright_is

    It only seems to affect mounted FAT images, not macOS native formatted drives and images. At least the sample code provided assumes a FAT mounted image file.

    Given that FAT doesn't have any form of security, it is not surprising that you can write to it. The significant part is, you can bypass the OS reporting to do so, by a quick look at the code.

    You could, for example, find an installer image file, manipulate it and slip in some malware, which would then be installed when the image is mounted and the software installed.

    Bur you would need local access to the PC or you would need a secondary remote execution vulnerability to slip in the code that could slip in the malware. If you can do remote code execution, it is questionable, how helpful this would be, but you could, for example, infect a central image respository of a company.

    That said, I would need to go back over the code in more detail to see if my initial understanding is correct.

    • ivarh

      In reply to wright_is:

      This does not look like a filesystem problem to me. It is a problem that MacOS allows writes to a file that is mapped to a block device (and mounted) thus allowing the content of the block device being changed bypassing any security features in a filesystem on the block device. I suspect the fix is rather simple in that the kernel should place an exclusive write lock on the file when it's mapped to a block device. That would solve the problem completely without almost no modifications to the kernel code. I suspect the reason they use FAT to demonstrate is that the developer know FAT and how to modify it on disk.

      In fact, I am not sure I see any problem here. If you write to the file that is mapped to a block device it would be the same as writing directly to a disk via its device name and would have the same effect in that it would change the content of the device causing the changed to bleed into the filesystem on that device. This has always been so on any Unix I have worked with. 

      • wright_is

        In reply to ivarh:

        More or less what I said, with the exception that:

        Because it is FAT, there is no notion of security on the drive itself, it doesn't have read and write privileges - at most you can set individual files to read-only. This makes the FAT images an obvious target for this attack, as they only need to bypass one part of the OS.

        What the actual attack is doing is bypassing all Kernel controls on writing and logging.

  5. red.radar

    I am surprised this practice hasn't been tested in court for the liabilities it causes.

  6. lvthunder

    I would like to thank Google for putting Mac uses at a higher risk and helping the bad guys. This also means Apple has to now rush to get a patch out and we all knows what happens when you rush and don't test things thoroughly. What a bunch of arrogant jerks these Google people are.

    • sandy

      In reply to lvthunder:

      My only issue with Google is their hypocracy in not fixing their own bugs within 90 days.

      Apple has had 90 days, but chose not to fix this problem within that timeframe. The fault for putting users at risk lies with Apple; they are responsible for their buggy software.

      • OwenM

        In reply to Sandy:

        Are you an expert in fixing this sort of thing? Not every flaw can be be fixed and tested within 90 days. Google publicly disclosing flaws in this way helps nobody and serves only to harm competitors and those using their platforms.

      • lvthunder

        In reply to Sandy:

        So you are 100% sure that every bug (or even this bug) can be properly fixed and tested within 90 days. You know some arbitrary number Google came up with to give the companies to fix problems.

        Google is the one telling the hackers what to do to exploit the bug. They didn't have to post proof of concept code. That only helps two groups of people. The people trying to fix the bug and the people trying to exploit the bug. I'm assuming Google shared this proof of concept when they originally reported the bug to Apple. So the only people who are gaining anything are the bad guys.

      • jimchamplin

        In reply to Sandy:

        Yes, because issues with filesystems should be rushed ASAP because that won't lead to data loss. It's not like making changes to APFS won't affect a billion devices or something.

        Oh wait it will.

  7. harrymyhre

    What happened to “DONT BE EVIL” ?

  8. ivarh

    When you read the actual bug description, you will see that this only happens on user mounted disk image files. These are mounted with the following mount flags: (hfs, local, nodev, nosuid, read-only, noowners, quarantine, mounted by ivar). These flags mean that device files in the filesystem will be ignored, Flags that would escalate privilege are ignored among others. It does not seem that this problem affects actual disk mounted filesystems. Also, they had to put the system under memory pressure for this to take effect. 

    Calling this a "serious flaw" really makes me wonder what they would classify the facetime bug as... The only time regular users mount a filesystem image (dmg file) is during software installs. Since applications on macos need to be signed by the developer (unless the user has changed the gatekeeper settings) any modifications to an app before it is copied off the image will cause it to fail verification. 

    This is a bug, but I have problems seeing how it would be used to breach a system successfully.

Leave a Reply