Page MenuHomeFreeBSD

stack_protector: Add tunable to bypass random cookies
ClosedPublic

Authored by cem on Apr 16 2019, 5:02 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 10 2024, 9:44 AM
Unknown Object (File)
Jan 7 2024, 9:54 PM
Unknown Object (File)
Dec 23 2023, 2:31 AM
Unknown Object (File)
Nov 16 2023, 12:44 AM
Unknown Object (File)
Nov 11 2023, 5:49 AM
Unknown Object (File)
Nov 7 2023, 6:15 PM
Unknown Object (File)
Oct 14 2023, 11:45 PM
Unknown Object (File)
Oct 14 2023, 3:50 AM
Subscribers

Details

Summary

Add the new tunable, "security.stack_protect.permit_nonrandom_cookies," in
order to continue boot with insecure non-random stack cookies if the random
device is unavailable.

For now, enable it by default. This is not safe. It will be disabled by
default in a future revision.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 23701
Build 22670: arc lint + arc unit

Event Timeline

Add CTASSERT that nitems(__stack_chk_guard) matches our expectations.

Tinderbox passes. I'd appreciate expediency on this one, if possible.

I'm fine with this as an immediate fix for the installer/VM boot issues.

Please expand the commit message a little bit, in that this change is effectively restoring the status quo prior to rS346250.

This revision is now accepted and ready to land.Apr 16 2019, 6:06 PM

this is a reasonable stopgap, approved with the understanding that there will be follow on work to allow MD sources of entropy, like RDSEED on x86 etc

For a stopgap fix I think it's fine. Note that it's probably better to derive __stack_chk_guard from SHA512 of something that we change often (e.g. __FreeBSD_version) concatenate with something that potentially varies, like getcyclecount(), for the fallback guard data: these are not secure random numbers, but would make it harder for an attacker to develop more generic smashing attack.

This revision was automatically updated to reflect the committed changes.