Gefs is a new file system built for Plan 9. It aims to be a crash-safe, corruption-detecting, simple, and fast snapshotting file system, in that order. Gefs achieves these goals by building a traditional 9p file system interface on top of a forest of copy-on-write Bε trees. It doesn’t try to be optimal on all axes, but good enough for daily use.

source: L

Operating systems and file systems have traditionally been developed hand in hand. They impose mutual constraints on each other. Today we have two major leaders in file system semantics: Windows and POSIX. They are very close to each other when compared to the full set of possibilities. Interesting things happened before POSIX monopolized file system semantics.

source: L

Sometimes, you will hear the view that Unix’s design is without significant issues, especially the ‘pure’ design of Research Unix (before people who didn’t really understand Unix like Berkeley and corporate AT&T got their hands on it). Unfortunately that is not the case, and there are some areas where Research Unix made decisions that still haunt us to this day. For reasons beyond the scope of this entry, today’s example is that part of the file attributes that you get from stat() system call and its friends is the ‘device number’ of the filesystem the file is on.

I think it’s a bit exaggerated to say this is an issue that haunts us. More like a historical note.

What we have here is a case of creating an insecure system and then being surprised that the system is insecure.

This is all too common, but the fix is equally shortsighted. Always too much focus on narrow aspect of the problem.

They claimed that the issue could be fixed by simply adding the ampersand to the list of illegal file name characters. They forgot about the percent sign (for injecting environment variables), the caret (for escaping), and possibly even the apostrophe.

Mark Zbikowski led the MS-DOS 2.0 project, and he sat down with a stopwatch while Aaron Reynolds and Chris Peters tried to swap floppy disks on an IBM PC as fast as they could.

They couldn’t do it under two seconds.

A followup: https://devblogs.microsoft.com/oldnewthing/20191001-00/?p=102946

One simple answer is that the Unix API provides no way to report delayed errors for file and directory operations. If you write() data, it is an accepted part of the Unix API that errors stemming from that write may not be reported until much later, such as when you close() the file. This includes not just ‘IO error’ type errors, but also problems such as ‘out of space’ or ‘disk quota exceeded’; they may only appear and become definite when the system forces the data to be written out. However, there’s no equivalent of close() for things like removing files or renaming them, or making directories; the Unix API assumes that these either succeed or fail on the spot.

Let’s talk about files! Most developers seem to think that files are easy.

In this talk, we’re going to look at how file systems differ from each other and other issues we might encounter when writing to files. We’re going to look at the file “stack”, starting at the top with the file API, moving down to the filesystem, and then moving down to disk.

source: danluu

The documentation for wofapi.h says merely “This header is used by Data Access and Storage.” For more information, it refers you to another web page that contains no additional information. WOF stands for Windows Overlay Filter, which is a nice name that doesn’t really tell you much about what it does or what it’s for.

Changing the native NTFS file compression would be a disk format breaking change, which is not something taken lightly. Doing it as a filter provides much more flexibility. The downside is that if you mount the volume on a system that doesn’t support the Windows Overlay Filter, all you see is an empty file. Fortunately, WOF is used only for system-installed files, and if you are mounting the volume onto another system, it’s probably for data recovery purposes, so you’re interested in user data, not system files.

The question I’m going to answer in this post is not why 4 bits are used, but why they’re used the way they are. If you have a look at the standard file types, their values seem pretty arbitrary, when you might expect a simple count upwards.

source: L

