• DevSummit
• 201309
• Security

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.

Results

201309 DevSummit Security Report.pdf

/dev/random

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 Snowden -- 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.

Package Signing -- bapt

Had two fairly intense sessions in Cambridge. In short term need this working so we can ship signed packages for 10.x

pkgng has simple signature on pkg check Don't want certificate on builders -- signature should be on hash by signing server Adminstratively need to be able to choose which signatures to trust /etc/pkg/fingerprints/{trusted,revoked} -- freebsd-update will pull any changes pkgng internal code implemented. pkg signed by revoked signature will be rejected. Don't have signing servers to test with. Don't have code for signing server (who is responsible?) Need to add signing checks to /usr/bin/pkg in base Is close, need boxes setup soon in cluster so we can test.

SO to provide (even a temp) key for testing within days

Should we use /etc/keys rather than /etc/pkg to store keys in generally? Subdirectories for different purposes /etc/keys/pkg, /etc/keys/SO

freebsd-update will try and merge changes under /etc -- mark keys as not to be modified.

Break for Lunch

VuXML/audit -- Things we might like to do

VuXML by Jacques Vidrine

XML schema for expressing information about pkg vulnerabilities. Tools (portaudit, pkg audit) to scan system and tell you if you have vulnerable pkgs installed.

portaudit has cronjob to condense VuXML to one-line summaries rather than reading directly

VuXML -- list of affected ports and packages by name, ranges -- which version number. Basically works by a sting match Ref django vuln: py26-django and py27-django are exactly the same port except for some compilation options. py{26,27}-django-devel are a different port. (Nb. python-3 items missing from VuXML)

Opposite problem with perl, emacs, php, mysql which are effectively branches of an original port VuXML can miss a package if it was renamed

pkg audit -X can use vuxml -- this should be the default CVE numbers. CVEs assigned by Mitre. NVD Republished by NIST, but not blindly. Uses CVSS metrics to assign severity score. The can get it wrong...

Interesting part: Vulnerable software and versions on NVD website. Could extract this from NVD site as XML and import into VuXML. We often get VuXML wrong eg. mixing up gt and ge on version numbers.

Problem matching version mubers: if we backport fix to eg 1.4.7 we'll call it 1.4.7_1 Can add additional fields to CPE naming spec. Can add a revision number for a port.

We need to record the CPE in ports and packages. django port needs to define variables either directly or eg. by defining CPE_VENDOR and derive other parts from PORTNAME etc. Similarly to MASTERSITES

(With staging for eg. an SourceForge port need almost no more than to set the port name and that it needs autotools and review the generated plist)

Need to incorporate CPE into portaudit etc. Check license terms for compatibility. Is slightly more complex than a simple match.

Fields in spec arrande in order of how commonly the occur. 1st field /a => application. etc.

Step 1: Add CPEs in ports. This is a bit of work, but can be done before portaudit is able to use it. Have pkg register record CPE as an annotation. Need to do this ASAP -- needs to be available before a vulnerability is discovered.

Will need a fallback mechanism for pkgs that don't have a CPE assigned.

The other problem with VuXML -- should we add FreeBSD SAs to VuXML? Nothing uses VuXML for the base system. FreBSD Update for uname components will not update the kernel version so the version apparently doesn't change Should we add /etc/freebsd_release ? (Previous suggestions lead to huge bikeshed...) Also should update both kernel and world together for best results. Should be OK so long as most people update together. Don't want to report new version until you reboot into new kernel. Good reasons for not updating version unless kernel changes

Could make fake packages for kernel, world etc. (Not pkg specific necessarily) packaged base system? We can record the information in some standard way and import wen eg. pkg is activated. Means we can just use pkg audit to cover the base system.

Equivalnet /etc/lsb-release.d from Linux. Linux also has /etc/issue

The audit tool should look at sysctl kern.bootfile. What does uname report. Handling the case of the interval between updating and rebooting. You're still vulnerable until you've rebooted. /etc/periodic warning? mtime on kernel later than boot time -- not bulletproof. FreeBSD update means mtime on kernel will be time kernel was installed. Problem if NTP makes clock go backwards...

/etc/lsb-release politically difficult because of the 'l' and because we don't necessarilly comply.

Looking for ideas.

Can't rely on eg. SVN metadata in uname -a -- it won't always be present.

We need to validate the userland as well as the kernel. How do we store the userland path level? We don't want a separate version for userland and kernel.

Info in VuXML needs to be sufficient that we can run an older kernel when the userland needs to be update.

Concrete suggestions ? Can rely on what the kernel reports?

Record a version in each binary? Too ineficient.

Reasonable to assume the userland is consistent. inconsistent is not a supportable configuration.

Avoid /etc as that implies admin action to update the version

Have a separate binary (bin/version) or hardcode into uname Could use a shell-script so it's accessible from other architectures

In the root -- /.version

or a shell script in /libexec/version that just does 'echo $VERSION' or write it in a way that is easily parseable.

Colin Percival -- "It's mostly things I meant to do in the past 5 years but never got around to"

CategoryHistorical