https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&target=201309+DevSummit+Security+Report.pdf
https://wiki.freebsd.org/201309DevSummit/Security In the security working group, we had four items in the agenda. First of all, we started with the current state of /dev/random. There were a number of known entropy harvesting bugs that have been fixed, for example feeding a lot of zeroes from the network stack. We have a pluggable random generator framework and we have a number of plugins for it, Yarrow is one, and the RDRAND, Padlock are two others, we have one that blocks and one that panics, and few coding examples and so on. For 10, we are going to backtrack and remove RDRAND and Padlock backends and feed them into Yarrow instead of delivering their output directly to /dev/random. It will still be possible to access hardware random number generators, that is, RDRAND, Padlock etc., directly by inline assembly or by using OpenSSL from userland, if required, but we cannot trust them any more. In addition to this, we want to collect more entropy early in the boot process, because we want to get rid of the initrandom script that feeds mostly static data into /dev/random and pretends that is actually entropy, when it is not. Pawel Jakub Dawidek has a patch which has been floating around and doing some analysis on this, we finally got some numbers for it. This patch feeds the amount of time it takes to attach a device into /dev/random and it turns out that one can get about 4 good bits of entropy from each device. Also, we should have the installer fill up the /entropy file on the newly installed system, so we have something when the system starts up for the first time. And there is also the matter of (especially with virtualization and cloning, which is becoming more and more common) ensuring that the clones diverge quickly enough. As an example, we discussed having the installer generate SSH keys. But a problem is that if you install a VM and it generates the SSH keys, and then it is cloned, all the instances will have the same keys. So when the individual VMs are started and they do not have enough entropy harvesting early in the boot process, then keys are generated based on the entropy that the installer has dumped during the installation process, which is as almost as bad. The device attach patch helps with that. The next item was package signing. We have a short-term solution for 10 until a more professional one is developed. In this design, the package builders do not have the keys, instead they submit hashes to a signing server after they are done, and the signing server returns the signature. We are simply going to ship the fingerprints with the base system under /etc/pkg/fingerprints. If we need to revoke a key, or distribute a new key, we will just issue a new FreeBSD Security Advisory (which should be done anyway), and will have freebsd-update(8) distribute an update that moves the key from the trusted directory to the revoked directory and adds the new key to the trusted directory. When launched, pkg(8) looks into those directories, loads all the keys it finds, and will accept a packages if it is signed by at least one good key and no revoked keys. Package signing was followed by mitigation by Sofian Brabez. He has stackgap optimization and mmap() randomization ready to be included in 10, but turned off by default. Stackgap randomization adds a random amount of empty space at the top of the stack, so that an attacker cannot just make assumptions about the actual stack layout of the applications in case of buffer overflows. The problem with stackgap randomization is programs like Varnish, that have many threads and therefore very small stacks in order to avoid running out of stack space, will run out of stack space. This is because stackgap randomization will increase the size of the stacks. mmap() randomization inserts a random gap between consecutive mappings for the same purpose. Stack protection (SSP) can now be enabled by default. The problem is if it is turned on by default, a lot of ports will break. It is because GCC includes an additional object file during linking for checking the canary words, and this apparently interferences the way some ports build. libc is now a linker script and not just a .so file, therefore the linker will always know how to handle this. ldbase randomization was also discussed, but it has not been implemented. It randomizes where the libraries are loaded by the run-time linker. The final item on the agenda was VuXML and portaudit. We have a number of shortcomings with VuXML. One of them is that the portaudit tool is based on string matching which is unreliable, especially when we have ports that are renamed and multiple ports, different versions of the same software. In addition, there are many errors in the actual data, especially a very common error is to have > instead of >=. Also, the auditing tools do not verify the base system version. We have VuXML entries for Security Advisories but they are unused because of this. One of the reasons for that is that the kernel patch level does not necessarily reflect the patch level of the userland, because freebsd-update(8) does not update the kernel patch level unless the actual update affects the kernel. So we are going to start including CPE information in ports. That is the Common Platform Enumeration, and that is a NIST standard for uniquely identifying software packages, versions, variances, even port revisions. The point of using CPEs is that it is unique, not tied to the name of the port so we can have multiple ports with the same CPE without any trouble. We will store it as annotations for pkg(8) packages. CPEs published by NIST can be simply pushed directly to VuXML and we do not have to do the matching ourselves any more. The specification of CPE includes a matching algorithm and is shipped with a reference implementation. FreeBSD 10 is going to install a script under /libexec that prints the userland patch level, and freebsd-update(8) will update that script so it will be possible to verify the userland patch level as well. ======================================================================= “We cannot trust” Intel and Via’s chip-based crypto, FreeBSD developers say Following NSA leaks from Snowden, engineers lose faith in hardware randomness. Developers of the FreeBSD operating system will no longer allow users to trust processors manufactured by Intel and Via Technologies as the sole source of random numbers needed to generate cryptographic keys that can't easily be cracked by government spies and other adversaries. The change, which will be effective in the upcoming FreeBSD version 10.0, comes three months after secret documents leaked by former National Security Agency (NSA) subcontractor Edward Snowden said the US spy agency was able to decode vast swaths of the Internet's encrypted traffic. Among other ways, The New York Times, Pro Publica, and The Guardian reported in September, the NSA and its British counterpart defeat encryption technologies by working with chipmakers to insert backdoors, or cryptographic weaknesses, in their products. The revelations are having a direct effect on the way FreeBSD will use hardware-based random number generators to seed the data used to ensure cryptographic systems can't be easily broken by adversaries. Specifically, "RDRAND" and "Padlock"—RNGs provided by Intel and Via respectively—will no longer be the sources FreeBSD uses to directly feed random numbers into the /dev/random engine used to generate random data in Unix-based operating systems. Instead, it will be possible to use the pseudo random output of RDRAND and Padlock to seed /dev/random only after it has passed through a separate RNG algorithm known as "Yarrow." Yarrow, in turn, will add further entropy to the data to ensure intentional backdoors, or unpatched weaknesses, in the hardware generators can't be used by adversaries to predict their output. "For 10, we are going to backtrack and remove RDRAND and Padlock backends and feed them into Yarrow instead of delivering their output directly to /dev/random," FreeBSD developers said. "It will still be possible to access hardware random number generators, that is, RDRAND, Padlock etc., directly by inline assembly or by using OpenSSL from userland, if required, but we cannot trust them any more." In separate meeting minutes, developers specifically invoked Snowden's name when discussing the change. "Edward Snowdon [sic] -- v. high probability of backdoors in some (HW) RNGs," the notes read, referring to hardware RNGs. Then, alluding to the Dual EC_DRBG RNG forged by the National Institute of Standards and Technology and said to contain an NSA-engineered backdoor, the notes read: "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." RNGs are one of the most important ingredients in any secure cryptographic system. They are akin to the dice shakers used in board games that ensure the full range of randomness is contained in each roll. If adversaries can reduce the amount of entropy an RNG produces or devise a way to predict some of its output, they can frequently devise ways to crack the keys needed to decrypt an otherwise unreadable message. A weakness in the /dev/random engine found in Google's Android operating system, for instance, was the root cause of a critical exploit that recently allowed thieves to pilfer bitcoins out of a user's digital wallet. RDRAND is the source of random data provided by Ivy Bridge and later versions of Intel processors. Padlock seeds random data in chips made by Via. While the FreeBSD developers discussing the change cited allegations of backdoors raised in documents leaked by Snowden, the move would have been a good idea even if those weaknesses never came to light. Adding additional sources of randomness to RDRAND, Padlock, and other RNGs will not reduce their entropy and may make the keys they help generate harder to crack. Relying on multiple sources of randomness is a good practice and possibly could have helped prevent recently discovered crippling weaknesses in Taiwan's secure digital ID system. _______________________________________________ Open https://lists.partito-pirata.it/cgi-bin/mailman/listinfo/open