The basic code design comes from FreeBSD, but the code is written from scratch. It was just easier to write from scratch than trying to port sys/fs/fuse/* in FreeBSD for various reasons. Note that this is to implement FUSE API/ABI, but not to be compatible with FreeBSD implementation which contains FreeBSD specific sysctls, etc.

source: Dfly

Fix time overflow issues in the original 32-bit UFS code in two ways. First, treat the original 32-bit seconds fields as unsigned.Second, utilize the spare fields to expand these fields to 48 bits each. Retain the nanosecond-grain accuracy of the nsec fields.

source: Dfly

This syscall would only performs additional sanitary checks if we are removing a directory entry which corresponds to the inode stored which refers to the file descriptor.

source: L

Many scp clients fail to verify if the objects returned by the scp server match those it asked for. This issue dates back to 1983 and rcp, on which scp is based. A separate flaw in the client allows the target directory attributes to be changed arbitrarily. Finally, two vulnerabilities in clients may allow server to spoof the client output.

Be careful what you believe.

source: grugq

This shift means that there will be little to no net new development of Illumos. While working through the git history of ZoL I have also discovered that many races and locking bugs have been fixed in ZoL and never made it back to Illumos and thus FreeBSD. This state of affairs has led to a general agreement among the stakeholders that I have spoken to that it makes sense to rebase FreeBSD’s ZFS on ZoL.

Also some background: https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072430.html

source: L

Only two weeks for an NFS bug?

source: L

If a handle is provided to a directory, it should imply access to resources within that directory (and additionally, their subdirectories). Unfortunately, however, a holdout from POSIX prevents directory handles from cleanly integrating with these concepts in a capability system: “..”. If a handle is provided to a directory, the client can simply request “..”, and the handle will be “upgraded” to access the parent directory, with broader scope. As a consequence, this implies that a handle to a directory can be upgraded arbitrarily to access the entire filesystem.

source: HN

I spent a couple of years evangelizing about Capsicum. I wrote many articles about it. So, it is very natural that I would also like to update you on this blog about the progress of the Capsicum project in FreeBSD, because this is what I’m doing in my free time. That said I feel that this blog wouldn’t be completed without some introduction to what Capsicum is. This post should fill this gap. Over the next weeks and months we will extend this topic and discuss different parts of Capsicum.

source: Dfly

The October 2018 Update tried to tidy up this situation. When KFR is being used, the October 2018 Update will delete the original, default Known Folder locations. Microsoft imagined that this would simply remove some empty, redundant directories from your user profile. No need to have a Documents directory in your profile if you’re using a redirected location, after all. The problem is, it neither checked to see if those directories were empty first, nor copied any files to the new redirected location. It just wiped out the old directory, along with anything stored within it. Hence the data loss.

Maybe just leave tidying to the user.

Recently, there has been some attention around the topic of physical attacks on smartphones, where an attacker with the ability to connect USB devices to a locked phone attempts to gain access to the data stored on the device. This blogpost describes how such an attack could have been performed against Android devices (tested with a Pixel 2).

Interesting exploit chain and pivot. Lots of little bugs here, there, everywhere.

As an attacker, it normally shouldn’t be possible to mount an ext4 filesystem this way because phones aren’t usually set up with any such keys; and even if there is such a key, you’d still have to know what the correct partition GUID is and what the key is. However, we can mount a vfat filesystem over /data/misc and put our own key there, for our own GUID. Then, while the first malicious USB mass storage device is still connected, we can connect a second one that is mounted as PrivateVolume using the keys vold will read from the first USB mass storage device.

Notably, this attack crosses two weakly-enforced security boundaries: The boundary from blkid_untrusted to vold (when vold uses the UUID provided by blkid_untrusted in a pathname without checking that it resembles a valid UUID) and the boundary from the zygote to the TCB (by abusing the zygote’s CAP_SYS_ADMIN capability). Software vendors have, very rightly, been stressing for quite some time that it is important for security researchers to be aware of what is, and what isn’t, a security boundary - but it is also important for vendors to decide where they want to have security boundaries and then rigorously enforce those boundaries. Unenforced security boundaries can be of limited use - for example, as a development aid while stronger isolation is in development -, but they can also have negative effects by obfuscating how important a component is for the security of the overall system.

Given a MITM apk repo.

Persistent arbitrary file writes can be easily turned into code execution because of apk’s “commit hooks” feature. If we can figure out a way to extract a file into /etc/apk/commit_hooks.d/ and have it stay there after the cleanup process, it will be executed before apk exits.

Transactions are hard.

source: HN