Decades-old file security flaws found in Android, Linux, macOS, and Windows

Security researchers affiliated with Austria's Graz University of Technology have found flaws in the implementation of file notification systems on Android, Linux, macOS, and Windows that leak potentially compromising system information. "We found decades-old bugs on [these operating systems], all rooted in the file-notification …

[Sproggit]

A Question on Mitigation...

Reading the article the element of the vulnerability that stood out to me is the fact that it is possible to set up a file system watcher on content even when the account making the API call has no rights to the files or folders it is requesting within the scope of it's watch list.

I'm probably not using the correct terminology, but this strikes me as a basic ACL check failure - because the API is returning information about an object [file system objects] to a user who has, in effect, zero rights on the objects concerned.

Which leads me to a question: does this mean that for *general purpose* files, the threat could be mitigated if the API respected Access Control - i.e. the user/group/world permission set for files?

I suspect that this would not work for e.g. the /dev file system - which is mapping directly to hardware and which is potentially the greater threat - but at a hunch I'd suspect that anything done to wrap access control around file system structures in locations like /dev might risk breaking a whole bunch of stuff...

Interesting to know if anyone is publishing recommended mitigating controls for this one...

[TJ1]

Re: A Question on Mitigation...

I think whoever wrote that doesn't understand basic Linux file-system semantics.

"adding an inotify watch on the file results in a permission-denied error. However, if the user can read /dev/input – i.e., they can list the files in the directory – then an inotify watch on the directory succeeds, and the user receives notifications for all files inside it, as shown below:"

They seem to imply this is by-passing the file permission, but of course it is not, since the watch is reporting actions on the dirents (directory entry structures), not on the file inodes. That doesn't negate the fact that it is revealing the events on the child - but that is intended.

fs/notify/fsnotify.c::__fsnotify_parent() notifies the parent of a dirent of child events.

The main problem there is, I think with udev's setting mode o+rx (Others, read + traverse) on /dev/input/ - it likely should only be +x (traverse). /dev/input/event* file nodes have ownership root:input (User:Group) with mode ug=rw,o=--- (User and Group have read and write, Other has no access) so a process that cannot read/write a node has no need to list the parent directory.

Best solution there - aside from changing the mode to o=x - is to not enable CONFIG_INOTIFY_USER or use secomp to filter access to the inotify IOCTL interface. However, some tools (such as virus scanners) may use that or more likely require CONFIG_FANOTIFY and possibly CONFIG_FANOTIFY_ACCESS_PERMISSIONS.

Also, their Android description is slightly disingenuous; they say "Every app is assigned a private folder at /sdcard/Android/, hidden from other apps through Android’s FUSE layer," but they do not spell out that those are NOT and never have been PRIVATE folders in terms of directory ownership, permissions or SELinux: the /sdcard/ mounts have always been root:everybody ever since the original /sdcard/ was a removable micro SD-card with FAT file system (which has no concept of ownership/mode permissions).

[Sproggit]

Re: A Question on Mitigation...

Thank you - that made a lot more sense!

[T. F. M. Reader]

What in a teapot?

Let's say I have a readable directory and unreadable files in it. I don't need inotify to list the files in the directory, including access time, modification time, etc. I can watch for changes, too. This has always been the case in UNIX/Linux by design.

There may be specific inter-keystoke-timing attacks related to special files like /dev/input, and TFA says that was fixed in the kernel last year.

Inotify and its sister fanotify are actually fairly common components of EDR security products. Of course, EDR typically runs with root permissions, so the whole "leakage" question becomes moot. The BUGS section of the fanotify(7) man page actually says, "When an event is generated, no check is made to see whether the user ID of the receiving process has authorization to read or write the file before passing a file descriptor for that file. This poses a security risk, when the CAP_SYS_ADMIN capability is set for programs executed by unprivileged users." Well, that's a rather wide set of additional capabilities - and?

Shrug.

[Jou (Mxyzptlk)]

"ReadDirectoryChangesW" hellofa unreliable...

I would not call this a security issue. The directory AND file change notifications are so notoriously unreliable, when trying to make use of them in an application, that Microsoft could say "we already secured it, too unreliable to be useful".

[Zaphodikus]

Re: "ReadDirectoryChangesW" hellofa unreliable...

We have had the same experience, it is unreliable. I think, the gist is (from Windows experience) that this api removes the need to poll the filesystem that you have already got "enumerate files" access to. The vulnerability is thus that it makes it easier to detect where a user "most often" goes. Reducing the effort to scan for activity makes it easier to snoop, is the vulnerability, which is merely part of the Swiss Cheese layering model, .. so it's not a way to gain control, modify or egress data that the attacker did not have access to, other than general traffic metadata only?

[Anonymous Coward]

Just this one?

... response was nominated for the lamest vendor response at the Pwnie Awards 2026."

Wait ...

Just this one?

Aren't all of Microsoft's responses to this sort of incidents just as lame?

.

[DS999]

Is this really a flaw

On Android/Linux/macOS you have the stat() call available, which is what was used before inotify() type stuff became available. You can check if a file or directory has been read or modified, but you have to do multiple stat() calls and compare the results. But the same information is available, it is just a little less convenient to obtain.

So if these are concerning then what about the fact that you can do the same thing with a system call that has been in Unix since day one or nearly so? For a file stat() does not require any permissions for the named file, you only need to be able to access the directory path leading to it. Don't even need to write a program, to find out if a file has been read "ls -lu filename" then do that command again and see if the access time has changed.

[Anonymous Coward]

Certainly not a problem on windows

There's so many things fecking with the filesystem in the background.

[Tron]

Risk/Reward.

If fixing something exotic or something that requires a high level of access to work, breaks too much else, then it is better left as it is.

Burglars will not use a six grand laser cutter to break into your home, even though they theoretically could, so you don't need to have glass that is laser cutter proof. There are too many easier ways of doing it.

Making systems that lack resilience through being complex, more complex, to cover endless exotic bugs, is counter-productive. And publicising them for academic purposes, also doesn't help. We have enough problems with AI-supported hackers, without this.

That said, we do need a new OS that removes many of these issues through intrinsic design/architecture/hardware choices. Things are easier in hindsight, and we now have a fair few decades of hindsight stored up, for a new OS project.

[Groo The Wanderer - A Canuck]

That is some seriously creative abuse of a notification system, but that kind of side-channel issue has been with the world as long as MQ-Series type services have.

[Anonymous Coward]

"On Windows, we propose disallowing the monitoring of entire drives"

But that wouldn't stop an application from monitoring all the top-level directories in that drive individually.

[JimmyPage]

Is this the future now ?

People discover something that was always meant to work that way and catastrophize it into a headline ?

The real story here - which won't be reported (even in the new style Vulture) is that this sort of thing is exactly what happens when you tell the experts to fuck off and pretend "AI" can replace them.

[pc-fluesterer.info]

Evil Maid issue

All of this fuss is about a theoretical weakness the exploitation of which is complicated and unreliable AND possible only for insiders (local or ssh). So what?