vDSO, 32-bit time, and seccomp
> The seccomp() mechanism is notoriously difficult to use. It also turns out to be easy to break unintentionally, as the development community discovered when a timekeeping change meant to address the year-2038 problem created a regression for seccomp() users in the 5.3 kernel. Work is underway to mitigate the problem for now, but seccomp() users on 32-bit systems are likely to have to change their configurations at some point.
The problems inherent in exposing very low level interfaces in one place (seccomp) and high level interfaces in another (libc).
Killing a process and all of its descendants
> Unix-like operating systems have sophisticated process relationships. Parent-child, process groups, sessions, and session leaders. However, the details are not uniform across operating systems like Linux and macOS. POSIX compliant operating systems support sending signals to process groups with a negative PID number.
I think some of this is not entirely correct, but as noted, it’s a complicated subject.
shebangs and busybox
> neat, right? this lets us write shell scripts that are portable across all sorts of different setups. except there’s a problem.
Extending the Kernel with Built-in Kernel Headers
> Kernel headers are usually unavailable on the target where these BPF tracing programs need to be dynamically compiled and run. That is certainly the case with Android, which runs on billions of devices. It is not practical to ship custom kernel headers for every device. My solution to the problem is to embed the kernel headers within the kernel image itself and make it available through the sysfs virtual filesystem (usually mounted at /sys) as a compressed archive file (/sys/kernel/kheaders.tar.xz). This archive can be uncompressed as needed to a temporary directory. This simple change guarantees that the headers are always shipped with the running kernel.
I feel this is the wrong solution, but interesting nevertheless.
security things in Linux v5.2
> page allocator freelist randomization
And some other things as well.
OpenSSH Taking Minutes To Become Available, Booting Takes Half An Hour ... Because Your Server Waits For A Few Bytes Of Randomness
> Basically as of now the entropy file saved as /var/lib/systemd/random-seed will not - drumroll - add entropy to the random pool when played back during boot. Actually it will. It will just not be accounted for. So Linux doesn’t know. And continues blocking getrandom(). This is obviously different from SysVinit times2 when /var/lib/urandom/random-seed (that you still have lying around on updated systems) made sure the system carried enough entropy over reboot to continue working right after enough of the system was booted.
And then... it just kinda keeps getting worse. The problem is understandable, the inability to resolve it less so.
> 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.
Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service issues
> Netflix has identified several TCP networking vulnerabilities in FreeBSD and Linux kernels. The vulnerabilities specifically relate to the minimum segment size (MSS) and TCP Selective Acknowledgement (SACK) capabilities. The most serious, dubbed “SACK Panic,” allows a remotely-triggered kernel panic on recent Linux kernels.
security things in Linux v5.1
> Linux kernel v5.1 has been released! Here are some security-related things that stood out to me:
Alpine Linux Docker Image root User Hard-Coded Credential Vulnerability
> Versions of the Official Alpine Linux Docker images (since v3.3) contain a NULL password for the root user. This vulnerability appears to be the result of a regression introduced in December t2015. Due to the nature of this issue, systems deployed using affected versions of the Alpine Linux container that utilize Linux PAM, or some other mechanism that uses the system shadow file as an authentication database, may accept a NULL password for the root user.
NULL as in empty. Note the timeline.
> This vulnerability was originally reported and patched in 2015, regression tests were added to prevent this from occurring in the future.
> Unfortunately, later that same year, a commit was pushed to simplify the regression tests. This lead to logic that may have caught this regression being simplified, causing these tests to be incorrectly ‘satisfied’ if the root password was once again removed.
> Eight days after this vulnerability was initially fixed, a commit was pushed which removed this ‘disable root by default’ flag from the ‘edge’ build properties file, reintroducing this issue to subsequent builds.
An overview of Secure Boot in Debian
> This blog post isn’t meant to be a definitive guide about Secure Boot in Debian. The idea is to give some context about the boot sequence on the PC architecture, about the Secure Boot technology, and about some implementation details in Debian.
Nevertheless, pretty complicated.
Slim: OS kernel support for a low-overhead container overlay network
> In theory there are four possible modes for container networking: a bridge mode for containers on the same host; host mode in which containers use the IP address of their host network interface; macvlan mode (or similar hardware mechanisms) to give each container its own IP address; and overlay mode in which each container is given its own own virtual network interface and each application has its own network namespace.
Too many cores
> Why would the new servers be worse, but only for Raspbian?
> Common wisdom says ARM architecture versions add new instructions, but can still run code for older versions. This is, broadly, true. However, there are a few cases where deprecated instructions become missing instructions, and continuity demands those instructions be caught by the kernel, and emulated.
Linux: virtual address 0 is mappable via privileged write() to /proc/*/mem
> This can be abused on systems without SMAP to make NULL pointer
dereferences exploitable again.
Breaking out of Docker via runC – Explaining CVE-2019-5736
> This post aims to be a comprehensive technical deep dive into the vulnerability and it’s various exploitation methods.
Too much stuff in the container and some of it leaks out.
GNOME Usability Study Report
> Sun’s GNOME usability staff in Menlo Park, California, conducted a baseline usability study of the GNOME desktop during the week of March 13-16, 2001. We recruited a dozen adult participants, each with several years of experience using computers in their work - but specifically not with backgrounds in computer science, software development or programming - to use GNOME 1.2.2 on Linux with Nautilus installed.
Kinda old, but still relevant in many ways.
Privilege Escalation in Ubuntu Linux (dirty_sock exploit)
> In January 2019, I discovered a privilege escalation vulnerability in default installations of Ubuntu Linux. This was due to a bug in the snapd API, a default service. Any local user could exploit this vulnerability to obtain immediate root access to the system.
This is somewhere between amazing and just dumb.
> This is calling one of golang’s standard libraries to gather user information related to the socket connection. Basically, the AF_UNIX socket family has an option to enable receiving of the credentials of the sending process in ancillary data (see man unix from the Linux command line). This is a fairly rock solid way of determining the permissions of the process accessing the API.
> Instead, some additional processing happens in this function, where connection info is added to a new object along with the values discovered above: …and then a bit more in this one, where all of these values are concatenated into a single string variable: ..and is finally parsed by this function, where that combined string is broken up again into individual parts:
Yes. Take the input you trust, concatenate with untrusted input, then parse it again.
A proposed API for full-memory encryption
> Hardware memory encryption is, or will soon be, available on multiple generic CPUs. In its absence, data is stored — and passes between the memory chips and the processor — in the clear. Attackers may be able to access it by using hardware probes or by directly accessing the chips, which is especially problematic with persistent memory. One new memory-encryption offering is Intel’s Multi-Key Total Memory Encryption (MKTME) [PDF]; AMD’s equivalent is called Secure Encrypted Virtualization (SEV). The implementation of support for this feature is in progress for the Linux kernel. Recently, Alison Schofield proposed a user-space API for MKTME, provoking a long discussion on how memory encryption should be exposed to the user, if at all.
Wine 4.0 Released
> This release represents a year of development effort and over 6,000 individual changes. It contains a large number of improvements that are listed in the release notes below. The main highlights are:
> Vulkan support.
> Direct3D 12 support.
> Game controllers support.
> High-DPI support on Android.
How to write a rootkit without really trying
> We open-sourced a fault injection tool, KRF, that uses kernel-space syscall interception. You can use it today to find faulty assumptions (and resultant bugs) in your programs. Check it out!
> This post covers intercepting system calls from within the Linux kernel, via a plain old kernel module. We’ll go through a quick refresher on syscalls and why we might want to intercept them and then demonstrate a bare-bones module that intercepts the read(2) syscall.