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

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.

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday — and get free copies of Paul Thurrott's Windows 11 and Windows 10 Field Guides (normally $9.99) as a special welcome gift!

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

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

Share post

Please check our Community Guidelines before commenting

Conversation 17 comments

  • RonH

    Premium Member
    04 March, 2019 - 2:39 pm

    <p>I have never understood how Google gets away with putting people at risk like this..</p><p>This post is also interesting…https://www.thurrott.com/mobile/android/201391/an-android-tv-bug-is-exposing-your-photos-to-strangers </p>

  • lvthunder

    Premium Member
    04 March, 2019 - 4:16 pm

    <p>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.</p>

    • sandy

      04 March, 2019 - 7:54 pm

      <blockquote><em><a href="#408953">In reply to lvthunder:</a></em></blockquote><p>My only issue with Google is their hypocracy in not fixing their own bugs within 90 days.</p><p>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.</p>

      • jimchamplin

        Premium Member
        05 March, 2019 - 1:00 am

        <blockquote><em><a href="#408981">In reply to Sandy:</a></em></blockquote><p>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.</p><p><br></p><p><em>Oh wait it will.</em></p>

      • lvthunder

        Premium Member
        05 March, 2019 - 10:34 am

        <blockquote><em><a href="#408981">In reply to Sandy:</a></em></blockquote><p>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. </p><p><br></p><p>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.</p>

      • OwenM

        Premium Member
        05 March, 2019 - 4:50 pm

        <blockquote><em><a href="#408981">In reply to Sandy:</a></em></blockquote><p><br></p><p>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. </p>

  • ivarh

    Premium Member
    04 March, 2019 - 5:44 pm

    <p>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.&nbsp;</p><p><br></p><p>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.&nbsp;</p><p><br></p><p>This is a bug, but I have problems seeing how it would be used to breach a system successfully.</p>

  • harrymyhre

    Premium Member
    04 March, 2019 - 10:12 pm

    <p>What happened to “DONT BE EVIL” ?</p>

  • red.radar

    Premium Member
    04 March, 2019 - 11:35 pm

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

  • dontbe evil

    04 March, 2019 - 11:56 pm

    <p>LOL … a big hug to apple fans that keep think "mac os is the most secure OS evaaaaaaaaaaaaa"</p>

  • wright_is

    Premium Member
    05 March, 2019 - 1:06 am

    <p>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.</p><p>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.</p><p>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.</p><p>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.</p><p>That said, I would need to go back over the code in more detail to see if my initial understanding is correct.</p>

    • ivarh

      Premium Member
      05 March, 2019 - 5:53 pm

      <blockquote><em><a href="#409039">In reply to wright_is:</a></em></blockquote><p>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.&nbsp;I suspect the reason they use FAT to demonstrate is that the developer know FAT and how to modify it on disk.</p><p><br></p><p>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.&nbsp;</p>

      • wright_is

        Premium Member
        06 March, 2019 - 12:23 am

        <blockquote><em><a href="#409296">In reply to ivarh:</a></em></blockquote><p>More or less what I said, with the exception that:</p><p>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.</p><p>What the actual attack is doing is bypassing all Kernel controls on writing and logging.</p>

  • Jack Smith

    05 March, 2019 - 5:51 am

    <p>Good on Google helping Apple. Saw this last weekend Microsoft is using Google Reptoline to help make Windows more secure without hurting performance.</p><p><br></p><p>Love seeing Google put helping others with security issues over competition. Security should rise above competition. Hopefully Google lead will be followed by others.</p>

    • locust infested orchard inc

      05 March, 2019 - 7:57 am

      <blockquote><em><a href="#409069">In reply to Jack_Smith:</a></em></blockquote><p><br></p><p>You make it sound as if Google is the Superman of bug-busting within code.</p><p><br></p><p>Google's Project Zero clearly has ulterior motives as it attempts to position itself as the only company whose devices and services ought to be used by all.</p>

    • lvthunder

      Premium Member
      05 March, 2019 - 10:35 am

      <blockquote><em><a href="#409069">In reply to Jack_Smith:</a></em></blockquote><p>How is telling the bad guys how to compromise competitors system helping anyone but Google?</p>

    • Chris Payne

      05 March, 2019 - 12:56 pm

      <blockquote><em><a href="#409069">In reply to Jack_Smith:</a></em></blockquote><p>Finding the problem and reporting to Apple is one thing. Irresponsibly disclosing it to the public because Apple couldn't meet your ridiculous made-up-out-of-nowhere-deadline is another, evil, bad thing.</p>

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

Thurrott © 2024 Thurrott LLC