This status is going to be pretty short. The focus in October has been on the home purchase.

News regarding the home purchase: if things go according to plan, we will take possession of the property towards the end of November 2023 (this month).

In ports:

1. Loic F fixed archivers/rpm4
2. Loic F fixed graphics/sane-backends
3. Shawn Webb fixed lang/perl5.36
4. Shawn Webb updated ports-mgmt/pkg to 1.20.8
5. Shawn Webb "fixed" audio/pulseaudio by ripping out SIMD support. A more proper fix is needed. If the community can help us re-gain SIMD support for this port, that would be very much appreciated.

I worked on hbsdfw a little bit, figured out some of the issues in building the base OS packages. Now I need to figure out why some ports fail to build.

For November, I'm working on a new malloc.conf(5) option: bool nullonzero, default: false. This malloc.conf(5) option will cause malloc(3)-and-friends to return NULL when a zero size is passed in. This would prevent a class of integer overflow vulnerabilities that can lead to buffer overflows.

For example, in the common OpenSolaris CTF code (used in DTrace), we find the following function:

    char *
    xstrndup(char *str, size_t len)
    {
        char *newstr;
        
        /*
         * HardenedBSD note:
         *
         * If len happens to be SIZE_MAX, the size passed to malloc is zero.
         */
        if ((newstr = malloc(len + 1)) == NULL)
            memory_bailout();
    
        /*
         *HardenedBSD note:
         *
         * malloc(0) happily handed us a non-NULL pointer, sized zero. We now
         * copy SIZE_MAX bytes from str to newstr.
         */
        (void) strncpy(newstr, str, len);
        newstr[len] = '\0';
    
        return (newstr);
    }

HardenedBSD would prefer developers get used to providing reasonableness checks regarding size calculations. This xstrndup function could include this defensive coding technique of applying reasonable checks like so:

    char *
    xstrndup(char *str, size_t len)
    {
        char *newstr;
    
        if (str == NULL || len + 1 == 0) {
            return (NULL);
        }
    
        if (len == 0 && str[0] != '\0') {
            return (NULL);
        }
    
        /*
         * If len is still 0, that means we're duplicating an empty string.
         * That's fine, since strdup("") is a thing.
         */
        
        if ((newstr = malloc(len + 1)) == NULL)
            memory_bailout();
    
        (void) strncpy(newstr, str, len);
        newstr[len] = '\0';
    
        return (newstr);
    }

These new reasonable checks ensure that sleepy, caffeine-deprived developers have a harder time making understandable mistakes. We want to encourage safe and defensive programming techniques, especially before we launch this feature. I will fix the issues that come up in the base OS. When it lands, this feature will be defaulted to disabled, but the reasonableness checks and fixes will remain in place regardless.

So that's a preview of what's going on. I hope to land this before the end of the month. Perhaps mid-2024 we'll have it enabled by default.

HardenedBSD 14-STABLE is now officially a thing! Our mirrors are catching up with our inaugural build, and with our build infrastructure limited at 200Mbps, please be considerate with bandwidth use.

Installers: https://installers.hardenedbsd.org/pub/14-stable/
Package builder: https://hbsd-pkg-14-stable-01.hardenedbsd.org/index.html

There was only one notable change in the src repo in July 2023. But first, a little background info:

A long time ago, I started on a project that makes anonymous remote code injection and PLT/GOT redireciton techniques over the ptrace boundary easy in one little consumable API. The end-goal of the tool is to support injection of shared objects in a completely anonymous manner, and to be able to hijack PLT/GOT entries to point to their counterpart in the newly-injected shared object. I started on this work well over a decade ago (it has roots back to ideas I had in 2003.) The project is aptly named libhijack[0].

One common technique is to rely on shared memory-backed file descriptors, writing the shared object to the shmfd, lseek(shmfd,0,seek_set), then fdlopen(shmfd). This causes the RTLD to load the shared object from anonymous memory. In fact, I've published a PoC[1] that shows this very technique.

I'm currently working on providing shmfd-based anonymous shared object injection support in libhijack, so it can be performed over the ptrace boundary with a simple API call. Imagine something like this on a webserver running nginx:


pid_t pid = get_nginx_pid();
const char *path_to_shared_object = "/lib/libpcap.so.8";
InjectSharedObject(pid, path_to_shared_object);


This would cause the target process to create a new shmfd, write the contents of libpcap.so.8 to it, seek to the beginning, then load it via fdlopen.

I have this mostly implemented, but I'm running into some ptrace oddities.

Where this ties into HardenedBSD's src is: while writing this code, I kept thinking to myself, how would I defend against this kind of technique? Results from fstat(2) aren't helpful as there's no way to detect that we're looking at an anonymous shared memory-backed file descriptor.

