Why file and directory operations are synchronous in NFS
> 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.
What is WofCompressedData?
> 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.
A history of S_IFMT
> 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.
dragonfly - Add initial FUSE support
> 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.
ufs - Expand time_t support to 48 bits
> 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.
> 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.
scp client multiple vulnerabilities
> 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.
The future of ZFS in FreeBSD
> 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
How we spent two weeks hunting an NFS bug in the Linux kernel
Only two weeks for an NFS bug?
Fuchsia - Dot Dot Considered Harmful
> 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.
> 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.
Windows 10 October 2018 Update no longer deletes your data
> 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.
OATmeal on the Universal Cereal Bus: Exploiting Android phones over USB
> 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.
Remote Code Execution in Alpine Linux
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.
Remote Mac Exploitation Via Custom URL Schemes
> Which also means custom URL scheme handlers:
> ■ are registered automatically by macOS as soon as application (that “advertises” support for such handlers) hits the file-system
> ■ will trigger the execution of the (automatically registered) handler application, when the custom url scheme is invoked
Kind of obvious in hindsight, making things too easy leads to runaway.
The early history of Windows file attributes, and why there is a gap between System and Directory
TRIM by default
> The TRIM operation has been in DragonFly for some time, and it looks like most SSDs support it reliably, now – so it’s on by default.
Pledge, and Unveil, in OpenBSD
> Unveiling a directory unveils everything underneath it in the filesystem
A Problematic Place
> This code does some processing on a list of directories. Apparently while coding this, the author found themself in a “problematic place”. We all have our ways of avoiding problematic places, but this programmer decided the best way was to introduce some randomness into the equation. By randomizing the order of the list, they seem to have completely mitigated… well, it’s not entirely clear what they’ve mitigated.
This actually seems like it may be a reasonable fix to a poorly identified problem. Too many processes opening files in the same order? Lock contention?