2013-08 DevSummit Security session
Topics to discuss
/dev/random session
- What do we want for the long term?
- What can we do in time for 10.0?
- Pawel's attachtimes patch for early entropy gathering
- random_adaptor framework
- HWRNG support:
- As an entropy source for Yarrow / Fortuna
- As a backend for /dev/random
- Selectable mixer
Mitigation topics
- Walkthrough on actual state of security mitigation in FreeBSD
ASLR (exprimental patches on people.freebsd.org/~sbz/aslr) => rewiew + exp-run + security OID
- DEP (nxstack) [data, head and stack OK]
redzone => not in production (double allocation for runtime check)
- ...
General security topics
Topics:
Using CPE in VuXML => no time
- Security Testing/Operations
Security infrastructure (PKI) => clusteradm not present
Response to incident quickly (why not having a security operation team) => clusteradm not present
Report
In total, there were three security-related sessions: one on each day of the summit.
Monday, August 26th
Notes taken by SofianBrabez originally in text/x-zim-wiki syntax, partly moinmoinified by DagErlingSmørgrav
Present
- pjd
- des
- sbz
- gavin
- markm
- adrian
- rwatson
- daviddrysdale
- oshogbo
- Warren Hunt
/dev/random
See /DevRandom
mitigation session (25min)
ST
Probably for 11.0
rwatson: Use randomness for ASLR in process and kernel markm : RC4 random (dedicated register) use for mititation and aslr randomness in user mode, /dev/random unblock
Recent:
FreeBSD-SA-13:06.mmap by alc
- security.bsd.unprivileged_proc_debug=1 by default
LT:
- Code (.text): [NO ASLR]
- Data (.bss): [NO ASLR] [DEP]
- Linker (loader): [NO ASLR]
- Libc: [NO ASLR]
- Heap: [NO ASLR] [DEP]
- Stack: [NO ASLR] [DEP]
- SSP: Base [OK], Port [KO], Kernel modules [OK/KO]
- kib/alc:
- email rewiew
- des: 64 bits code
- increase address space fragemenation (super pages code ?!)
- have to look, logic for a hole to fill
- have to be in security sysctl OID
- garretcooper, macos/other bsd to look at it:
- apple
mmap random => mask to use => modulus
- patches + exp run + sysctl enable (9.x, 10.x)
=> for port
- sysctl oid:
- move kern/random kern.randompid to security for 10.x
- move stackgap and mmap to security
- align size of the pointer (align byte minus 1):
- rwatson:
- use ALIGN macro
- pjd:
- mmx ?!
- des:
- align byte macro on ARM is incorrect
- rwatson:
- redzone:
- runtime check, buffer overflow, overrun
- twice allocation
Tuesday, August 27th
Whiteboard photos:
Present:
- des
- rwatson
- bz
- sbz
- jonathan
- daviddrysdale
- pjd
- oshogbo
- piete brooks
- pjg
- gavin
- erwin
DNSsec (55min)
- 10.0:
- des: want to kill BIND and replace it by ldns + unbound (or offer the possibility)
- des: need local caching resolver understanding DNSSEC because time consuming
- des about ldns:
- important ldns-host on Monday
- came from with drill program require a dig wrapper
- 90 % of compatibility of dig
- des about unbound:
- have local resolution (cache resolver and can't afford zone) + local forwarder
- files as forwarders because it's want we want for each case
- dhclient updates has to hash unbound instance for resolution because it's cached (resolv.conf to localhost)
- pjd: risky because people does resolution in jails
- rwatson: how to choose beetween localtion resolution and normal
- gavin: resolv.conf handles unbound
- service unbound states ?!
- rwatson: handle non-atomicity in rc.conf change
- openssh: SSHFP (host key fingerprint) record handle by ldns
- future:
- question about transitions ? for binary output ?
- careful to removal of nslookup
- bapt: use bind binary from ports tree version
des: library use by ldns = libval feature API => integrated as libdns in libc for 11.0 (state machine record)
- pjd: order of depends at runtime and interact with DNSSEC ?!
- des: shape root key
- bz ask:
- security problems if we link a libc that does the resolution for SSH !
- is libdns a stable API ?!
- SSH in 10.0 will use libdns and sshfp
- rwatson: linking the library statically
- Don't build libunbound at all
- ask: DNSSec use in base beyond SSH
Mitigation (no time)
Package NG signing + CA (1h)
des: libfetch in 10.0 can verify certificate, where we ship the certificate ?! bz: insane to put cert in DNSSEC record rwatson: digital signature ?! bapt: I just need to sign the metadata ?! des: you have to sign packages as well too bapt: already to be able to sign the catalog des: we have around november because pkgng is a port bapt: introduce simon bytesync python tool => we don't need to use SSH to copy thing.
pjd: LT when using mirrors compromised ? will be a problem / replace a package corrupted
Both ways are OK * easy way
- https for package distribution
to transfer the cert what about ceils ? 1) DANE 2) x509 -> root cert ?
-> distribution route -> talk w/Simon
-> require CDN with SSL
* hard way
signed package set hash -> certification but not a CA! (use per-source key fingerprint)
bapt: no feedback for improvment because no review and pcbsd already use exisiting solutions => need secteam review
-> requires review
-> really wants attribute certificate (Extension of OpenSSL) -> not in OpenSSL right now
-> OR multiple chains or multiple roots
- des: FreeBSD Foundation can pay for a root for a multiple chains ?
- bapt: verisign propose something or can provide it
- rwatson: introduce CRL to revoke package or package sets
- difference between package vs vulnerable package
- CPE in ports ?
- bapt: pkg repo does the sign of the metadata
- simon: want an unsigned catalog
- bapt: ask Juniper (sjg) what they done at Juniper
- pjd: propose having absolute path to key
- jonathan/rwatson: propose to add a include directive in pkgng configuration
future:
- we want to set a root cert for having a chains !
- freebsd-update aware !
- pjd: would like to look for revocation (CRL ?)
- des: revoke key and create a new key
rwatson: think about model before review and revoke key => revoke packages
jonathan: using pluggable for signing => signature checking
10.0 Operational TODO:
- pkg repo must submit metadata for signing, not hold keys
pjd: support people without certificate and local repository (file://, ssh://...)
- build system cool still compromise for short term (one month)
- key management
pawel or Juniper's signature source for FreeBSD -> signing service
- TODO for clusteradm:
- bapt requires HSM-LIKE service (provide by pjd implementation or sjg at juniper)
10.0 Developer TODO:
- Installer support ?
- Commit pkg keys to src
- Having in time for 10.0 release but pkgng is a port
- Review pkgng sign/validation code
Way to distribute/include key via freebsd-update -> master key to update
- Package + package set revocation
- - record hashes in db
- - how do distribute revocation list (list of hashes ?!)
Allow multiple signatures on package set -> Fingerprints (multiple) bad keys w/ expirate date
- Model dual - key model
- Clear validation strategy/algorithm
- Key definitions can contain "revocation" fingerprints with dates
- VUXML:
- - pkgng support condense and normal audit format
- TODO for clusteradm/secteam (benlaurie, jonanderson, steven, ...):
- commit pkgng keys to src
- TODO for bapt:
- pkg/set revocation
- key definitions
- allow multiple signatures
10.0 impossible things:
- 1) X509 certs
- 2) nature key management/
- 3) assume pkgng self-update post freebsd-update
- 4) HSM
Authentification (no time)
CPE (5min)
- Nomenclature used by Mitre and the NVD to identify which software packages are affected by a vulnerability
- Currently, VuXML uses the port's ${PACKAGE_NAME} and easily gets confused if a package is renamed (e.g. various Perl ports)
- If we store the CPE as metadata in the package and include it in the VuXML entry, we can use that instead
Conclusion: just start adding CPEs and worry about how to use them later.
Conclusions / Consensus:
- All SAs need regression tests
- Migration kill from BIND to LNDS + Unbound in base
- What about host, dig, nsupdate (replace old tool by ldns tool)
- "Screw it, we import unbound"
Package signing breakout session
Result Summary
We will have a short-term plan for 10.0 that isn't pretty but allows us to securely update packages and pkg infrastructure in the field (pkg signing for 10.0.jpeg).
We also need a longer-term plan that we can implement for e.g. 11 (longer term pkg signing plan.jpeg).
Notes
Current state
A package currently contains:
- - Two manifest files
- +MANIFEST - Contains full details, including hashes of each file +COMPACT_MANIFEST - File list, directory list, scripts removed
digest.txz contains:
- - Signatures of COMPACT_MANIFESTS
- - digests file is purely an optimisation.
Packagesite.txz contains:
- - packagesite.yaml
- - Contains copy of all COMPACT_MANIFEST details, including hash(pkg files)
Future changes
In the future, digest.txz and packagesite.txz should both be signed.
/usr/local/etc/pkg.conf on client should support:
- - fingerprint: ..... - include: /etc/... (this support needs to be added, and needs to support multiple includes)
- - This is to allow people to create their own fingerprint trees and include them
Signatures are RSA, created with OpenSSL
TODO for 10
/etc/pkg/keys/ - OpenSSL public keys
- Contains list of good keys Contains list of bad keys
- - pkg needs to check bad keys first!
/etc/pkg/freebsd.conf "enable: true" to enable official repo
Bootstrapping relies on:
- pkg.txz pkg.txz.sig (pkg.txz.crt) keys.txz keys.txz.sig pkg bootstrap binary in base verifies SSL signature against /etc/pkg/keys/ key
Need to record which key/certificate created each signature
Signing service needs building - clusteradm (Juniper/pjd?)
Digests need to contain (pkg, reposet, signatures, signature datestamp)
Compromised package sets notified via "pkg audit", plus security advisory etc
packagesite.txz should contain previous "bad" backage set details
packageset.txz also contains cert/signature mapping
poudriere: ports->packages->repo. Signed. (cert, sig) given to pkg update.
- pgk update:
- for each (cert, sig):
- check cert, fingerprint (with OpenSSL)
- (check /etc/pkg/fingerprints/bad, check "bad set" list)
- ..
- check cert, fingerprint (with OpenSSL)
- for each (cert, sig):
clusteradm will have key on signing server. so@ will keep copy encrypted against so@ pgp key, just in case.
TODO beyond 10.0
- - CA cert + chain - Key rotation - key distribution through pkgng
OpenSSL doesn't support attribute certificates, so we need to hack around it.
- FreeBSD CA
\--> sub -->> @FreeBSD.org S/MIME
- |
|---> freebsd-update fingerprint (handled in same way as below)
- \|/
- pkg fingerprint file (serves to break the certificate chain)
- \|/
- \|/
- cert
- \|/
- pkg set
- |
Result: FreeBSD CA only signing configuration files. Chain of trust deliberately broken via signing fingerprint files so that lower certificates are untrusted to tools that don't understand how the chain works