Messages

It's important to note that this only enables PIE for applications in base. This does not enable PIE for applications installed via ports/pkg. I'm planning PIE enabled for ports for 17.1.

I updated this morning without a single issue. Here's a screenshot of it working flawlessly for me: https://goo.gl/photos/MjUvMjc2t7D4bZZb7

The exp-run has officially begun!

I've now finished porting over HardenedBSD's ports PIE with RELRO + BIND_NOW support. If you make your own builds of OPNsense and you're feeling adventurous, give the hardening/pie ports feature branch a try: https://github.com/opnsense/ports/tree/hardening/pie

HardenedBSD is currently running a package build for their 12-CURRENT/LibreSSL/amd64 repo. Once that is done, I will do an experimental run (aka, exp-run) to make sure there aren't dragons lurking in corners. If the exp-run finishes successfully, I plan to merge the feature branch into master.

Over the past year, I have had the wonderful experience of working with the OPNsense core team in porting over HardenedBSD's robust ASLR implementation. It is with pleasure and humility that I have accepted their invitation to join the core team. My overarching goal will be to port the main features of HardenedBSD to OPNsense.

Address Space Layout Randomization, or ASLR for short, is an exploit mitigation technology that aims to make certain kinds of vulnerabilities harder to successfully exploit. In order to fully apply ASLR, applications must be compiled as a Position-Independent Executable (PIE). In the short term, my next goal is to enable PIE fully across OPNsense's ports tree. As this is a feature HardenedBSD also needs, I'm using HardenedBSD's ports tree and package building infrastructure as a test bed prior to importing into OPNsense.

OPNsense is investigating migrating to 11.0-RELEASE for its 17.1 release. The Virtual Memory (VM) subsystem has changed drastically between FreeBSD 10 and FreeBSD 11. Since ASLR deals with the VM subsystem, extreme care must be taken in the update of the codebase from FreeBSD 10.3 to 11.0. I will assist in those efforts by freshly porting over the ASLR implementation from HardenedBSD 11.0 to OPNsense's FreeBSD 11.0 codebase.

I look forward to being a part of the OPNsense core team. The coordination between HardenedBSD and OPNsense will bring a more solid foundation on which home users and enterprises alike can build secure and scalable networks.

Stay safe,

Shawn Webb, on behalf of the OPNsense team.

PIE base is already done and PIE ports is nearing completion. Dogfooding PIE ports in HardenedBSD first. But wait! There's more! Also included will be RELRO + BIND_NOW. :)

Once FreeBSD 12-CURRENT supports the RPI3, and OPNsense solidifies its ARM support, I'll try doing a build for ARM64.

Given that turning off ASLR didn't change the resulting kernel panic, I don't think ASLR was the issue. I'll let Franco take it from here.

At the boot loader, could you escape to the loader prompt then use these commands:

set hardening.pax.aslr.status=0
boot

Does it boot fine for you after doing that?

Hey bugbuster,

Can you tell us a bit more about your setup? Can you tell us if Suricata is enabled and is in IPS mode? What other services  are set up? At what point does the kernel panic happen? Before even init runs?

Thanks,

Shawn

Are you running on a 32bit or 64bit box? If you're on 32bit, you may see this occasionally. It's safe to ignore. It simply means that ASLR couldn't properly randomize the stack. There's simply not enough bits in 32bit architectures to shuffle things around.

Hey All,

I've been thinking about this quite a bit for the past few weeks. My life is getting busier and busier and my available hobbyist time is diminishing. I've decided to scale back on a few items, including producing custom OPNsense builds based on HardenedBSD. Doing so takes a good chunk of my time from my main project (HardenedBSD). I will be focusing more of my efforts on HardenedBSD.

In talking with Franco, I'm happy to continue providing patches to OPNsense on behalf of HardenedBSD. My next goal is to help OPNsense implement PIE (and maybe with RELRO + BIND_NOW) across the board for both base and ports. I hope to have that both started and completed sometime in July. I feel I'll take more of a consulting role rather than the custom build producer role.

I'm excited for all the great things OPNsense is doing, especially with regards to security. If you have any questions, comments, or concerns, please let me know.

Editing this to comment: even though I'm scaling back right now doesn't mean that I won't resume doing HardenedBSD-based builds in the future. I've loved doing my own builds and seeing HardenedBSD running on my hardware firewall appliances. If my available hobbyist time increases in the future, I may pick up custom builds again.

Thanks,

Shawn Webb

Hey All,

I just wanted to expound upon the i386 performance impact a little. The reason why Position-Independent Executable (PIE) support on i386 has a performance impact is due to the limited amount of CPU registers. The amd64 architecture has enough registers that it can dedicate one to use for the calculation of offsets. Since i386 is limited, it has to resolve symbols (functions, global variables, etc.) inefficiently. It cannot make use of a dedicated register for symbol offset calculations.

It's important to note that the 12% performance hit is a worst-case scenario. In some cases, the performance hit might be as low as 5%. The point is that you will definitely see a performance hit. This is not due to HardenedBSD or its ASLR implementation, but rather the underlying computer architecture. All operating systems, including Linux and Windows, will have a performance hit when running Position-Independent Code (PIC) on i386.

Which brings up another point: most of your applications will hit PIC. libc is a PIC library. All applications used within OPNsense depend on libc. The RTLD is a PIC library as well. (Fun fact: the RTLD relocates itself.) All dynamically-compiled applications rely on the RTLD.

Thanks,

Shawn Webb

I also just realized that switching out opnsense-update for hbsd-update would also require changes to tools.git to use hbsd-update-build to build the distsets. Now you've got me curious about how this will work. ;)

Hey Shawn! Thanks for working on this despite your busy schedule, we appreciate it.

Having all the goodies of HardenedBSD baked right into OPNsense seems like the perfect match for building a very secure router. I'm glad features have already been backported to FreeBSD 10 and integrated into OPNsense.

Although I might not fully understand, I'm curious about the technical reasons why binary upgrades don't work?

My pleasure. I'm grateful that OPNsense has created such an easy way to perform builds, allowing me to do what I do. The main reason why binary updates don't work is that I still need to stand up the infrastructure to host the files. I also need to patch the OPNsense codebase (which I have forked on GitHub) to point to my infrastructure rather than theirs. Since I started doing the new builds, I created a new binary update mechanism for HardenedBSD itself, called hbsd-update. I'd like to use that instead of opnsense-update for updating base. So that'll involve a little more than just replacing utilities. I gotta make sure that where those utilities (opnsense-update, pkg upgrade, etc.) are called call my utilities instead and call them in the right way. When all is said and done, there's not much work on the side of the code, but mostly I need to get the infrastructure piece working.