Introducing CFI in HardenedBSD

2 March, 2017 - 19:37 — lattera

Control Flow Integrity, or CFI, is an exploit mitigation technique that helps prevent attackers from modifying the behavior of a program and jumping to undefined or arbitrary memory locations. Microsoft has implemented a variant of CFI, which they term Control Flow Guard, or CFG. The PaX team has spent the last few years perfecting their Reuse Attack Protector, RAP. CFI, CFG, and RAP all attempt to accomplish the same goal, with RAP being the most complete and effective implementation. Clang's CFI is stronger than Microsoft's CFG and PaX Team's RAP is stronger than both CFI and CFG. RAP would be a great addition to HardenedBSD; however, it requires a GPLv3 toolchain and is patented.

HardenedBSD is excited to announce the integration of Clang's CFI into base. CFI is enabled by default in HardenedBSD 12-CURRENT on amd64 and can be disabled by setting WITHOUT_CFI in src.conf. CFI is not applicable to architectures other than amd64, though Shawn is working on porting SafeStack to arm64.

Clang's CFI requires a linker that supports Link-Time Optimization (LTO). On 02 March 2017, version 4.0.0 of the lld linker from the llvm project was imported into both FreeBSD and HardenedBSD. lld 4.0.0 is the first version of lld that is usable in base and provides HardenedBSD with a linker that supports LTO. We have been working hard over the past few months in developing and testing the integration of Clang's CFI in HardenedBSD's base. All CFI schemes have been enabled for all of base in HardenedBSD 12-CURRENT/amd64, with the exception of the cfi-icall scheme for a handful of applications. It is possible that we may need to disable the cfi-icall scheme for more applications and we'll need to rely on our user base to identify edge cases. Any application that calls function pointers resolved via dlopen+dlsym will require the cfi-icall scheme to be disabled.

Ogma Promoted to Crew

5 December, 2016 - 08:03 — Shinobi

It is with great honor that I would like to announce the decision to promote Ogma to the status of full crew member of SOLDIERX. During the past year, Ogma has worked hard on VulnTrack as well as being an awesome member of the SX community. As with all members promoted to the status of full crew, we hope that Ogma will continue his efforts and show the same enthusiasm and workmanship that he showed during his inductee status. Congratulations Ogma!

In other news, we are in the process of creating a podcast (talk show) with segments! Hosted by Shinobi, Redcircle, and ThoughtPhreaker.

Introducing SafeStack in HardenedBSD

28 November, 2016 - 09:56 — lattera

SafeStack is an exploit mitigation technique that creates two stacks: one for data that needs to be kept safe, such as return addresses and function pointers; and an unsafe stack for everything else. SafeStack promises a low performance penalty (typically around 0.1%).

SafeStack requires both ASLR and W^X in order to be effective. With HardenedBSD satisfying both of those prerequisites, SafeStack was deemed to be an excellent candidate for default inclusion in HardenedBSD. Starting with HardenedBSD 12-CURRENT, it is enabled by default for amd64. Support for non-amd64 architectures is limited by upstream clang.

As of 28 November 2016, with clang 3.9.0, SafeStack only supports being applied to applications and not shared libraries. Multiple patches have been submitted to clang by third parties to add support for shared libraries. As such, SafeStack is still undergoing active development.

SafeStack has been made available to the HardenedBSD ports tree as well. Unlike PIE and RELRO+BIND_NOW, it is not enabled globally for the ports tree. Some ports, like ports-mgmt/pkg have SafeStack enabled by default. Only those ports that have been tested to work fine will have SafeStack enabled by default. Users are able to toggle SafeStack by using the config target. Additionally, the SafeStack option is only applicable to amd64 architectures. Attempting to enable SafeStack for a non-amd64 port build will result in a NO-OP. SafeStack will simply not be applied.

Here's some good weekend reading for you if you'd like more info about SafeStack and CFI/CPI in general:

  1. SafeStack - Clang documentation
  2. Fine-Grained Control-Flow Integrity through Binary Hardening (PDF)
  3. Control-Flow Bending: On the Effectiveness of Control-Flow Integrity (PDF

VulnTrack 1.0 by Ogma Publicly Released

21 November, 2016 - 18:48 — Ogma

The first full version of VulnTrack has been released, providing the full implementation of the base functionality and several interface and functionality enhancements. For those that haven't had a chance to check out the Alpha or Beta releases, VulnTrack provides monitoring and alerting of security vulnerabilities and exploits based on a provided rule set. VulnTrack uses the rules you enter into the config file and regularly checks NIST and Exploit-DB data for matched vulnerabilities/exploits. This is especially useful for alerting on vulnerabilities that don't fall into your typical patch management system (Web Applications, Network devices, etc) or for profiling a target network to be notified when a vulnerability or exploit becomes public. As always, any feedback or feature requests are greatly appreciated.

Head over to SX Labs and download a copy - https://www.soldierx.com/sxlabs/VulnTrack

Update on HardenedBSD

16 November, 2016 - 12:01 — lattera

A Look Back on 2016

As 2016 is coming to a close, I'd like to reflect about what we've accomplished in HardenedBSD. A whole lot of work has been done and we still have a lot of work ahead of us.

  1. All of base and ports is compiled as Position-Independent Executables (PIEs) along with full RELRO (note: there are some exceptions).
  2. I started hardening some syscalls and sysctl nodes. You'll now notice that the gpart command must run as root because of that. Jailed environments and unprivileged users now cannot see which kernel modules are loaded and root cannot see the base address of kernel modules.
  3. Documentation is now a key priority. Work has started on the HardenedBSD Handbook. We have a long way to go, but the foundation has been laid.
  4. Work on cleaning up our PaX SEGVGUARD implementation has started. We're eventually going to take a whole different approach. Though the current implementation is useful, we haven't guaranteed its stability.
  5. Intel SMAP/SMEP support working in a private feature branch.
  6. LibreSSL imported into HardenedBSD base and made the default in 12-CURRENT.
  7. hbsd-update continues receiving more features and can be considered production-ready. Though there's still more work to do, it is feature complete for the vast majority of use cases.
  8. New, self-hosted package building server.
  9. Port HardenedBSD ASLR and SEGVGUARD to OPNsense, complete with PIE base/ports. Every single OPNsense install has ASLR enabled.
  10. Help FreeBSD with the RPI3 efforts. Test and research clang 3.9.0 and ld.lld on the RPI3. HardenedBSD works flawlessly on the RPI3, showing the strength of HardenedBSD's portability and robustness.
  11. Help FreeBSD with their efforts to port Linux DRM to FreeBSD. This includes buying multiple new laptops and running HardenedBSD with the drm-next-4.7 bits imported.

New Server Install - Downtime Ahead

26 August, 2016 - 11:53 — RaT

Just a heads up to all of our faithful readers, we are getting a new web server installed this weekend. The results will be a much faster user experience, with foundations laid for a site overhaul when the crew is ready. The downside is that there will be some downtime this weekend. Just wanted to give everybody a heads up, as I'm sure at least one lamer out there will claim to have DDoS'd us offline. Everything should be up and running no later than Monday, August 29th, 2016. While we're still online, you should check out new tutorials by r3q13m - our latest crew member of SX.

Syndicate content