Messages

121

General Discussion / Re: https://meltdownattack.com/

« on: January 17, 2018, 03:08:52 pm »

The amd64 PTI patch has landed in FreeBSD HEAD, disabled by default: https://svnweb.freebsd.org/base?view=revision&revision=328083

We'll enable it by default in HardenedBSD.

122

Development and Code Review / Re: dark theme first look

« on: January 16, 2018, 08:53:54 pm »

I'm really liking what I see! Keep it up!

123

General Discussion / Re: https://meltdownattack.com/

« on: January 16, 2018, 08:53:06 pm »

That's a really good question, one that I cannot answer right now. Once PTI becomes available for 11.1-RELEASE, we at OPNsense will definitely have to do one or more "Call For Testing" rounds.

124

General Discussion / Re: https://meltdownattack.com/

« on: January 16, 2018, 08:10:43 pm »

`make -sj6 buildworld` on my Intel Xeon E3-1505M v5 @ 2.80GHz laptop went from 1.5 hours to about 2.25 hours with PTI enabled. retpoline didn't increase the time.

125

General Discussion / Re: https://meltdownattack.com/

« on: January 16, 2018, 06:07:26 pm »

Another update. In the past few days:

• Merged in Kostik's PTI patch into the retpoline feature branch in HardenedBSD
• Updated the retpoline patch
• Enabled retpoline for the entire HardenedBSD ports tree for users of the retpoline feature branch
• Migrated four systems over to the retpoline feature branch
• Published numerous binary updates
• Completed an experimental package build

Everything's looking good so far. Not a single issue with retpoline, even when building over 29,400 packages. I've had a few issues with PTI, but those have since been resolved. I haven't noticed any real performance impact of retpoline.

The PTI patch does come with a rather large performance hit, especially since it doesn't currently support PCID. (I've been assured by upstream FreeBSD PCID support will follow.) Kostik's PTI patch should land in upstream FreeBSD in a "default disabled" state later today.

I plan to merge into HardenedBSD 12-CURRENT the retpoline patch within the next week or two. Note that retpoline requires lld as the default linker. HardenedBSD enabled lld as the default linker for 12-CURRENT/amd64, but GNU ld remains the default in 11-STABLE/amd64.

The soon-to-be-released OPNsense 18.1 uses FreeBSD 11.1-RELEASE as its upstream, with a select few crucial HardenedBSD bits mixed in. In OPNsense, GNU ld remains the default. Thus, retpoline as currently implemented will not be applicable to OPNsense.

126

General Discussion / Re: https://meltdownattack.com/

« on: January 13, 2018, 01:32:11 am »

I thought I'd update everyone with the progress I'm making in addressing Spectre in HardenedBSD.

