Differences

This shows you the differences between two versions of the page.

--- devsummit:201309:security [2013/09/26 09:55] – DagErlingSmørgrav
+++ devsummit:201309:security [2021/04/25 10:00] (current) – Move to DevSummit namespace. JethroNederhof
@@ Line 12: / Line 12: @@
 | [[/SofianBrabez|SofianBrabez]] | Mitigation |
 | %%DagErlingSm%%ørgrav | %%VuXML%% / auditing |
-| [[/UlrichSpoerlein|UlrichSpoerlein]] | Coverity Scan |
 ==== Results ====
-//(Add a list or attach slides detailing the achieved results here.)//
+{{devsummit/201309/security/201309_devsummit_security_report.pdf?linkonly|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
+.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|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.
+st 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"
+----
+{{tag>Historical}}