However, I noticed that calling fstatfs(2) on the shmfd causes undocumented behavior: fstatfs(2) will return EINVAL. The underlying code for shared memory file descriptors doesn't implement a handler for fstatfs(2), causing the syscall to return EINVAL.

I then added code to the RTLD to check the return value of a call to fstatfs(2) on the file descriptor passed in when RTLD hardening is enabled. If fstatfs(2) fails and sets errno to EINVAL, we prohibit loading the object.

This would force an attacker to fully implement what I call a "remote RTLD": an out-of-process RTLD that loads objects over a boundary (the boundary in this particular case being ptrace.) The attacker would have to force the application to call mmap (which libhijack supports), inject into those new mapping (which libhijack supports), but then perform all the RTLD logic and fixups over the boundary (which libhijack does not support.)

My hope is that one day, libhijack gains that last little bit. That last little bit is the most complex bit. That's why I'm going the shmfd route first: to prove the concept and to flush out a "rough draft" of what's in my head.

HardenedBSD's PaX NOEXEC-inspired strict W^X implementation is effective over the ptrace boundary, further frustrating the concept of a remote RTLD.

[0]: https://github.com/SoldierX/libhijack
[1]: https://git.hardenedbsd.org/shawn.webb/random-code/-/tree/main/memdlopen

May 2023 has been a very busy month behind-the-scenes here at HardenedBSD. I want to start off, though, by talking about infrastructure downtime as it's the most important take-away from this status report.

On 03 June 2023, in preparation for our move to Colorado, I will take down the following servers (hosted out of my home):

1. GitLab ( https://git.hardenedbsd.org/ )
2. The main installers mirror ( https://installers.hardenedbsd.org/pub )
3. The package build servers
4. The OS and update build servers
5. The Tor Onion Service nodes

The last pre-move builds will start tomorrow on 01 June 2023. They should complete by 02 June 2023. The builds will be accessible via our two mirrors. The link to the list of up-to-date HardenedBSD mirrors is: https://hardenedbsd.org/content/mirrors

We're grateful for those who provide mirrors. You ensure that HardenedBSD's installers (and hopefully one day: packages) are available regardless of our own infrastructure. The project, and I'm sure the entire community, thanks you.

At the time of writing this status report, we have a tentative temporary hosting solution with limited bandwidth capabilities. We're evaluating multiple hosting possibilities, with this tentative temporary hosting solution being only a backup in case those other options don't pan out. We do not have an ETA for bringing the infrastructure back online.

Now, let's get on with the fun stuff! The HardenedBSD Foundation is now fully registered in Colorado! We're moving the headquarters from Maryland to Colorado while still maintaining a presence my Maryland. Keeping a Maryland presence allows us to continue serving local communities. For those curious, our Colorado registration can be found at: https://www.coloradosos.gov/ccsa/ViewReports.do?ceId=325482

We will soon update the US federal side, the completion of which finishes the move to Colorado. The HardenedBSD Foundation Board of Directors has been a great help in supporting the move.

And now, in the src tree:

1. Shawn fixed NULL pointer derefs in the following portions of the kernel:
   • mrsas(4)
   • powerpc code
   • NVIDIA Tegra CPU Frequency code <- integer overflow, too
   • iw_cxgbe
   • drm2 <- integer overflow, too
   • hdspe-pcm
   • linsysfs(5)
   • beri's virtio support <- integer overflow, too
   • firewire(4)
   • qnnxe(4)
   • axgbe pci code <- integer overflows, too
   • mmc(4)
2. On 14-CURRENT (and soon in hbsdfw), SHM hardening places restricitons on what can be done with the shared memory subsystem (see `shm_open(2)`.) This feature is launching with one technique (with more planned):
   • Use of `shm_open(2)/__sys_shm_open2` system calls is prohibited when:
     1. The `hardening.harden_shm` sysctl tunable is enabled;
     2. The process has not opted out of the feature;
     3. The process has entered capability mode (aka, Capsicum mode)
3. FreeBSD introduced an old vulnerability, the infamous (argc == 0) CVE, but this time in the linuxulator. Shawn ensured that HardenedBSD remains invulnerable.
4. Shawn fixed the 14-CURRENT builds by fixing a FreeBSD commit for building ELF Toolchain's `strings(1)` utility. By default, we use llvm's.

And in ports:

1. MrUnix disabled the JIT and re-enabled MPROTECT for www/ungoogled-chromium

In last month's status report, I mentioned that I decided to punish myself by running HardenedBSD 14-CURRENT/amd64 with Cross-DSO CFI enabled for base userland on my primary laptop, even during this move to Colorado. Shawn is happy to report that two months in, and he's still rocking (and keeping up-to-date with) Cross-DSO CFI! :-)

As a reminder, we mirror our src and ports repos on GitHub. They will remain available (and updated as best as I can). Links below.