This is an old revision of the document!
FreeBSD Developer Summit: Security Working Group
We would like to cover the following topics. This is not an exhaustive list and if you feel there is something missing that you want to talk about, contact the session chair and your topic will be included here.
Agenda
Please send talks, brain storm topics, or other proposals to the session leader, DagErlingSmørgrav.
| Who | Description |
|---|---|
| MarkMurray | /dev/random |
| BaptisteDaroussin | Package signing |
| SofianBrabez | Mitigation |
| DagErlingSmørgrav | VuXML / auditing |
| UlrichSpoerlein | Coverity Scan |
Results
(Add a list or attach slides detailing the achieved results here.)
MM absent. DES summarises /dev/random discussion from Cambridge sysctl to choose rng adaptor committed – mostly for HW support. yarrow as fallback Also support for other RNG HW which only input to yarrow 10.x fix known bugs – passing in part of struct that is mostly zeros on 64bit Pawel's patch: in dev attach call binuptime before and after attach and feed delta into yarrow. Entropy estimation? New: Statistical analysis by benl: 4bits entropy per devices conservative estimate[*]. Can commit soon. Important: feed data into yarrow v. early in boot. Need good entropy very early on – eg. generation of ssh keys on first boot Current initrandom script to feed data into yarrow is 'crap' – most of the data is either static or predictable. [*] VirtualBox VM OK, embedded platforms we lack data. Mark Murray will implement fotuna but not for 10.x Embedded systems will probably pre-generate keys. Some have very few devices.
Edward Snowdon – v. high probability of backdoors in some (HW) RNGs. Including elliptic curve generator included in NIST. rdrand in ivbridge not implemented by Intel… Cannot trust HW RNGs to provide good entropy directly. (rdrand implemented in microcode. Intel will add opcode to go directly to HW) This means partial revert of some work on rdrand and padlock – everything will feed into yarrow or fortuna in future. Fortuna doesn't require estimating entropy – big advantage Estimating entropy remaining to system was SotA 15 years ago; not the best way now. Fortuna designed s.t. even if you can influence input, delay before this affects output long enough to make attacks infeasible (3 weeks) Generation of ssh keys on install – bsdinstaller to save entropy / generate keys as last thing Installing system and cloning image? Having some entropy will mean keys diverge.
Mitigation – Sofian
Comparison with other operating systems: what can be added in short term, what can be added eventually.
Mitigation: techniques used to counter exploitation. Implement at binary level, at router level, in network stack etc.
OpenBSD has Address Space Layer Randomization
We don't have randomization in code, data, linker, libc, heap, stack. data, heap, stack DEP.
sysctl kern.elf{64,32}.nxstack=0 toggle DEP on stack
sbz patch adds 2 new sysctl: kern.stackgap_random and bsd.security.mmap_random Add disabled by default with aim to enable by default for 11.x
Other potential: SSP Stack Smash Protector Capsicum
Libc mitigation: randomize address of ldbase
NetBSD has bacs implementation we could investigate
Finer grained activation? Possible to disable for single executable
SSP: mostly for ports
focusses on avoiding stack based overflows. Pushes canary on stack on function call, checks canary unchanged on function exit. Committed to base in 2008. Really simple to do for ports, but many corner cases. i386/gcc linking can prevent correct linking.
ldscript to pull in libssp_nonshared contains symbols for i386 – this works; now able to enable by default. Committed last week.