News

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

2 min read

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.

Read Next

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

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

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

Savia Lobo

A Data science fanatic. Loves to be updated with the tech happenings around the globe. Loves singing and composing songs. Believes in putting the art in smart.

Share
Published by
Savia Lobo

Recent Posts

Top life hacks for prepping for your IT certification exam

I remember deciding to pursue my first IT certification, the CompTIA A+. I had signed…

3 years ago

Learn Transformers for Natural Language Processing with Denis Rothman

Key takeaways The transformer architecture has proved to be revolutionary in outperforming the classical RNN…

3 years ago

Learning Essential Linux Commands for Navigating the Shell Effectively

Once we learn how to deploy an Ubuntu server, how to manage users, and how…

3 years ago

Clean Coding in Python with Mariano Anaya

Key-takeaways:   Clean code isn’t just a nice thing to have or a luxury in software projects; it's a necessity. If we…

3 years ago

Exploring Forms in Angular – types, benefits and differences   

While developing a web application, or setting dynamic pages and meta tags we need to deal with…

3 years ago

Gain Practical Expertise with the Latest Edition of Software Architecture with C# 9 and .NET 5

Software architecture is one of the most discussed topics in the software industry today, and…

3 years ago