Sinon, la RC2 de #FreeeBSD est prête; Mis à part quelques correctifs, c'est la mise en place de barrières pour éviter les #stackclash qui est au menu

Thank you, , for yet another flawless upgrade to 17.1.9! It's nice to see the mitigations made it in, too.

After my latest fixup commits, I've started a new pkg exp-run for . I'm hoping I've got it all fixed after the major stack architecture changes introduced.

So the latest work done by can cause a kernel panic if the user has set security.bsd.stack_guard_page > 1.

This has already been mitigated in by ensuring mmap(MAP_FIXED) requests are NOT within bounds of the stack.

What could be done to improve it:

1. Don't allow unmapping of guard pages.
2. Don't allow remapping guard pages with MAP_FIXED.
3. Use MAP_GUARD with libthr's stack guard.
4. Increase the default size of the stack guard.

's mitigation landed:

A few thoughts:

1. I really like the new MAP_GUARD, which is useful for guarding between shared objects.
2. I'm not sure I like that MAP_GUARD mappings can be unmapped.
3. Guard mappings can be mapped over with MAP_FIXED. I don't like that.
4. No attention paid to the per-thread stack guard (libthr). Easy to fix, though.

If an attacker can do items 2 and 3, it's already game over, though.

@david has ASLR. We tried to upstream it over a period of two years, but failed. No matter what, mitigations would only be useful on systems that have ASLR. Otherwise, the attacker already knows where the stack is and can abuse it.

Tomorrow, I'll be MFC'ing all the fixes from 12-CURRENT to 11-STABLE. I'll also write up a blog post about how we've decided to mitigate it.

Now with the mitigations fully completed in , it's time to update all of HardenedBSD's infrastructure.

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.

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: