This is an old revision of the document!


2013-08 DevSummit Security 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
  • 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)
    • …

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

In total, there were three security-related sessions: one on each day of the summit.

Notes taken by SofianBrabez originally in text/x-zim-wiki syntax, partly moinmoinified by DagErlingSmørgrav

Present

  • pjd
  • des
  • sbz
  • gavin
  • markmurray
  • adrian
  • rwatson
  • daviddrysdale
  • ogoshbo
/dev/random session (1h30 min)

ST

des:

  • we don't change property of the ouput
  • structural changes only for 10.0

note: “structural changes” means “changes to the framework that the drivers plug into, but no deep rototilling”

LT

Hardware RNG support

  • Yarrow (WRITE, Keyboard, Mouse, NET, PURE, INTERRUPT)
  • * hash buffer encryption key
  • * timestamp class entropy
  • * Net
  • * * TSI register buffer timer; need to downgrade number of bit register ⇒ already a fix for that
  • * * bad entropy because loosing to much in input queue
  • *
  • * not identification, sufficient entropy
  • * * ⇒ pavel patchs (entropy from device attach time)
  • * * * → no feed the queue
  • * * * → always feed attach time
  • * * * → overestimated entropy for some device
  • * * ⇒ losing something by XORING ?
  • * quick hashes ?!
  • * Interrupt
  • * * software (off by default) + hardware interrupts
  • * Buffer entropy (circular)
  • * * pjd: good idea to loader responsible for generation keys (preload entropy in fs)
  • * * gavin: nextboot project ?!
  • * * markm:
  • * * * write general purpose code to bring an API for other case (process, probe temperature, crypto, ect..) (random_adaptor framework)
  • * * * feed to yarrow
  • * * * to be done at runtime
  • * * rwatson:
  • * * * dealing with ssh keys, probably identical keys in the world because of the entropy?
  • * * markm when boot and don't have good results or RNG fail :
  • * * * block (seems the solution ssh-keygen block), crap entropy/pig randomness or panic (not appropriate will be same after next reboot)
  • * * * pdj: fallback on yarrow but if non yarrow ?!
  • * * * adrian: on mips can't do pid randomness (base on arc4random())
  • * * * rc4 vs /dev/random
  • Embedded
  • * adrian come up with embedded problem (time attach is low on his board), boot part ?!
  • * des background noise on wireless device/stack
  • * markm kill the input queue
  • * rwatson think we need to focus on desktop and servers to provide good documentation and good pratices by default, provide guidance and clearance
  • *
  • Yarrow vs Fortuna
  • * Y:256 bit hashes into fast and slow buffer, value as a key for encryption function (PRNG + hardware device to change the seed) + 2 pool
  • * F: 32 pool each event seperatly and evenlty spread each pool from source + bitmaps counter, advantage: counter mode
  • * * rwatson: queue per cpu core
  • david miles hash ?!
  • rwatson: sson did FIPS tests for Apple and MacOS
  • rwatson: multi socket ?! cpu socket ?! will be a problem high thread…
  • pjd: Yarrow limited to one CPU ⇒ don't scale because of the LOCK
  • * reading scalable ⇒ feed directly to the pool and not use queue
  • * XORING doesn't loose entropy
  • markm: we need to do the hash in pool !
  • sbz: test diehards
  • des: test vritual machine (vbox)

Schema ⇒ take picture

HW: rvy.c + nehemiah.c boot: sysctl yarrow: device driver

Schema propose by pjd

  • proxy mixer component which take entropy from real rand device and network?

Conclusion

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, DevSummit/201308/Security/dev/random unblock

Recent:

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
  • redzone:
  • * runtime check, buffer overflow, overrun
  • * twice allocation

IMG_20130827_115405.jpg IMG_20130827_115646.jpg IMG_20130827_115708.jpg

  • devsummit/201308/security.1377682082.txt.gz
  • Last modified: 2013/08/28 09:28
  • by DagErlingSmørgrav