• I've created a feature branch called hardened/current/retpoline in HardenedBSD's Playground repo (https://github.com/HardenedBSD/hardenedBSD-playground). This branch is based on HardenedBSD 12-CURRENT.
• I've imported FreeBSD's projects/clang600-import branch and performed some fixups.
• I merged in llvm's retpoline patch and integrated it into the build framework and enabled it by default on amd64 (the retpoline patch only addresses amd64).
• I updated my HardenedBSD laptop with the this retpoline branch.
• I'm now typing this from the same laptop with world + kernel build fully with retpoline.

What's left to do:

• Benchmarking
• Enable and build binary binary updates for the retpoline feature branch for wider testing.
• Further down the road: experimental package builds.

Note that this work is only applicable to HardenedBSD 12-CURRENT/amd64. We're still in the very early stages. Once retpoline makes it officially to llvm 6.0, it will be backported to prior versions. Applying this work to OPNsense will take some time. The work I'm doing is simply research. Getting my feet wet.

So, great progress is being made. FreeBSD's PTI patch is coming along as well.

Screenshot here: https://photos.app.goo.gl/nemutoL6zYceaVH12

127

General Discussion / Re: https://meltdownattack.com/

« on: January 04, 2018, 08:45:10 pm »

From what we discussed on IRC this is a local attack, quite unlikely to hit in a server/appliance scenario. Also meaning it can only be exploited in conjunction with a remote exploit or local shell access.

Hey Franco,

I'd like to clarify this bit. The Meltdown and Spectre attacks are only local. Remote attacks are extremely unlikely. If a remote vulnerability is found and exploited, the attacker will likely use that vulnerability to gain local access. It's after gaining local access that side channel attacks like Meltdown come into play. Meltdown then becomes extremely serious, especially on systems with non-ECC RAM where Row Hammer could be combined to gain arbitrary write access in the kernel.

FreeBSD's kernel is extremely leaky. Meaning, the kernel is full of information leak vulnerabilities. Log in and simply issue `sysctl -a | grep 0x` as an unprivileged user. While Meltdown is critical in that it can leak the contents of arbitrary kernel and userland memory, the FreeBSD kernel itself is an easy target once local access is achieved. Mitigating Meltdown would simply cause an attacker to look at the plentiful amount of other information leaks, buffer overflows, integer overflows, and other vulnerabilities that lie within the kernel.

We at HardenedBSD are paying attention. We're interested in the mitigation FreeBSD comes up with and will work to audit, test, and include it. We will work with OPNsense to merge it in.

OPNsense users are at a great advantage here due to the inclusion of a few of HardenedBSD's core features (ASLR, SEGVGUARD, and SafeStack integration). The inclusion of those features will drive up the economic cost for attackers, frustrating them and their attempts at exploitation. With HardenedBSD, gone are the days of copy & paste mass exploitation.

edit[0]: llvm is working on an approach (https://reviews.llvm.org/D41723) to mitigate Spectre. If the approach makes it to 6.0.0, I will definitely play around with it in a special feature branch of HardenedBSD.

128

17.7 Legacy Series / Re: HBSD SEGVGUARD errors on filterdns

« on: December 01, 2017, 02:15:55 pm »

Cool. By switching to 64-bit, you'll also gain SafeStack, an exploit mitigation that helps with buffer overflows. OPNsense is the first and currently only firewall shipping with SafeStack.

Edited to add: Like I said in my previous post, if you have issues with 64-bit, I'd be happy to help find the underlying issue and fix it. ASLR simply is rather limited on 32-bit systems and frankly not worth it on 32-bit systems.

129

17.7 Legacy Series / Re: HBSD SEGVGUARD errors on filterdns

« on: November 30, 2017, 05:21:42 am »

It's possible our ASLR is a bit too aggressive on 32-bit. I would suggest trying 64-bit. Below is a more detailed explanation as to why. If you don't understand, no worries. However, I'd just like to take the opportunity to document why it might be an issue.

The VDSO must lie between the top of the stack and the kernel virtual address space. Given that the 32-bit address space is extremely limited, it's possible that trying to find a mapping for the VDSO is failing, causing issues and resulting in crashes. Our SEGVGUARD implementation is a deterrent for ASLR bruteforcing, preventing frequently-crashing applications from being restarted too quickly (similar in concept to adding a delay each time someone enters the wrong password on a login prompt.)

In general, ASLR on 32-bit is rather weak. Like mentioned above, there simply isn't enough bits to randomize effectively. This isn't a problem with HardenedBSD's implementation; rather, it's a weakness inherent in the architecture. This isn't an issue with 64-bit systems as the virtual address space is sufficiently large.

To see if ASLR is the issue, you could add the following line to /boot/loader.conf.local:

hardening.pax.aslr.status=1

That will effectively disable ASLR on your system. If you still see the issue, please let me know and I'll spin up a virtualized 32-bit OPNsense installation to see if I can reproduce the issue.

130

17.7 Legacy Series / Re: HBSD SEGVGUARD errors on filterdns

« on: November 30, 2017, 03:27:43 am »

When you said you are running the i86 version, does that mean i386 (aka, 32-bit)?

131

17.7 Legacy Series / Re: HBSD SEGVGUARD errors on filterdns

« on: November 30, 2017, 01:13:40 am »

That message would happen because filterdns is crashing often. Can you provide a core dump or steps to reproduce your issue?

132

18.1 Legacy Series / Re: [CALL FOR TESTING] FreeBSD 11.1, newer Realtek vendor driver and more

« on: November 03, 2017, 05:47:06 pm »

Hi Lattera,
are you using VLANS on your productions ?
I was curious why IPS mode ?

I don't use VLANs currently. I use Suricata in IPS mode to help increase security.

133

18.1 Legacy Series / Re: [CALL FOR TESTING] FreeBSD 11.1, newer Realtek vendor driver and more

« on: November 02, 2017, 05:48:27 pm »

I just got around to testing my Tor-ified setup and all is well there, too.

134

18.1 Legacy Series / Re: [CALL FOR TESTING] FreeBSD 11.1, newer Realtek vendor driver and more

« on: November 01, 2017, 06:29:00 pm »

I migrated my OPNsense firewall at work from 17.7 to 18.1. Working great so far. Suricata is in IPS mode.

135

17.1 Legacy Series / Re: Any chance of upgrading freebsd 10.3 to 11.0 on Raspberry Pi with opnsense ?

« on: August 24, 2017, 05:07:58 pm »

Here's where we stand on arm64:

• Embedded dev boards like the RPI3 will need their own OPNsense images, due to u-boot. Can't do a generic arm64 image (at least, not yet.)
• There's a couple patches that I need to commit to the OPNsense tools.git repo to allow for native arm64 builds. I don't have those patches anymore due to reinstalling the arm64 dev box I was using. The box got hosed and I didn't have any backups (hey, it's a dev box.)
• I wasn't able to complete an OPNsense arm64 build due to some ports build failures with ld.lld. That was back when ld.lld was at 4.0.0. FreeBSD/HardenedBSD has ld.lld 5.0.0 now, so more ports should hopefully build.

Once I get #2 and #3 finished, #1 should be easier to do, hopefully. I'm not sure targeting embedded-style dev boards like the RPI3, Pine64, etc. would be worthwhile for OPNsense to do in any official capacity, since they all currently require their own images (again, due to u-boot). If FreeBSD is able to get a "one image to fit them all," that might change.

The dev box I'm using right now is currently set up for porting SafeStack to arm64. Once I've made more progress in that area, I'd be happy to switch it back over to OPNsense development. That could take a month or so, though. Feel free to keep pinging me to keep reminding me. A reminder here and there never hurts.