So... just found out I can watch projects on github, think I'm going to start reading random C sources from #HardenedBSD, #FreeBSD, #DragonFlyBSD, and #OpenBSD to help build up my ability to do anything useful in C. Has been fun so far looking at OpenBSD's cat(1) and cp(1)

Ah, pues no sólo. #FreeBSD no logra actualizar los repositorios... aunque todo lo demás tire.
Pues también se ha roto parte de la red en #FreeBSD bajo #VirtualBox 5.1 en #Debian 9. #leches

Today, I finished the Stack Clash mitigations in .

Here's the highlights:

1. Default 2MB guard between the bottom-most part of the stack and other memory mappings.
2. Plug the hole that makes the guard ineffective
3. Disallow applications from requesting or being granted memory mappings within the bottom-most limit of the stack and the top of the stack.

@liate Because implementing ASLR in was Oliver's thesis research project and one of my personal goals. Out of the difficulties (and eventual failure) of upstreaming ASLR to FreeBSD was HardenedBSD born.

Now, we want to give the FreeBSD community a choice. We continue our work on to give the community a choice in security.

If you would like to help fund 's efforts and like how promptly we addressed , we accept PayPal and Bitcoin.

Our Bitcoin address: 1FmbSRvZK4yC1b6ajeZWSvYXV2nmvwdWQq

Our PayPal address:

I will be doing new builds of for the and today, which include Stack Clash mitigations and the ability to use our new signed arm64 package repo.

I just fixed a false positive in my PoC.

The RTLD NX bypass also affects , but not (on amd64 and arm64).

would like to celebrate "National FreeBSD Day" with its stack guard page disabled:

has it enabled by default.

(rarely) triggers kernel panics on all 3 of my machines. :<

@Zulgrib and are focused on security. on portability (but with a few PaX features ported over for security). on enterprise features (ZFS, Jails, DTrace). With being based on , you get enterprise features with enhanced security.

3/3 #FreeBSD has packaged version 2.4.25 since December, but I assume Squid was regularizing headers for me. I guess HAProxy is more laissez-fare about these things, so the change exposed the server to this bug I wrote last year.

The right fix would be to re-flash the micro-controller with patched firmware, but that's a hassle. A quick and dirty workaround is to just tell Apache to relax. Adding `HttpProtocolOptions Unsafe` at least gets the data logging back up and running for now.