I’m moving the rest of the large items from our rental home to our new home. I’m hoping to also expand the HardenedBSD development and build infrastructure by one server, depending on schedule.
My wife and I just bought a home! I’m going to move the majority of the smaller items to the new place this weekend. If the stars align, I’ll also move the HardenedBSD development and build infrastructure.
This is going to become an ever more challenging problem, especially for existing at-risk populaces. We’re already seeing the need for safe, anonymous human medical transport across geographic boundaries as a direct result of certain recent regressive and oppressive political policy changes in the US over the past couple years.
In a seriesofcommitstoHardenedBSD for hardening the RTLD, we made ldd(1) nonfunctional by default. Users must set the hardening.harden_rtld sysctl tunable to 0 in order for ldd(1) to work.
Hardening the RTLD has been somewhat problematic for our users. I feel that keeping it enabled by default, we’re able to determine which applications need fixing. Indeed, applications like LibreOffice and Java use non-standard library paths, relying on the RTLD to accept an arbitrary LD_LIBRARY_PATH environment variable.
Why make it non-functional? rtld-elf already supports:
Using openat with provided file descriptors
Passing those file descriptors in with LD_LIBRARY_PATH_FDS
It would be pretty simple to add a mode where, when you enable tracing, it opens / read only, calls cap_enter, closes all other file descriptors, and falls back to resolving paths using the read-only file descriptor that it has for the root. That’s probably no more than a 10-line change and, matter how compromised it is, the worst it can do is sit there consuming CPU cycles and spamming your terminal: it can’t write to anything other than stdout / stderr.
LD_LIBRARY_PATH* is also prohibited when RTLD hardening is enabled. I’m hoping to close some gaps in mitigating post-exploitation tooling. The RTLD provides a fun and rich playground for post-exploitation hijinks.
I’m currently researching how to prevent fdlopen from using a memory-backed file descriptor (like that offered by memfd_create).
LD_LIBRARY_PATH* is also prohibited when RTLD hardening is enabled
That seems like an overly strict default that will be sufficiently annoying that people will turn it off globally. Have you considered adding it as an ELF note so that specific binaries can opt out of it?
I’m currently researching how to prevent fdlopen from using a memory-backed file descriptor (like that offered by memfd_create).
That ought to be impossible by design (UNIX really wants file descriptors to be opaque and fungible), but there is probably some ioctl that works on them (maybe one of the sealing ones?) but returns errors for regular files (or vice versa) that you can use.
I asked on LinkedIn when you posed about this, but what is your threat model here? Any attacker who can create and map a memory fd has the ability to do anything that rtld can do within their own process (e.g. mprotect relro GOT pages and redirect functions to code that they’ve injected), so I can’t see how preventing rtld helps. If it did, an attacker could quite easily compile rtld without the mitigations and inject that into the victim process first and then use all of the evil rtld functionality instead of the default ones, and an attacker who wants to use these rtld functions must, by definition, already have the ability to do this.
That seems like an overly strict default that will be sufficiently annoying that people will turn it off globally
Most people, including myself, do turn it off for desktop environments. However, server deployments typically leave it on, unless they’re dealing with things like Java.
Have you considered adding it as an ELF note so that specific binaries can opt out of it?
We don’t modify binaries, but we do use filesystem extended attributes to store out-of-band per-application exploit mitigation toggle data. That way, we leave the file itself unmodified, making forensics a bit easier (since we’re not changing the hash or signature of the file.)
there is probably some ioctl that works on them (maybe one of the sealing ones?) but returns errors for regular files
I recently figured out that calling fstatfs(2) on a memory-backed file descriptor results in failure.
mprotect relro GOT pages and redirect functions to code that they’ve injected
Unless PaX MPROTECT is disabled, this isn’t possible on HardenedBSD.
The goal here is to increase the economic cost of an attacker. Now that attackers can’t rely on the RTLD, they must write and inject their own RTLD into the process. This is the overarching goal of my libhijack project, though I’m currently working on the (memfd_create(2) + fdlopen(3)) paradigm right now. Implementing what I call a “remote RTLD” (an RTLD that gets injected over the ptrace boundary) that loads shared objects into anonymous memory mappings is incredibly difficult (and still impossible under a default HardenedBSD installation due to multiple hardening techniques we apply.)
As it stands now, HardenedBSD has effectively squashed an attacker’s ability to anonymously load/inject shared objects.
We don’t modify binaries, but we do use filesystem extended attributes to store out-of-band per-application exploit mitigation toggle data. That way, we leave the file itself unmodified, making forensics a bit easier (since we’re not changing the hash or signature of the file.)
I assumed this would be something you’d incorporate into the port, so you disabled the feature breakage in programs that rely on it in the packaged version. Having a non-invasive mechanism for when your use of the program relies on a feature but normal usage doesn’t is nice too.
Unless PaX MPROTECT is disabled, this isn’t possible on HardenedBSD.
Does this prevent me from copying the data and calling mmap with MAP_FIXED to replace the GOT page with my own version? If not, the attack is possible just with a different system call.
The goal here is to increase the economic cost of an attacker.
That’s the bit that I remain unconvinced by. You are requiring them to do a different thing, but the new thing requires them to have the same level of compromise as the old thing and is no harder to automate, so once they’ve done it once they can do it repeatedly. In exchange for this, you make life harder for normal users by breaking a bunch of useful things.
Now that attackers can’t rely on the RTLD, they must write and inject their own RTLD into the process
But, to usefully rely on rtld, they must already have enough of a code reuse attack that they can make system calls. Once someone is in a position to use this primitive, they have a huge number of other options for what they can do, so blocking one route feels a bit like putting a road block in the middle of a field - sure, you can’t go the most direct route through it, but going around it is negligible extra effort. It’s not breaking a first-order primitive that attackers use, it’s not even breaking a second-order one.
This feels like a lot of work for very little gain. In contrast, consider the memcpy protection that I’m trying (not very hard) to upstream with the snmalloc work. This blocks a first-order primitive that, in our analysis (your corpus may vary), was the root cause of about 10% of vulnerabilities that led to arbitrary code execution (linear overflow in memcpy between heap objects). This was probably less work to implement and does not break any features that people rely on (if your code relies on memcpy writing beyond the bounds of an object, it’s broken). If you merge that into HardenedBSD, you break a common first-order attack primitive.
You are requiring them to do a different thing, but the new thing requires them to have the same level of compromise as the old thing and is no harder to automate, so once they’ve done it once they can do it repeatedly.
Agreed here. I hope to someday provide the first open source implementation of the “remote RTLD” technique. Or the second if someone beats me to it. ;-)
But, we must remember, this hardening feature is specifically targeting post-exploitation techniques, one of which being calling fdlopen(3) on a memfd_create(2) file descriptor. It closes one avenue for easy (keyword: easy) anonymous loading of shared objects.
If you merge that into HardenedBSD, you break a common first-order attack primitive.
I’m interested in bringing snmalloc into HardenedBSD. I’d love to have the ability to choose your allocator at buildworld time. I also want to bring in GrapheneOS’ hardened_malloc. Having a choice between three allocators, each with its own security guarantees (or lack thereof) could really help the ecosystem.
I did try bringing snmalloc in, but ran into C++ header pollution issues at buildworld time. I think I reported the issue on that mailing list thread you created. I might give it another shot now that llvm16 is in base. Perhaps the situation has changed.
But, we must remember, this hardening feature is specifically targeting post-exploitation techniques, one of which being calling fdlopen(3) on a memfd_create(2) file descriptor. It closes one avenue for easy (keyword: easy) anonymous loading of shared objects.
My confusion is about where you’re in a situation where you can call memfd_create or shm_open (the former, I believe, is a wrapper around the latter on FreeBSD) and then can perform some write system calls to fill it with arbitrary data and can then call fdlopen, which internally calls mmap but you can’t call mmap. If I can call mmap and map the page executable, then I have complete arbitrary-code execution and I can then do any sequence of steps that I want to further take control over the process, including calling ftruncate to extend my shared-memory object, injecting more code / data into it, and calling mmap to map it over other pages full of code / GOT data, and so on.
Does HardenedBSD add a mechanism to lock bits of the address space so that subsequent mmap calls can’t replace them? That would protect GOT / code pages from tampering (just disabling mprotect doesn’t, though it does mean that it would show up in procstat - you could also use DTrace to monitor long-running processes for changes to their address mappings and add those to the auditdistd log for forensics).
An attacker could still find thread stacks and replace return addresses on them with pointers to your own code or tamper with vtable pointers and so on without anything other than the addition of new executable pages being permitted.
LLVM’s remote JIT already has all of the tools that you need for doing this - it’s basically what LLDB does (JIT some code in one process, inject it into another, resolving symbols against things in the target process) so it’s not even as if you’d need to write much new code to automate this.
The root problem that I think you’re trying to solve is that an attacker can inject arbitrary code after they have a limited code-reuse attack. If you want to properly address that, I’d look at veriexec (I think some Juniper folks ported it from NetBSD, but it looks like it was never upstreamed). You could enforce a per-process rule that the only pages that can be marked executable are ones with valid veriexec entries. This would still let an attacker inject code from any libraries on the system (at least, ones that they could get a read-execute file handle to) but would not let them inject arbitrary code, so they’d still be limited to code reuse attacks, just with a potential mechanism for extending the set of gadgets by loading additional libraries.
All of this feels like a losing battle though. The number of non-trivial programs that don’t contain enough gadgets for a Turing-complete weird machine is tiny, so unless you’ve got a working CFI scheme (which has been impossible in the absence of a non-bypassable memory safety scheme) then an attacker doesn’t need to inject executable code.
I did try bringing snmalloc in, but ran into C++ header pollution issues at buildworld time. I think I reported the issue on that mailing list thread you created. I might give it another shot now that llvm16 is in base. Perhaps the situation has changed.
This was a build system issue. The C++ headers were added after the C ones in the libc build, which meant that #include_next did the wrong thing and everything broke. I think it was fixed, but I’m not 100% sure. I’ve been running on my dev machine with snmalloc as my libc malloc for a few years and with the memcpy mitigations enabled (for stores only by default, memcpy overflows for information disclosure are opt in and I don’t normally) for a bit over a year with no problems.
Does HardenedBSD add a mechanism to lock bits of the address space so that subsequent mmap calls can’t replace them?
Nope. I could see that being useful in some cases, though. Assuming munmap and mprotect of “protected” pages is also prohibited.
If I can call mmap and map the page executable, then I have complete arbitrary-code execution and I can then do any sequence of steps that I want to further take control over the process, including calling ftruncate to extend my shared-memory object, injecting more code / data into it, and calling mmap to map it over other pages full of code / GOT data, and so on
In my particular use case (libhijack), we force the target process to create anonymous memory mappings, and inject executable code there. Then we replace the GOT entry with the address of our injected code.
The problem with this approach is that it’s a lot of work, even though libhijack has already abstracted out a lot of the really difficult bits.
You could enforce a per-process rule that the only pages that can be marked executable are ones with valid veriexec entries.
I really like that idea. Though, it would likely need to be both per-DSO and per-binary? I’d rather not go down the Microsoft route of having security flags be per-DSO. It hasn’t worked out so well for them.
Nope. I could see that being useful in some cases, though. Assuming munmap and mprotect of “protected” pages is also prohibited.
You don’t need munmap. You can mmap directly over another mapping (this is how you do reservations). This lets you bypass the mprotect protections on the GOT trivially.
I really like that idea. Though, it would likely need to be both per-DSO and per-binary? I’d rather not go down the Microsoft route of having security flags be per-DSO. It hasn’t worked out so well for them.
I believe iOS basically has this rule and UWP apps on windows have similar ones, though with very exec you don’t necessarily need a signing entity, depending on the property that you are trying to enforce. You don’t need to have a per-DSO flag, you do need something to authorise processes to opt out so that they can do dynamic code generation. In the UWP and Apple ecosystems, this is handled via an entitlement, which is part of the signed bundle for a program.
My wife and I just singed a year lease for a rental house in Colorado! We’re moving in this weekend. The process of signing the lease has been an incredible pain. But, the pain was worth it in the end.
I’m hoping this home has enough power to be able to host the HardenedBSD development and build infrastructure. That’s what I’ll work on next week.
I’ve started reviving an old post-exploitation tool I started over a decade ago. I hope to finish teaching it how to inject shared objects anonymously over the ptrace boundary. I suspect it’ll take me a few more months of work, then I”ll release a 1.0 version.
I’m bringing down the HardenedBSD build infrastructure in preparation for the impending move to Colorado! Wahoo!
This weekend is all about packing. The following weekend is when we vacate our home, handing it over to our real estate agent, and drive to Colorado. Freaking crazy that it’s just a week away.
Less than two weeks until we move to Colorado! I’m hoping to finish packing our living room and kitchen this week.
For HardenedBSD:
I need to file an updated registration with the federal IRS to update the address to the Colorado location.
The installation media for 14-CURRENT builds isn’t being produced right. I need to address this before the next bi-weekly build, which will be started via cron on 01 June 2023.
Yesterday (Sunday), I added a new security hardening technique: we now prohibit use of shm_open(2) when a process is in capabilities mode. I need to expand that to cover the majority use case: non-sandboxed processes.
For work:
I’m trying to figure out how to properly use go-swagger. I’ve generated a template project based on a properly-formatted swagger.yml file, yet the project won’t compile. The documentation for go-swagger leaves a freakton to be desired, so I’m having to reverse engineer things that are supposed to just magically work.
I’m trying to figure out how to properly use go-swagger. I’ve generated a template project based on a properly-formatted swagger.yml file, yet the project won’t compile. The documentation for go-swagger leaves a freakton to be desired, so I’m having to reverse engineer things that are supposed to just magically work.
I was experimenting with go-swagger the other day and experienced the same thing as you. In my case, the file it generates starting with configure_*.go won’t be re-generated if it already exists, so if you’re iterating on the swagger.yml file and re-generating, I’ve found the configure_*.go file drifts pretty hard and in my case resulted in compiler issues.
I’ve resigned to copy/pasting the template code into the existing non-swagger project to swagger-ify it. I’ve wasted too much time trying to get the actual go-swagger tool to work.
For the HardenedBSD build infrastructure, which I host out of my home behind a single IPv4 address and tunneled IPv6 (with HE’s TunnelBroker service), I use nginx as a web reverse proxy. Below is a sanitized version of the nginx configuration.
All hostname-related records in the hardenedbsd.lan domain have ONLY an IPv6 AAAA record. No A records exist for *.hardenedbsd.lan.
Hmm, it seems like to me you are re-doing encryption right? It’s not exactly a SNI technique per se, is it?
I wonder though what is the impact of connecting two TLS segments like this in terms of performance or traffic increase.
Cryptographic key material is required regardless. In this context, SNI is used simply to determine which host the client is trying to reach. nginx doesn’t require any extra configuration parameters for SNI (meaning: full native transparent support for SNI) when SSL/TLS support is compiled in.
Cryptographic key material is required regardless.
This is the part I don’t understand; what is the minimal requirement for the material? dhparams or?
So if I understand well, your NGINX cannot “dump” the plaintext communication between a client and git.hardenedbsd.org for example, right? Do you have any link on the matter? I am definitely confused a bit on this.
If you take a look to my article, I never use any cryptographic key material. See https://github.com/dlundquist/sniproxy for examples too. It never use any cryptographic key material, neither it does decrypt the traffic.
So that’s why I’m wondering why this is needed in your case.
I’m going to catch up on chores and see if I can integrate GrapheneOS’ hardened_malloc into HardenedBSD. Ideally, users will be able to choose which heap implementation they want during buildworld time.
Still have COVID, so I’m gonna stay home and hack on HardenedBSD and do chores.
FreeBSD is working on native kernel support for netlink. Problem is that the quality of that code is severely lacking, with a number of NULL derefs, which I’ve fixed downstream in HardenedBSD. I took the time to harden parts of the kernel malloc implementation because of that. I’ve also applied -ftrivial-var-auto-init=zero to key parts of the kernel, including the netlink module. I plan to continue down the path of kernel heap hardening and provide more complete application of trivial auto var init to zero.
I also hope to finalize the new HardenedBSD build framework and infrastructure work this weekend, opening the path for new mirrors of our installation media. For the first time, we’ll also have mirrors of our OS update artifacts.
I guess COVID is somewhat beneficial to the project. ;-)
I’m going to try to get a new build of hbsdfw out the door. hbsdfw is a HardenedBSD-based build of OPNsense I maintain. I’m making progress on Cross-DSO CFI in HardenedBSD. I’m working in the ports tree now, trying to wrap my brain around all the breakages that come from having the base OS fully built with Cross-DSO CFI.
I’m starting a new job at IOActive as a Senior Security Consultant! After two months of being unemployed, it feels really good to be back in business. :-)
As of March 2022, HardenedBSD does this by default for the entire OS userland ecosystem (the OS itself and 33,000+ packages). We’ve only had to disable auto-var-init-to-zero for a small subset of packages.
Applying to the kernel will require more research, but is on the roadmap.
Can you share any details on why you’ve had to disable it for some packages? Is it performance concerns? Buggy software relying on uninitialised variables to be non-zero?
I can’t speak for u/lattera but in my experience the big carve out/exception is code that has “large” stack allocated arrays where the compiler is unable to avoid large pre-zeroing of values that will otherwise be initialized. It’s really easy to see
int a[1000]
for (int j = 0; I j< 1000; j++) a[j]=0;
but for example
int a[1000];
f(a, 1000);
Should the compiler initialize a? clang (and I assume gcc) know the existence and semantics of bzero, memset, etc so can both treat that as a call the initializes a, but if you have a bunch of code that has large amounts of on stack data that has less trivial initializing logic, then it becomes much harder (esp. in C/C++)
I’m going to work through HackTheBox challenges, re-acquainting myself with offensive techniques that I once used to know. I have a feeling and a desire to get back to my roots in offensive security research. I’ve spent over a decade on the defensive side.
HardenedBSD recently switched to auto init to zero by default for the entire userland OS/ecosystem, including 33,000+ packages. Very quite literally zero noticeable performance hit. I would like to see a performance engineer test the before and after of our change, though.
Fixing incorrect code by making things slower for correct code. Not gonna happen.
Except auto initializing everything by default isn’t a performance hit, and pretty much every language other than C and C++ some how manages it.
Also while it took the NSA and NIST saying not use C or C++ to get WG21 to get off it’s delusional horse, the committee finally seems to have started to grasp that continuing to aggressively avoid fixing known safety problems with the language means that it will die.
I can see this as opt-in, but we already have more than a handful of ways to initialize automatic variables.
And yet 10% of CVEs are the result of uninitialized locals.
I’m learning the various AWS Python APIs (boto3). I’ve deliberately put off dealing with anything revolving around AWS in my career, but it seems like today’s world loves vendor lock-in, so…
I’ve got various job interviews lined up for the week. I’m hoping to work towards having an offer on my desk by the 16th of this month so that I can start on or around the 21st.
Tomorrow (Tuesday), I’m going to serve as an election judge in my local gubernatorial elections. I suspect we’ll have a huge turnout.
I’m moving the rest of the large items from our rental home to our new home. I’m hoping to also expand the HardenedBSD development and build infrastructure by one server, depending on schedule.
My wife and I just bought a home! I’m going to move the majority of the smaller items to the new place this weekend. If the stars align, I’ll also move the HardenedBSD development and build infrastructure.
This is going to become an ever more challenging problem, especially for existing at-risk populaces. We’re already seeing the need for safe, anonymous human medical transport across geographic boundaries as a direct result of certain recent regressive and oppressive political policy changes in the US over the past couple years.
In a series of commits to HardenedBSD for hardening the RTLD, we made
ldd(1)nonfunctional by default. Users must set thehardening.harden_rtldsysctl tunable to0in order forldd(1)to work.Hardening the RTLD has been somewhat problematic for our users. I feel that keeping it enabled by default, we’re able to determine which applications need fixing. Indeed, applications like LibreOffice and Java use non-standard library paths, relying on the RTLD to accept an arbitrary
LD_LIBRARY_PATHenvironment variable.Why make it non-functional?
rtld-elfalready supports:openatwith provided file descriptorsLD_LIBRARY_PATH_FDSIt would be pretty simple to add a mode where, when you enable tracing, it opens
/read only, callscap_enter, closes all other file descriptors, and falls back to resolving paths using the read-only file descriptor that it has for the root. That’s probably no more than a 10-line change and, matter how compromised it is, the worst it can do is sit there consuming CPU cycles and spamming your terminal: it can’t write to anything other than stdout / stderr.LD_LIBRARY_PATH*is also prohibited when RTLD hardening is enabled. I’m hoping to close some gaps in mitigating post-exploitation tooling. The RTLD provides a fun and rich playground for post-exploitation hijinks.I’m currently researching how to prevent
fdlopenfrom using a memory-backed file descriptor (like that offered bymemfd_create).That seems like an overly strict default that will be sufficiently annoying that people will turn it off globally. Have you considered adding it as an ELF note so that specific binaries can opt out of it?
That ought to be impossible by design (UNIX really wants file descriptors to be opaque and fungible), but there is probably some ioctl that works on them (maybe one of the sealing ones?) but returns errors for regular files (or vice versa) that you can use.
I asked on LinkedIn when you posed about this, but what is your threat model here? Any attacker who can create and map a memory fd has the ability to do anything that rtld can do within their own process (e.g. mprotect relro GOT pages and redirect functions to code that they’ve injected), so I can’t see how preventing rtld helps. If it did, an attacker could quite easily compile rtld without the mitigations and inject that into the victim process first and then use all of the evil rtld functionality instead of the default ones, and an attacker who wants to use these rtld functions must, by definition, already have the ability to do this.
Most people, including myself, do turn it off for desktop environments. However, server deployments typically leave it on, unless they’re dealing with things like Java.
We don’t modify binaries, but we do use filesystem extended attributes to store out-of-band per-application exploit mitigation toggle data. That way, we leave the file itself unmodified, making forensics a bit easier (since we’re not changing the hash or signature of the file.)
I recently figured out that calling
fstatfs(2)on a memory-backed file descriptor results in failure.Unless PaX MPROTECT is disabled, this isn’t possible on HardenedBSD.
The goal here is to increase the economic cost of an attacker. Now that attackers can’t rely on the RTLD, they must write and inject their own RTLD into the process. This is the overarching goal of my libhijack project, though I’m currently working on the
(memfd_create(2) + fdlopen(3))paradigm right now. Implementing what I call a “remote RTLD” (an RTLD that gets injected over the ptrace boundary) that loads shared objects into anonymous memory mappings is incredibly difficult (and still impossible under a default HardenedBSD installation due to multiple hardening techniques we apply.)As it stands now, HardenedBSD has effectively squashed an attacker’s ability to anonymously load/inject shared objects.
I assumed this would be something you’d incorporate into the port, so you disabled the feature breakage in programs that rely on it in the packaged version. Having a non-invasive mechanism for when your use of the program relies on a feature but normal usage doesn’t is nice too.
Does this prevent me from copying the data and calling
mmapwithMAP_FIXEDto replace the GOT page with my own version? If not, the attack is possible just with a different system call.That’s the bit that I remain unconvinced by. You are requiring them to do a different thing, but the new thing requires them to have the same level of compromise as the old thing and is no harder to automate, so once they’ve done it once they can do it repeatedly. In exchange for this, you make life harder for normal users by breaking a bunch of useful things.
But, to usefully rely on rtld, they must already have enough of a code reuse attack that they can make system calls. Once someone is in a position to use this primitive, they have a huge number of other options for what they can do, so blocking one route feels a bit like putting a road block in the middle of a field - sure, you can’t go the most direct route through it, but going around it is negligible extra effort. It’s not breaking a first-order primitive that attackers use, it’s not even breaking a second-order one.
This feels like a lot of work for very little gain. In contrast, consider the memcpy protection that I’m trying (not very hard) to upstream with the snmalloc work. This blocks a first-order primitive that, in our analysis (your corpus may vary), was the root cause of about 10% of vulnerabilities that led to arbitrary code execution (linear overflow in memcpy between heap objects). This was probably less work to implement and does not break any features that people rely on (if your code relies on memcpy writing beyond the bounds of an object, it’s broken). If you merge that into HardenedBSD, you break a common first-order attack primitive.
Agreed here. I hope to someday provide the first open source implementation of the “remote RTLD” technique. Or the second if someone beats me to it. ;-)
But, we must remember, this hardening feature is specifically targeting post-exploitation techniques, one of which being calling
fdlopen(3)on amemfd_create(2)file descriptor. It closes one avenue for easy (keyword: easy) anonymous loading of shared objects.I’m interested in bringing
snmallocinto HardenedBSD. I’d love to have the ability to choose your allocator at buildworld time. I also want to bring in GrapheneOS’hardened_malloc. Having a choice between three allocators, each with its own security guarantees (or lack thereof) could really help the ecosystem.I did try bringing snmalloc in, but ran into C++ header pollution issues at buildworld time. I think I reported the issue on that mailing list thread you created. I might give it another shot now that llvm16 is in base. Perhaps the situation has changed.
My confusion is about where you’re in a situation where you can call
memfd_createorshm_open(the former, I believe, is a wrapper around the latter on FreeBSD) and then can perform somewritesystem calls to fill it with arbitrary data and can then callfdlopen, which internally callsmmapbut you can’t callmmap. If I can callmmapand map the page executable, then I have complete arbitrary-code execution and I can then do any sequence of steps that I want to further take control over the process, including callingftruncateto extend my shared-memory object, injecting more code / data into it, and callingmmapto map it over other pages full of code / GOT data, and so on.Does HardenedBSD add a mechanism to lock bits of the address space so that subsequent
mmapcalls can’t replace them? That would protect GOT / code pages from tampering (just disabling mprotect doesn’t, though it does mean that it would show up in procstat - you could also use DTrace to monitor long-running processes for changes to their address mappings and add those to the auditdistd log for forensics).An attacker could still find thread stacks and replace return addresses on them with pointers to your own code or tamper with vtable pointers and so on without anything other than the addition of new executable pages being permitted.
LLVM’s remote JIT already has all of the tools that you need for doing this - it’s basically what LLDB does (JIT some code in one process, inject it into another, resolving symbols against things in the target process) so it’s not even as if you’d need to write much new code to automate this.
The root problem that I think you’re trying to solve is that an attacker can inject arbitrary code after they have a limited code-reuse attack. If you want to properly address that, I’d look at veriexec (I think some Juniper folks ported it from NetBSD, but it looks like it was never upstreamed). You could enforce a per-process rule that the only pages that can be marked executable are ones with valid veriexec entries. This would still let an attacker inject code from any libraries on the system (at least, ones that they could get a read-execute file handle to) but would not let them inject arbitrary code, so they’d still be limited to code reuse attacks, just with a potential mechanism for extending the set of gadgets by loading additional libraries.
All of this feels like a losing battle though. The number of non-trivial programs that don’t contain enough gadgets for a Turing-complete weird machine is tiny, so unless you’ve got a working CFI scheme (which has been impossible in the absence of a non-bypassable memory safety scheme) then an attacker doesn’t need to inject executable code.
This was a build system issue. The C++ headers were added after the C ones in the libc build, which meant that
#include_nextdid the wrong thing and everything broke. I think it was fixed, but I’m not 100% sure. I’ve been running on my dev machine with snmalloc as my libc malloc for a few years and with the memcpy mitigations enabled (for stores only by default, memcpy overflows for information disclosure are opt in and I don’t normally) for a bit over a year with no problems.Nope. I could see that being useful in some cases, though. Assuming
munmapandmprotectof “protected” pages is also prohibited.In my particular use case (libhijack), we force the target process to create anonymous memory mappings, and inject executable code there. Then we replace the GOT entry with the address of our injected code.
The problem with this approach is that it’s a lot of work, even though libhijack has already abstracted out a lot of the really difficult bits.
I really like that idea. Though, it would likely need to be both per-DSO and per-binary? I’d rather not go down the Microsoft route of having security flags be per-DSO. It hasn’t worked out so well for them.
You don’t need munmap. You can mmap directly over another mapping (this is how you do reservations). This lets you bypass the mprotect protections on the GOT trivially.
I believe iOS basically has this rule and UWP apps on windows have similar ones, though with very exec you don’t necessarily need a signing entity, depending on the property that you are trying to enforce. You don’t need to have a per-DSO flag, you do need something to authorise processes to opt out so that they can do dynamic code generation. In the UWP and Apple ecosystems, this is handled via an entitlement, which is part of the signed bundle for a program.
My wife and I just singed a year lease for a rental house in Colorado! We’re moving in this weekend. The process of signing the lease has been an incredible pain. But, the pain was worth it in the end.
I’m hoping this home has enough power to be able to host the HardenedBSD development and build infrastructure. That’s what I’ll work on next week.
I’ve started reviving an old post-exploitation tool I started over a decade ago. I hope to finish teaching it how to inject shared objects anonymously over the ptrace boundary. I suspect it’ll take me a few more months of work, then I”ll release a 1.0 version.
I’m bringing down the HardenedBSD build infrastructure in preparation for the impending move to Colorado! Wahoo!
This weekend is all about packing. The following weekend is when we vacate our home, handing it over to our real estate agent, and drive to Colorado. Freaking crazy that it’s just a week away.
Less than two weeks until we move to Colorado! I’m hoping to finish packing our living room and kitchen this week.
For HardenedBSD:
shm_open(2)when a process is in capabilities mode. I need to expand that to cover the majority use case: non-sandboxed processes.For work:
I’m trying to figure out how to properly use go-swagger. I’ve generated a template project based on a properly-formatted
swagger.ymlfile, yet the project won’t compile. The documentation for go-swagger leaves a freakton to be desired, so I’m having to reverse engineer things that are supposed to just magically work.I was experimenting with go-swagger the other day and experienced the same thing as you. In my case, the file it generates starting with
configure_*.gowon’t be re-generated if it already exists, so if you’re iterating on the swagger.yml file and re-generating, I’ve found theconfigure_*.gofile drifts pretty hard and in my case resulted in compiler issues.I’ve resigned to copy/pasting the template code into the existing non-swagger project to swagger-ify it. I’ve wasted too much time trying to get the actual
go-swaggertool to work.I’m going to inventory and pack a good portion of our basement in preparation for our move from Maryland to Colorado this June.
I tested it today in a HardenedBSD VM, so this application isn’t limited to those in the Linux camp. :-)
Good job on a fun little program!
Thanks! Yes, it works on a variety of systems! I named it linuxwave initially because I was pretty much focused on reading data from /dev/urandom
For the HardenedBSD build infrastructure, which I host out of my home behind a single IPv4 address and tunneled IPv6 (with HE’s TunnelBroker service), I use nginx as a web reverse proxy. Below is a sanitized version of the nginx configuration.
All hostname-related records in the
hardenedbsd.landomain have ONLY an IPv6 AAAA record. No A records exist for*.hardenedbsd.lan.Here’s the
nginx.conffile:As a bonus, here’s a snippet of the unbound config file for the HardenedBSD build infrastructure DNS server:
Hmm, it seems like to me you are re-doing encryption right? It’s not exactly a SNI technique per se, is it? I wonder though what is the impact of connecting two TLS segments like this in terms of performance or traffic increase.
nginx is doing SNI behind-the-scenes automatically for me.
But then, what is the
ssl_certificate/ssl_certificate_keyused for? SNI should not require any TLS certificates as far as I understand it?Cryptographic key material is required regardless. In this context, SNI is used simply to determine which host the client is trying to reach. nginx doesn’t require any extra configuration parameters for SNI (meaning: full native transparent support for SNI) when SSL/TLS support is compiled in.
This is the part I don’t understand; what is the minimal requirement for the material? dhparams or?
So if I understand well, your NGINX cannot “dump” the plaintext communication between a client and git.hardenedbsd.org for example, right? Do you have any link on the matter? I am definitely confused a bit on this.
Doesn’t TLS require cryptographic key material? This is just regular HTTPS with TLS and SNI. I’m unsure as to the source of your confusion…
If you take a look to my article, I never use any cryptographic key material. See https://github.com/dlundquist/sniproxy for examples too. It never use any cryptographic key material, neither it does decrypt the traffic. So that’s why I’m wondering why this is needed in your case.
I’m going to catch up on chores and see if I can integrate GrapheneOS’ hardened_malloc into HardenedBSD. Ideally, users will be able to choose which heap implementation they want during buildworld time.
Still have COVID, so I’m gonna stay home and hack on HardenedBSD and do chores.
FreeBSD is working on native kernel support for netlink. Problem is that the quality of that code is severely lacking, with a number of NULL derefs, which I’ve fixed downstream in HardenedBSD. I took the time to harden parts of the kernel malloc implementation because of that. I’ve also applied
-ftrivial-var-auto-init=zeroto key parts of the kernel, including the netlink module. I plan to continue down the path of kernel heap hardening and provide more complete application of trivial auto var init to zero.I also hope to finalize the new HardenedBSD build framework and infrastructure work this weekend, opening the path for new mirrors of our installation media. For the first time, we’ll also have mirrors of our OS update artifacts.
I guess COVID is somewhat beneficial to the project. ;-)
Congrats! I work on Linux networking and it’s always so weird to use Unix and not have the “ip” command.
I’ve been having a really hard time getting over COVID. I’m just gonna take it easy. Perhaps hack a little bit on Cross-DSO CFI in HardenedBSD.
I’m going to try to get a new build of hbsdfw out the door. hbsdfw is a HardenedBSD-based build of OPNsense I maintain. I’m making progress on Cross-DSO CFI in HardenedBSD. I’m working in the ports tree now, trying to wrap my brain around all the breakages that come from having the base OS fully built with Cross-DSO CFI.
A coworker needed a tool to download all of an organization’s repos on GitHub, so I started on a little script to do that. I plan to put the finishing touches on it, enabling support for both public and private repos: https://git.hardenedbsd.org/shawn.webb/random-code/-/blob/main/github/org_repo_clone/org_repo_clone.zsh
I’m starting a new job at IOActive as a Senior Security Consultant! After two months of being unemployed, it feels really good to be back in business. :-)
As of March 2022, HardenedBSD does this by default for the entire OS userland ecosystem (the OS itself and 33,000+ packages). We’ve only had to disable auto-var-init-to-zero for a small subset of packages.
Applying to the kernel will require more research, but is on the roadmap.
Can you share any details on why you’ve had to disable it for some packages? Is it performance concerns? Buggy software relying on uninitialised variables to be non-zero?
I can’t speak for u/lattera but in my experience the big carve out/exception is code that has “large” stack allocated arrays where the compiler is unable to avoid large pre-zeroing of values that will otherwise be initialized. It’s really easy to see
but for example
int a[1000]; f(a, 1000);
Should the compiler initialize
a? clang (and I assume gcc) know the existence and semantics of bzero, memset, etc so can both treat that as a call the initializesa, but if you have a bunch of code that has large amounts of on stack data that has less trivial initializing logic, then it becomes much harder (esp. in C/C++)I’m going to work through HackTheBox challenges, re-acquainting myself with offensive techniques that I once used to know. I have a feeling and a desire to get back to my roots in offensive security research. I’ve spent over a decade on the defensive side.
Fixing incorrect code by making things slower for correct code. Not gonna happen.
I can see this as opt-in, but we already have more than a handful of ways to initialize automatic variables.
HardenedBSD recently switched to auto init to zero by default for the entire userland OS/ecosystem, including 33,000+ packages. Very quite literally zero noticeable performance hit. I would like to see a performance engineer test the before and after of our change, though.
Except auto initializing everything by default isn’t a performance hit, and pretty much every language other than C and C++ some how manages it.
Also while it took the NSA and NIST saying not use C or C++ to get WG21 to get off it’s delusional horse, the committee finally seems to have started to grasp that continuing to aggressively avoid fixing known safety problems with the language means that it will die.
And yet 10% of CVEs are the result of uninitialized locals.
The entire point of the proposal is that it does not slow down correct code. That’s also where most of effort was spent.
I’m learning the various AWS Python APIs (boto3). I’ve deliberately put off dealing with anything revolving around AWS in my career, but it seems like today’s world loves vendor lock-in, so…
I’ve got various job interviews lined up for the week. I’m hoping to work towards having an offer on my desk by the 16th of this month so that I can start on or around the 21st.
Tomorrow (Tuesday), I’m going to serve as an election judge in my local gubernatorial elections. I suspect we’ll have a huge turnout.