Google’s Project Zero reveals a “High severity” copy-on-write security flaw found in macOS kernel

A Security researcher from Google’s Project Zero team recently revealed a high severity flaw in the macOS kernel that allows a copy-on-write (COW) behavior, a resource-management technique, also referred to as shadowing.

The researcher informed Apple about the flaw back in November 2018, but the company is yet to fix it even after exceeding the 90-day deadline. This is the reason why the bug is now being made public with a "high severity" label.

According to a post on Monorail, the issue tracking tool is for chromium-related projects, “The copy-on-write behavior works not only with anonymous memory but also with file mappings. This means that, after the destination process has started reading from the transferred memory area, memory pressure can cause the pages holding the transferred memory to be evicted from the page cache. Later, when the evicted pages are needed again, they can be reloaded from the backing filesystem.”

“This means that if an attacker can mutate an on-disk file without informing the virtual management subsystem, this is a security bug. MacOS permits normal users to mount filesystem images. When a mounted filesystem image is mutated directly (e.g. by calling pwrite() on the filesystem image), this information is not propagated into the mounted filesystem”, the post further reads.

According to a Google project member, “We've been in contact with Apple regarding this issue, and at this point no fix is available. Apple is 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 user commented on HackerNews, “Given the requirements that a secondary process should even be able to modify a file that is already open, I guess the expected behavior is that the 1st process's version should remain cached in memory while allowing the on-disk (CoW) version to be updated? While also informing the 1st process of the update and allowing the 1st process to reload/reopen the file if it chooses to do so. If this is the intended/expected behavior, then it follows that pwrite() and other syscalls should inform the kernel and cause prevent the origional cache from being flushed.”

To know more about this news, head over to the bug issue post.

Drupal releases security advisory for ‘serious’ Remote Code Execution vulnerability

Google’s home security system, Nest Secure’s had a hidden microphone; Google says it was an “error”

Firedome’s ‘Endpoint Protection’ solution for improved IoT security

Google’s Project Zero reveals a “High severity” copy-on-write security flaw found in macOS kernel

Recommendations for you

Comments (0)

No comments for this article yet!