Security
Entropy with NeuG
At LinuxCon Japan 2015, Yutaka Niibe presented [PDF] his work on NeuG, a true random-number generator (TRNG) built entirely with free software and which can run on a variety of cheap hardware devices. There are several competing free-software TRNG options on the market these days; NeuG may not generate the fastest stream of random numbers, but it is notable for its flexible hardware support and its simplicity.
Niibe began the session with a brief autobiographical sketch. He has been a long-time GnuPG developer, with much of his work focusing on libgcrypt. Several years ago, he began working on a GnuPG smartcard implementation called Gnuk. The Gnuk project involved designing and building a secure hardware token that he dubbed the FST-01. Along the way, he said, he became convinced that users were in need of a hardware TRNG.
The issue, of course, is that cryptography requires good keys and generating good keys require random numbers. Interest in the subject is on the increase, he said, with projects like the Free Software Foundation's (FSF's) Email Self Defense and the Electronic Frontier Foundation's (EFF's) HTTPS Everywhere but, he reminded the audience, GnuPG is a fundamental part of free-software distribution, too, providing signatures for releases, commits, and packages.
Given the importance of the topic, hardware TRNGs are vital because users have to trust the hardware in order to trust their encryption keys. There may be backdoors in algorithms, he noted, but there may also be backdoors in hardware—as has been alleged about Intel's RDRAND instruction or in cryptographic chips. So he decided to buck the recent trend of building more powerful embedded devices, and set out to develop a TRNG that uses a cheap, general-purpose microcontroller rather than any specialty hardware.
NeuG is the result. The primary focus has been on implementing NeuG as an alternate firmware for the FST-01, he said, but it will run on several other devices. At the moment, there are five, all of which use the STM32F103 microcontroller found on the FST-01. The microcontroller features an ARM Cortex-M3 core running at 72MHz and has full-speed USB 2.0 connectivity. The various boards include between 20 and 64KiB of RAM and between 64 and 512KiB of flash ROM.
The cheapest option is the ST-Link debugger board that ships with ST's STM8S-DISCOVERY kit; it can be had online for less than ten dollars. The FST-01 remains the reference design, though. It includes 20KiB of RAM, 128KiB of ROM, a 12MHz crystal, a status LED, and some additional flash memory. The schematics and circuit-board designs are free as well.
When connected to a Linux PC, the FST-01 appears as /dev/ttyACM0 (or whatever /dev/ttyACM device is available) and also presents a small USB mass-storage device holding a copy of the GPLv3 license and a README file for using the software. The random-number generation works by sampling the microcontroller's two built-in analog-to-digital converters (ADCs). One ADC samples the microcontroller's reference voltage pin and built-in temperature sensor, while the other is tied to two of the microcontroller's analog input pins (both of which are pulled up to the power supply pin). These four signal sources are sampled in various combinations, passed through four rounds of CRC32, then passed through a SHA-256 conditioning function.
The output, Niibe said, is about 256 bits of entropy from every 280 bits sampled. The FST-01 produces around 80KB of entropy per second in this fashion. The NIST SP 800-90B standard defines the conditioning requirements needed to remove sampling bias, he said, and it defines three health checks that one can use to test the quality of the output. The NeuG software includes a Python program to test the device's output, he said, "but if you don't trust me, you can test it with external tools, too." He recommended TestU01 and PractRand, though he cautioned that they can require extremely large data sets for proper analysis.
Normally, he continued, the device is used with the kernel's rng-tools; the NeuG software bundle includes a udev rule and systemd service to feed output into the kernel's entropy pool. But it can be sampled directly, too, with raw samples, CRC32-filtered bits, and fully SHA-256–conditioned output all available. Altogether, the NeuG library is quite compact: the version that ships on the FST-01 is just 1,500 lines of code, including the USB stack, the USB communications device class (CDC) and mass-storage drivers, and a small thread library called Chopstx.
Regarding the performance of the TRNG design, Niibe admitted that many electrical engineers prefer to talk about other, more esoteric entropy sources like avalanche diodes, photon decay, and radio waves. They sound better, he said, but such exotic sources are not usually needed in practice. People also ask him whether NeuG offers any advantage over haveged, to which he replies that haveged may be good enough for many people on its own, but that it is always better to have multiple, independent entropy sources.
An audience member asked how much entropy a system needs. Niibe replied that some people go overboard, but in his opinion it is best to think of entropy like spice. "Don't drink your soy sauce," he said to a collective chuckle from the crowd, "just use a little wasabi if you want to enjoy your sushi."
Others in attendance asked about the use of the microcontroller at the core of the project. Could the code be ported to other microcontrollers, perhaps? And is there any protection against hardware trojans in the microcontroller itself? Niibe replied that the code is quite portable, and could probably be ported to a variety of other microcontrollers if someone is interested.
As for the possibility of hardware trojans, he said that the risk of compromised hardware was the reason he chose a modest, general-purpose part, adding "although now that I've given this talk, I guess the bad guys will start attacking it." But the STM32F103 has been around for eight years or so, he said, so if users are really paranoid, they should just go buy one now (or even try to find an old one) before the spies get to them. He is also occasionally asked why the NeuG uses a TTY with no encryption to deliver its data, he said. His response is that he could implement USB-channel encryption, but he does not think it makes sense to encrypt your USB bus. If the NSA is snooping your internal USB traffic, he said, "I think you're already finished."
Niibe ended the session with a few "further reading" recommendations for those interested in random-number generation. In summary, he said that free software is about controlling one's own computing. Where encryption is concerned, we need something at the center to serve as the anchor point. No one can control the random number sequence, he said, so he would like to see more people use hardware TRNGs, whether they buy one of his or another.
The most direct comparison to NeuG might be Moonbase Otago's OneRNG, which we looked at in January. Both are open hardware in addition to running free software. The OneRNG uses an avalanche diode as its entropy source and its bit rate is estimated at 350Kbps. So users have some decisions to make if they are interested in choosing one or the other—the NeuG may not produce as much entropy, but it may produce enough for daily usage. On the other hand, the OneRNG is a recent Kickstarter product: although shipments have begun, there is only one source for the hardware, as opposed to the five different boards supported by NeuG. Regardless of how those factors weigh out, however, it is good to have multiple options—and options that take substantially different approaches to the problem of random-number generation.
[The author would like to thank the Linux Foundation for travel assistance to attend LCJ 2015.]
Brief items
Security quotes of the week
Let's Encrypt Root and Intermediate Certificates
The Let's Encrypt project has announced that it has created the root and intermediate keys and certificates it will use to sign certificates. Let's Encrypt is the no-cost certificate authority announced by the Electronic Frontier Foundation (EFF) back in November. In April, the Linux Foundation announced that it would be hosting the project. "The keys and certificates that will underlie Let’s Encrypt have been generated. This was done during a key ceremony at a secure facility today." The intermediate certificates will be cross-signed by IdenTrust so that they will be accepted by browsers before the Let's Encrypt root certificate has been propagated. A bit more news from the blog post: "
In the next few weeks, we’ll be saying some more about our plans for going live."
New vulnerabilities
abrt: multiple vulnerabilities
| Package(s): | abrt | CVE #(s): | CVE-2015-1869 CVE-2015-1870 CVE-2015-3142 CVE-2015-3147 CVE-2015-3150 CVE-2015-3151 CVE-2015-3159 CVE-2015-3315 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | June 10, 2015 | Updated: | July 8, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Red Hat advisory:
It was found that ABRT was vulnerable to multiple race condition and symbolic link flaws. A local attacker could use these flaws to potentially escalate their privileges on the system. (CVE-2015-3315) It was discovered that the kernel-invoked coredump processor provided by ABRT wrote core dumps to files owned by other system users. This could result in information disclosure if an application crashed while its current directory was a directory writable to by other users (such as /tmp). (CVE-2015-3142) It was discovered that the default event handling scripts installed by ABRT did not handle symbolic links correctly. A local attacker with write access to an ABRT problem directory could use this flaw to escalate their privileges. (CVE-2015-1869) It was found that the ABRT event scripts created a user-readable copy of an sosreport file in ABRT problem directories, and included excerpts of /var/log/messages selected by the user-controlled process name, leading to an information disclosure. (CVE-2015-1870) It was discovered that, when moving problem reports between certain directories, abrt-handle-upload did not verify that the new problem directory had appropriate permissions and did not contain symbolic links. An attacker able to create a crafted problem report could use this flaw to expose other parts of ABRT to attack, or to overwrite arbitrary files on the system. (CVE-2015-3147) Multiple directory traversal flaws were found in the abrt-dbus D-Bus service. A local attacker could use these flaws to read and write arbitrary files as the root user. (CVE-2015-3151) It was discovered that the abrt-dbus D-Bus service did not properly check the validity of the problem directory argument in the ChownProblemDir, DeleteElement, and DeleteProblem methods. A local attacker could use this flaw to take ownership of arbitrary files and directories, or to delete files and directories as the root user. (CVE-2015-3150) It was discovered that the abrt-action-install-debuginfo-to-abrt-cache helper program did not properly filter the process environment before invoking abrt-action-install-debuginfo. A local attacker could use this flaw to escalate their privileges on the system. (CVE-2015-3159) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
cups: two vulnerabilities
| Package(s): | cups | CVE #(s): | CVE-2015-1158 CVE-2015-1159 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | June 9, 2015 | Updated: | November 2, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Debian LTS advisory:
CVE-2015-1158 - Improper Update of Reference Count This bug is exploitable in default configurations, and does not require any special permissions other than the basic ability to print.
CVE-2015-1159 - Cross-Site Scripting | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
jackrabbit: information leak
| Package(s): | jackrabbit | CVE #(s): | CVE-2015-1833 | ||||||||
| Created: | June 9, 2015 | Updated: | July 1, 2015 | ||||||||
| Description: | From the CVE entry:
XML external entity (XXE) vulnerability in Apache Jackrabbit before 2.0.6, 2.2.x before 2.2.14, 2.4.x before 2.4.6, 2.6.x before 2.6.6, 2.8.x before 2.8.1, and 2.10.x before 2.10.1 allows remote attackers to read arbitrary files and send requests to intranet servers via a crafted WebDAV request. | ||||||||||
| Alerts: |
| ||||||||||
libapache-mod-jk: information disclosure
| Package(s): | libapache-mod-jk | CVE #(s): | CVE-2014-8111 | ||||||||||||
| Created: | June 4, 2015 | Updated: | July 1, 2015 | ||||||||||||
| Description: | From the Debian advisory:
An information disclosure flaw due to incorrect JkMount/JkUnmount directives processing was found in the Apache 2 module mod_jk to forward requests from the Apache web server to Tomcat. A JkUnmount rule for a subtree of a previous JkMount rule could be ignored. This could allow a remote attacker to potentially access a private artifact in a tree that would otherwise not be accessible to them. | ||||||||||||||
| Alerts: |
| ||||||||||||||
mbedtls: code execution
| Package(s): | mbedtls | CVE #(s): | |||||||||||||
| Created: | June 9, 2015 | Updated: | June 19, 2015 | ||||||||||||
| Description: | From the mbed TLS 1.3.11 release announcement:
Handling of the SSL_VERIFY_OPTIONAL authmode was changed to make sure that information about keyUsage and extendedKeyUsage was properly propagated and accessible to the calling function. Just as a reminder, SSL_VERIFY_REQUIRED is the recommended security setting for authmode. A team of security researchers dove back into the Lucky 13 issue and found potential weaknesses in SSL implementations when the attacker can execute code on the same physical machine. mbed TLS was modified to always generate a cache miss and make sure that attackers gain no information from that event. | ||||||||||||||
| Alerts: |
| ||||||||||||||
pcre: code execution
| Package(s): | pcre | CVE #(s): | CVE-2015-3210 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | June 5, 2015 | Updated: | November 25, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Arch Linux advisory:
Several buffer overflows have been found in pcre <= 8.37. By compiling a crafted regular expression, it is possible to write more than the expected size into various buffers, allowing arbitrary code execution. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
pcs: access restriction bypass
| Package(s): | pcs | CVE #(s): | CVE-2015-3983 | ||||||||||||
| Created: | June 5, 2015 | Updated: | June 10, 2015 | ||||||||||||
| Description: | From the Red Hat bugzilla entry:
It was found that the pcs daemon did not sign cookies containing session data that were sent to clients connecting via the pcsd web UI. A remote attacker could use this flaw to forge cookies and bypass authorization checks, possibly gaining elevated privileges in the pcsd web UI. | ||||||||||||||
| Alerts: |
| ||||||||||||||
python-tornado: side-channel attack
| Package(s): | python-tornado | CVE #(s): | CVE-2014-9720 | ||||||||||||||||||||||||
| Created: | June 9, 2015 | Updated: | May 16, 2016 | ||||||||||||||||||||||||
| Description: | From the Tornado 3.2.2 release announcement:
The XSRF token is now encoded with a random mask on each request. This makes it safe to include in compressed pages without being vulnerable to the BREACH attack. This applies to most applications that use both the xsrf_cookies and gzip options (or have gzip applied by a proxy). | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
qemu: multiple vulnerabilities
| Package(s): | qemu, qemu-kvm | CVE #(s): | CVE-2015-3209 CVE-2015-4037 CVE-2015-4103 CVE-2015-4104 CVE-2015-4105 CVE-2015-4106 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | June 10, 2015 | Updated: | September 10, 2015 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Ubuntu advisory:
Matt Tait discovered that QEMU incorrectly handled the virtual PCNET driver. A malicious guest could use this issue to cause a denial of service, or possibly execute arbitrary code on the host as the user running the QEMU process. In the default installation, when QEMU is used with libvirt, attackers would be isolated by the libvirt AppArmor profile. (CVE-2015-3209) Kurt Seifried discovered that QEMU incorrectly handled certain temporary files. A local attacker could use this issue to cause a denial of service. (CVE-2015-4037) Jan Beulich discovered that the QEMU Xen code incorrectly restricted write access to the host MSI message data field. A malicious guest could use this issue to cause a denial of service. This issue only applied to Ubuntu 14.04 LTS, Ubuntu 14.10 and Ubuntu 15.04. (CVE-2015-4103) Jan Beulich discovered that the QEMU Xen code incorrectly restricted access to the PCI MSI mask bits. A malicious guest could use this issue to cause a denial of service. This issue only applied to Ubuntu 14.04 LTS, Ubuntu 14.10 and Ubuntu 15.04. (CVE-2015-4104) Jan Beulich discovered that the QEMU Xen code incorrectly handled MSI-X error messages. A malicious guest could use this issue to cause a denial of service. This issue only applied to Ubuntu 14.04 LTS, Ubuntu 14.10 and Ubuntu 15.04. (CVE-2015-4105) Jan Beulich discovered that the QEMU Xen code incorrectly restricted write access to the PCI config space. A malicious guest could use this issue to cause a denial of service, obtain sensitive information, or possibly execute arbitrary code. This issue only applied to Ubuntu 14.04 LTS, Ubuntu 14.10 and Ubuntu 15.04. (CVE-2015-4106) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
rabbitmq-server: multiple vulnerabilities
| Package(s): | rabbitmq-server | CVE #(s): | CVE-2014-9649 CVE-2014-9650 CVE-2015-0862 | ||||||||||||||||||||
| Created: | June 9, 2015 | Updated: | March 9, 2016 | ||||||||||||||||||||
| Description: | From the CVE entries:
Cross-site scripting (XSS) vulnerability in the management plugin in RabbitMQ 2.1.0 through 3.4.x before 3.4.1 allows remote attackers to inject arbitrary web script or HTML via the path info to api/, which is not properly handled in an error message. (CVE-2014-9649) CRLF injection vulnerability in the management plugin in RabbitMQ 2.1.0 through 3.4.x before 3.4.1 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via the download parameter to api/definitions. (CVE-2014-9650) Multiple cross-site scripting (XSS) vulnerabilities in the management web UI in the RabbitMQ management plugin before 3.4.3 allow remote authenticated users to inject arbitrary web script or HTML via (1) message details when a message is unqueued, such as headers or arguments; (2) policy names, which are not properly handled when viewing policies; (3) details for AMQP network clients, such as the version; allow remote authenticated administrators to inject arbitrary web script or HTML via (4) user names, (5) the cluster name; or allow RabbitMQ cluster administrators to (6) modify unspecified content. (CVE-2015-0862) | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
redis: code execution
| Package(s): | redis | CVE #(s): | CVE-2015-4335 | ||||||||||||||||||||||||||||
| Created: | June 8, 2015 | Updated: | October 6, 2015 | ||||||||||||||||||||||||||||
| Description: | From the Debian advisory:
It was discovered that redis, a persistent key-value database, could execute insecure Lua bytecode by way of the EVAL command. This could allow remote attackers to break out of the Lua sandbox and execute arbitrary code. | ||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||
strongswan: information disclosure
| Package(s): | strongswan | CVE #(s): | CVE-2015-4171 | ||||||||||||||||
| Created: | June 8, 2015 | Updated: | June 18, 2015 | ||||||||||||||||
| Description: | From the Debian advisory:
When an IKEv2 client authenticates the server with certificates and the client authenticates itself to the server using pre-shared key or EAP, the constraints on the server certificate are only enforced by the client after all authentication steps are completed successfully. A rogue server which can authenticate using a valid certificate issued by any CA trusted by the client could trick the user into continuing the authentication, revealing the username and password digest (for EAP) or even the cleartext password (if EAP-GTC is accepted). | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
thermostat1: code execution
| Package(s): | thermostat1 | CVE #(s): | CVE-2015-3201 | ||||||||||||
| Created: | June 4, 2015 | Updated: | June 11, 2015 | ||||||||||||
| Description: | From the Red Hat advisory:
It was discovered that the Thermostat web application stored database authentication credentials in a world-readable configuration file. A local user on a system running the Thermostat web application could use this flaw to access and modify monitored JVM data, or perform actions on connected JVMs. (CVE-2015-3201) | ||||||||||||||
| Alerts: |
| ||||||||||||||
zarafa: file overwrites
| Package(s): | zarafa | CVE #(s): | CVE-2015-3436 | ||||||||
| Created: | June 8, 2015 | Updated: | June 10, 2015 | ||||||||
| Description: | From the Red Hat bugzilla:
Guido Günther detected and reported that replacing "/tmp/zarafa-upgrade-lock" by a symlink makes the zarafa-server process following that symlink and thus allows to overwrite arbitrary files in the filesystem (assuming zarafa-server runs as root which is not case by default at Fedora, but upstream default). One just needs write permissions in /tmp and wait until the zarafa-server is restarted. | ||||||||||
| Alerts: |
| ||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>
