User: Password:
|
|
Subscribe / Log in / New account

Security

Adding CPU randomness to the entropy pool

By Jake Edge
February 19, 2014

Kernel developers, or at least the maintainers of the random subsystem, are always on the lookout for sources of unpredictability for use in the random number pool. In particular, there are a number of scenarios where good random numbers are needed and the available pool is lacking in quality—embedded systems, early in the boot process, virtual machines, etc.—so new sources that can alleviate the problem are generally welcome. However, there is always the question of how much entropy is truly provided by these sources, which is a difficult problem to solve. Two recent patches would contribute unpredictable sources, but take a different approaches with regard to adding to the store of entropy.

The kernel has two separate interfaces for random number generation: /dev/random and /dev/urandom. They are supposed to be used for different purposes, with /dev/random only providing as many bits of randomness as bits of entropy have been added to the pool—blocking if insufficient entropy is available. It is meant to be used for long-lived keys (e.g. the SSH key for the system), while /dev/urandom provides cryptographic-strength pseudo-random numbers without the entropy requirement (and, thus, no blocking). Data read from either device comes from the same pool, but the entropy requirement is only applied for reads from /dev/random.

Unpredictable events measured by the kernel (that cannot be observed by an adversary) make up the input to the entropy pool from which the random numbers are generated. Various kinds of interrupts are used (e.g. intra-key timing from the keyboard, sometimes disk or network device intra-interrupt timing, and so on) and their values are mixed into the pool. As that is done, an estimate of how many bits of entropy are being contributed is added to the entropy count. That estimate is hopefully conservative enough that it underestimates the amount of true entropy in the pool, while trying not to make it impossible to generate a reasonable number of random bits in a reasonable time.

An even more conservative approach would be to add unpredictable data to the pool without crediting any entropy. That is already done with some sources in today's kernel, such as when adding unpredictable device-specific data using add_device_randomness(). There is value in adding "zero credit" (i.e. no entropy contributed) unpredictability to the pool. Any data that is added perturbs the state of the pool, which will change the values produced by /dev/urandom. In some situations, the same random numbers would be produced boot after boot if there were no unpredictable data added.

CPU randomness

"Zero credit" is the approach Jörn Engel took with his CPU randomness patch. It mixes uninitialized stack values with unpredictable values like jiffies into its own pool, then mixes that pool into the normal entropy pool periodically. It clearly adds unpredictability into the pool, but how much entropy it provides is hard or impossible to determine, so Engel gives it no entropy credit.

The patch gathers its info from two kernel locations: the scheduler and the slab allocator. It uses an uninitialized four-element array (input) on the stack and XORs various values into it to produce the input to the private pool. The values used are jiffies, the value of the time stamp counter (TSC), the address where the scheduler and allocator functions will return, a value specific to that invocation of the scheduler or allocator, and the address of the input array itself. It is similar in some ways to the gathering that is done for interrupts for the global pool. This collection and mixing is done quite frequently (whenever need_resched() or __do_kmalloc() are called), then the private pool is combined with normal pool at most once per second.

Perhaps surprisingly, Engel's tests showed no measurable impact on kernel performance. For the private pool, he is using a custom mixing algorithm that is faster than fast_mix() that is used on the global pool, but provides worse mixing. The normal path is used when mixing the private pool into the global.

Engel's focus is on "generating high-quality randomness as soon as possible and with low cost to the system". In particular, he is targeting embedded systems:

But on embedded systems with less modern CPUs, few interrupt sources, no user interface, etc. you may have trouble collecting enough randomness or doing it soon enough. That is the problem worth fixing.

While the values being used seem unpredictable, Ted Ts'o questioned whether an "attacker with deep knowledge of how the kernel was compiled and what memory allocations get done during the boot sequence" would be able to successfully predict some of the values. For many kernel deployments (e.g. distribution kernels), an attacker will be able to get that deep knowledge fairly easily. Ts'o thought Engel's approach had promise for improving the /dev/urandom output, but agreed with the approach of not crediting entropy (thus not affecting how much data is available from /dev/random).

CPU jitter

Another approach was suggested by Stephan Müller in his CPU Jitter random number generator (RNG) patch set. It was met with more skepticism, at least partly because it does add to the entropy count. Ts'o and others are not convinced that sufficiently knowledgeable attackers couldn't predict the output. Müller's reliance on statistical techniques in his paper to measure the entropy pool and RNG output is also a cause for some skepticism. But, according to Müller, the statistical measures are just a "necessary baseline" before he gets into "measuring the actual noise coming out of the noise sources".

Müller's method is to measure the jitter in the amount of time it takes the CPU to perform a set of operations. When entropy is needed, the driver repeatedly runs two "noise sources": a memory accessing routine that "will add to the timing variations due to an unknown amount of CPU wait states added when accessing memory" and a timestamp folding operation that is "deliberately inefficient", which requires the function to be built with no optimization (-O0). The folding operation turns a 64-bit timestamp into one bit that is XORed into the driver's entropy pool. The jitter in the timing of those two operations is also mixed into that entropy pool one bit at a time. Once the required entropy is available, random numbers derived from that are returned.

While the timing is unpredictable, due to a number of the factors Müller cites in his paper and patchset, it still amounts to a pseudo-random number generator (PRNG), according to H. Peter Anvin:

The more modern and high performance a design you have the more sources of unpredictability there are. However, there are very few, if any, (unintentional) sources of actual quantum noise in a synchronous CPU, which means that this is at its core a PRNG albeit with a large and rather obfuscated state space.

He goes on to say that independent clocks in a system would provide a source of quantum noise that could potentially be used to increase the entropy count, but that such clocks are rare on today's systems as clocks are typically slaved from the same source using phase-locked loops to keep them synchronized. Thus, using jitter (or Engel's CPU randomness) for mixing into the pool is reasonable, Anvin continued, but not for entropy credit:

As mentioned, I definitely have no objection to these sort of things as zero-credit entropy sources -- they cannot, by definition, do harm, unless they somehow cancel other inputs out -- but the notion of making them creditable sources makes me skeptical in the extreme.

It would be nice to assume that since there is no discernible pattern to the output, there must be an underlying entropy-adding event at play. But that is not enough for Ts'o, Anvin, and others to be convinced. Back in October, when the CPU Jitter RNG was first introduced, Ts'o replied at length to the patch and explained the problem he saw:

It may be that there is some very complex state which is hidden inside the the CPU execution pipeline, the L1 cache, etc., etc. But just because *you* can't figure it out, and just because *I* can't figure it out doesn't mean that it is ipso facto something which a really bright NSA analyst working in Fort Meade can't figure out. (Or heck, a really clever Intel engineer who has full visibility into the internal design of an Intel CPU....)

He also went on to describe ways that Müller could convince him that there is real random noise being generated:

So if you want to really convince the world that CPU jitter is random, it's not enough to claim that it you can't see a pattern. What you need to do is to remove all possible sources of the uncertainty, and show that there is still no [discernible] pattern after you do things like (a) run in kernel space, on an otherwise [quiescent] computer, (b) disable interrupts, so that any uncertainty can't be coming from interrupts, etc., Try to rule it all out, and then see if you still get uncertainty.

If you think it is from DRAM timing, first try accessing the same memory location in kernel code with the interrupts off, over and over again, so that the memory is pinned into L1 cache. You should be able to get consistent results. If you can, then if you then try to read from DRAM with the L1 and L2 caches disabled, and with interrupts turned off, etc, and see if you get consistent results or inconsistent results. If you get consistent results in both cases, then your hypothesis is disproven. If you get consistent results with the memory pinned in L1 cache, and inconsistent results when the L1 and L2 cache are disabled, then maybe the timing of DRAM reads really are introducing entropy. But the point is you need to test each part of the system in isolation, so you can point at a specific part of the system and say, *that*'s where at least some uncertainty which an adversary can not reverse engineer, and here is the physical process from which the [chaotic] air patterns, or quantum effects, etc., which is hypothesized to cause the uncertainty.

Müller has done most or all of the testing Ts'o suggested as reported in his paper. The results seem to bear out some kind of random noise in both the memory access and folding operations. But Anvin's opinion that the jitter in modern CPUs just represents a complicated PRNG space seems to have held the day. Perhaps a further look at the testing results is in order.

The reliance of the jitter RNG on a high-resolution timer makes it unsuitable for Engel's embedded use case (as some of those systems lack such a timer), so it's not at all clear where things go from here. Ts'o is not opposed to adding something as a zero-entropy source to try to get better /dev/urandom numbers earlier in the boot. Since Engel's solution is both simpler and does not rely on a high-resolution timer, it may well get the nod.

Comments (5 posted)

Brief items

Security quotes of the week

In other words, because of pesky things like the Constitution in the United States and instead of just using existing, vast international resources to prosecute criminals and terrorists, we're going to be expanding broken ISP filters against the advice of pretty much everybody. Granted what is deemed "extremist" will likely be entirely arbitrary, and as we've seen with the porn filters, there's probably no limit to the number of entirely legal and legitimate websites UK citizens will find suddenly inaccessible.
Karl Bode on expansion of the UK's "porn" filters

Billy Rios, director of threat intelligence at Qualys, here [Kaspersky Security Analyst Summit] today said he and colleague Terry McCorkle purchased a secondhand Rapiscan 522 B X-ray system via eBay and found several blatant security weaknesses that leave the equipment vulnerable to abuse: It runs on the outdated Windows 98 operating system, stores user credentials in plain text, and includes a feature called Threat Image Projection used to train screeners by injecting .bmp images of contraband, such as a gun or knife, into a passenger carry-on in order to test the screener's reaction during training sessions. The weak logins could allow a bad guy to project phony images on the X-ray display.
Kelly Jackson Higgins in Dark Reading on vulnerabilities found in carry-on baggage screening devices

While much of the NSA's capabilities to locate someone in the real world by their network activity piggy-backs on corporate surveillance capabilities, there's a critical difference: False positives are much more expensive. If Google or Facebook get a physical location wrong, they show someone an ad for a restaurant they're nowhere near. If the NSA gets a physical location wrong, they call a drone strike on innocent people.
Bruce Schneier

Comments (7 posted)

Introducing ClamAV community signatures

ClamAV has announced a new "community signatures" program to gather signatures of new malware for use in the ClamAV anti-virus scanner. Malware submissions can be made to <http://www.clamav.net/lang/en/sendvirus/submit-malware/>, but signatures can be emailed:

If you would like to submit a ClamAV signature, you may do so by emailing community-sigs [at] lists [dot] clamav [dot] net. We will require that each signature:
  • not be a hash-based signature
  • be accompanied by a MD5/SHA1/SHA256 for a sample the signature is meant to detect.
  • come with a brief description of the threat the signature is trying to detect and what the signature is looking for

Full Story (comments: none)

New vulnerabilities

ffmpeg: multiple unspecified vulnerabilities

Package(s):ffmpeg CVE #(s):
Created:February 14, 2014 Updated:February 19, 2014
Description: From the Mageia advisory:

This updates provides ffmpeg version 1.1.8, which fixes several unspecified security vulnerabilities and other bugs which were corrected upstream.

The Mageia bug report gives a long list of CVEs, some of which *may* be fixed by this update, but the discussion makes it clear that no one knows which.

Alerts:
Mandriva MDVSA-2014:037 ffmpeg 2014-02-17
Mageia MGASA-2014-0066 ffmpeg 2014-02-13

Comments (none posted)

file: denial of service

Package(s):file CVE #(s):CVE-2014-1943
Created:February 17, 2014 Updated:April 7, 2014
Description: From the Debian advisory:

It was discovered that file, a file type classification tool, contains a flaw in the handling of "indirect" magic rules in the libmagic library, which leads to an infinite recursion when trying to determine the file type of certain files. The Common Vulnerabilities and Exposures project ID CVE-2014-1943 has been assigned to identify this flaw. Additionally, other well-crafted files might result in long computation times (while using 100% CPU) and overlong results.

Alerts:
Mandriva MDVSA-2015:080 php 2015-03-28
Scientific Linux SLSA-2014:1606-2 file 2014-11-03
Red Hat RHSA-2014:1765-01 php54-php 2014-10-30
Red Hat RHSA-2014:1606-02 file 2014-10-14
Gentoo 201408-11 php 2014-08-29
Oracle ELSA-2014-1606 file 2014-10-16
CentOS CESA-2014:1012 php53 2014-08-06
Oracle ELSA-2014-1012 php53 2014-08-06
Oracle ELSA-2014-1012 php53 2014-08-06
Scientific Linux SLSA-2014:1012-1 php53 and php 2014-08-06
CentOS CESA-2014:1012 php53 2014-08-06
Red Hat RHSA-2014:1012-01 php53 2014-08-06
Mageia MGASA-2014-0163 php 2014-04-04
Mageia MGASA-2014-0162 php 2014-04-04
Slackware SSA:2014-074-01 php 2014-03-15
Mandriva MDVSA-2014:059 php 2014-03-14
openSUSE openSUSE-SU-2014:0364-1 file 2014-03-13
openSUSE openSUSE-SU-2014:0367-1 file 2014-03-13
Gentoo 201403-03 file 2014-03-13
Mandriva MDVSA-2014:051 file 2014-03-13
Ubuntu USN-2126-1 php5 2014-03-03
Fedora FEDORA-2014-2876 file 2014-03-04
Debian DSA-2868-1 php5 2014-03-02
Ubuntu USN-2123-1 file 2014-02-26
Mageia MGASA-2014-0092 file 2014-02-22
Fedora FEDORA-2014-2739 file 2014-02-23
Debian DSA-2861-1 file 2014-02-16

Comments (none posted)

gnutls: certificate verification error

Package(s):gnutls CVE #(s):CVE-2014-1959
Created:February 17, 2014 Updated:February 26, 2014
Description: From the Mageia advisory:

Suman Jana reported a vulnerability that affects the certificate verification functions of gnutls 3.1.x and gnutls 3.2.x. A version 1 intermediate certificate will be considered as a CA certificate by default (something that deviates from the documented behavior)

Alerts:
Mandriva MDVSA-2015:072 gnutls 2015-03-27
Fedora FEDORA-2014-14760 gnutls 2014-11-13
Gentoo 201406-09 gnutls 2014-06-13
Ubuntu USN-2121-1 gnutls26 2014-02-25
Fedora FEDORA-2014-2565 mingw-gnutls 2014-02-24
Fedora FEDORA-2014-2583 mingw-gnutls 2014-02-24
Fedora FEDORA-2014-2588 gnutls 2014-02-22
Debian DSA-2866-1 gnutls26 2014-02-22
Slackware SSA:2014-050-01 gnutls 2014-02-19
Mandriva MDVSA-2014:043 gnutls 2014-02-19
Fedora FEDORA-2014-2580 gnutls 2014-02-17
Mageia MGASA-2014-0077 gnutls 2014-02-16

Comments (none posted)

imapsync: TLS botch

Package(s):imapsync CVE #(s):CVE-2014-2014
Created:February 14, 2014 Updated:October 28, 2014
Description: A bit of info from the Fedora advisory:

Bug fix: Check if going to tls is ok, exit otherwise with explicit error message. Thanks to Dennis Schridde for reporting this ugly bug that deserves a CVE.

See this oss-security list email for additional information.

Alerts:
Mageia MGASA-2014-0430 php 2014-10-28
Mandriva MDVSA-2014:060 imapsync 2014-03-14
Mageia MGASA-2014-0106 imapsync 2014-02-27
Fedora FEDORA-2014-2468 imapsync 2014-02-16
Fedora FEDORA-2014-2505 imapsync 2014-02-14

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):kernel CVE #(s):CVE-2014-0069 CVE-2014-1874
Created:February 18, 2014 Updated:March 28, 2014
Description: From the Red Hat bugzilla [1, 2]:

Linux kernel built with the NSA SELinux Support(CONFIG_SECURITY_SELINUX) is vulnerable to a crash caused by an empty SELinux security context value. If a file has an empty security context, listing it via 'ls(1)' could trigger this crash. Only user/processes with CAP_MAC_ADMIN privileges are allowed to set the SELinux security context of a file.

A user/process with CAP_MAC_ADMIN privileges could use this flaw to crash the kernel, resulting in a DoS. (CVE-2014-1874)

A flaw was found in the way cifs handled iovecs with bogus pointers userland passed down via writev() during uncached writes.

An unprivileged local user with access to cifs share could use this flaw to crash the system or leak kernel memory. Privilege escalation cannot be ruled out (since memory corruption is involved), but is unlikely. (CVE-2014-0069)

Alerts:
SUSE SUSE-SU-2015:0812-1 kernel 2015-04-30
Oracle ELSA-2014-1392 kernel 2014-10-21
SUSE SUSE-SU-2014:0908-1 Linux kernel 2014-07-17
SUSE SUSE-SU-2014:0909-1 Linux kernel 2014-07-17
SUSE SUSE-SU-2014:0910-1 Linux kernel 2014-07-17
SUSE SUSE-SU-2014:0911-1 Linux kernel 2014-07-17
SUSE SUSE-SU-2014:0912-1 Linux kernel 2014-07-17
Scientific Linux SLSA-2014:0771-1 kernel 2014-06-19
Oracle ELSA-2014-0771 kernel 2014-06-19
CentOS CESA-2014:0771 kernel 2014-06-20
Red Hat RHSA-2014:0771-01 kernel 2014-06-19
SUSE SUSE-SU-2014:0807-1 Linux Kernel 2014-06-18
openSUSE openSUSE-SU-2014:0766-1 Evergreen 2014-06-06
Ubuntu USN-2227-1 linux-ti-omap4 2014-05-27
Ubuntu USN-2221-1 kernel 2014-05-26
Mageia MGASA-2014-0238 kernel-vserver 2014-05-24
Mageia MGASA-2014-0234 kernel-tmb 2014-05-23
Mageia MGASA-2014-0236 kernel-tmb 2014-05-24
Mageia MGASA-2014-0237 kernel-rt 2014-05-24
Mageia MGASA-2014-0235 kernel-linus 2014-05-24
SUSE SUSE-SU-2014:0696-1 Linux kernel 2014-05-22
Mageia MGASA-2014-0229 kernel-vserver 2014-05-19
Mageia MGASA-2014-0228 kernel 2014-05-19
openSUSE openSUSE-SU-2014:0678-1 kernel 2014-05-19
openSUSE openSUSE-SU-2014:0677-1 kernel 2014-05-19
Mageia MGASA-2014-0208 kernel-rt 2014-05-08
Mageia MGASA-2014-0207 kernel-linus 2014-05-08
Mageia MGASA-2014-0206 kernel 2014-05-08
Red Hat RHSA-2014:0439-01 kernel-rt 2014-04-28
Ubuntu USN-2181-1 linux-ti-omap4 2014-04-26
Ubuntu USN-2180-1 linux-ti-omap4 2014-04-26
Ubuntu USN-2177-1 linux-lts-saucy 2014-04-26
Ubuntu USN-2176-1 linux-lts-raring 2014-04-26
Ubuntu USN-2175-1 linux-lts-quantal 2014-04-26
Ubuntu USN-2179-1 kernel 2014-04-26
Ubuntu USN-2178-1 kernel 2014-04-26
Debian DSA-2906-1 linux-2.6 2014-04-24
SUSE SUSE-SU-2014:0537-1 Linux kernel 2014-04-17
SUSE SUSE-SU-2014:0531-1 Linux kernel 2014-04-16
CentOS CESA-2014:X009 kernel 2014-06-16
Mandriva MDVSA-2014:124 kernel 2014-06-13
SUSE SUSE-SU-2014:0459-1 Linux Kernel 2014-03-28
Scientific Linux SLSA-2014:0328-1 kernel 2014-03-25
Oracle ELSA-2014-0328 kernel 2014-03-25
CentOS CESA-2014:0328 kernel 2014-03-25
Red Hat RHSA-2014:0328-01 kernel 2014-03-25
Ubuntu USN-2141-1 linux-ti-omap4 2014-03-07
Ubuntu USN-2134-1 linux-ti-omap4 2014-03-07
Ubuntu USN-2139-1 linux-ti-omap4 2014-03-07
Ubuntu USN-2137-1 linux-lts-saucy 2014-03-07
Ubuntu USN-2136-1 linux-lts-raring 2014-03-07
Ubuntu USN-2135-1 linux-lts-quantal 2014-03-07
Ubuntu USN-2138-1 kernel 2014-03-07
Ubuntu USN-2140-1 kernel 2014-03-07
Ubuntu USN-2133-1 kernel 2014-03-07
Ubuntu USN-2128-1 kernel 2014-03-05
Ubuntu USN-2129-1 EC2 kernel 2014-03-05
Mageia MGASA-2014-0103 kernel 2014-02-26
Fedora FEDORA-2014-2606 kernel 2014-02-17
Fedora FEDORA-2014-2576 kernel 2014-02-17

Comments (none posted)

libtar: directory traversal

Package(s):libtar CVE #(s):CVE-2013-4420
Created:February 19, 2014 Updated:February 26, 2014
Description: From the Debian advisory:

A directory traversal attack was reported against libtar, a C library for manipulating tar archives. The application does not validate the filenames inside the tar archive, allowing to extract files in arbitrary path. An attacker can craft a tar file to override files beyond the tar_extract_glob and tar_extract_all prefix parameter.

Alerts:
Mandriva MDVSA-2014:045 libtar 2014-02-20
Mageia MGASA-2014-0090 libtar 2014-02-21
Debian DSA-2863-1 libtar 2014-02-18

Comments (none posted)

lxc: privilege escalation

Package(s):lxc CVE #(s):CVE-2013-6441
Created:February 13, 2014 Updated:February 27, 2014
Description: From the Ubuntu advisory:

Florian Sagar discovered that the LXC sshd template set incorrect mount permissions. An attacker could possibly use this flaw to cause privilege escalation on the host.

Alerts:
Mageia MGASA-2014-0102 lxc 2014-02-26
Ubuntu USN-2104-1 lxc 2014-02-12
Debian-LTS DLA-442-1 lxc 2016-02-29

Comments (none posted)

maas: two vulnerabilities

Package(s):maas CVE #(s):CVE-2013-1070 CVE-2013-1069
Created:February 14, 2014 Updated:February 19, 2014
Description: From the Ubuntu advisory:

James Troup discovered that MAAS stored RabbitMQ authentication credentials in a world-readable file. A local authenticated user could read this password and potentially gain privileges of other user accounts. This update restricts the file permissions to prevent unintended access. (CVE-2013-1070)

Chris Glass discovered that the MAAS API was vulnerable to cross-site scripting vulnerabilities. With cross-site scripting vulnerabilities, if a user were tricked into viewing a specially crafted page, a remote attacker could exploit this to modify the contents, or steal confidential data, within the same domain. (CVE-2013-1069)

Alerts:
Ubuntu USN-2105-1 maas 2014-02-13

Comments (none posted)

maradns: denial of service

Package(s):maradns CVE #(s):CVE-2014-2031 CVE-2014-2032
Created:February 14, 2014 Updated:April 3, 2014
Description: From the Fedora advisory:

There has been a long-standing bug in Deadwood (ever since 2007) where bounds checking for strings was not correctly done under some circumstances.

Because of this, it has been possible to send Deadwood a "packet of death" which will crash Deadwood. Since the attack causes out-of-bounds memory to be read, but not written to, the impact of the bug is denial of service. It appears this attack can only be exploited by an IP with permission to perform recursive queries against Deadwood.

Note that this bug only affects users of the Deadwood recursive resolver.

Alerts:
Fedora FEDORA-2014-2439 maradns 2014-04-03
Mageia MGASA-2014-0079 maradns 2014-02-17
Fedora FEDORA-2014-2421 maradns 2014-02-14
Mageia MGASA-2014-0078 maradns 2014-02-17

Comments (none posted)

mongodb: denial of service

Package(s):mongodb CVE #(s):CVE-2012-6619
Created:February 18, 2014 Updated:April 29, 2014
Description: From the Mageia advisory:

A possible DoS issue was discovered in MongoDB. See the MongoDB advisory for more information.

Alerts:
Red Hat RHSA-2014:0440-01 mrggrid 2014-04-28
Red Hat RHSA-2014:0230-01 mongodb 2014-03-04
Mageia MGASA-2014-0083 mongodb 2014-02-17

Comments (none posted)

mpg123: denial of service

Package(s):mpg123 CVE #(s):CVE-2014-9497
Created:February 14, 2014 Updated:October 17, 2016
Description: From the Mageia advisory:

mpg123 1.14.1 and later are vulnerable to a buffer overflow that could allow a maliciously crafted audio file to crash applications that use the libmpg123 library.

Alerts:
Gentoo 201502-01 mpg123 2015-02-06
Mageia MGASA-2014-0067 mpg123 2014-02-13
Debian-LTS DLA-655-1 mpg123 2016-10-15

Comments (none posted)

mysql: code execution

Package(s):mysql CVE #(s):CVE-2014-0001
Created:February 13, 2014 Updated:June 9, 2014
Description: From the Red Hat advisory:

A buffer overflow flaw was found in the way the MySQL command line client tool (mysql) processed excessively long version strings. If a user connected to a malicious MySQL server via the mysql client, the server could use this flaw to crash the mysql client or, potentially, execute arbitrary code as the user running the mysql client. (CVE-2014-0001)

Alerts:
Gentoo 201409-04 mysql 2014-09-04
SUSE SUSE-SU-2014:0769-1 MySQL 2014-06-07
Debian DSA-2919-1 mysql-5.5 2014-05-03
Ubuntu USN-2170-1 mysql-5.5 2014-04-23
CentOS CESA-2014:0189 mariadb55-mariadb 2014-02-26
Slackware SSA:2014-050-02 mariadb 2014-02-19
CentOS CESA-2014:0173 mysql55-mysql 2014-02-19
Red Hat RHSA-2014:0189-01 mariadb55-mariadb 2014-02-19
Scientific Linux SLSA-2014:0186-1 mysql55-mysql 2014-02-18
Oracle ELSA-2014-0186 mysql55-mysql 2014-02-18
CentOS CESA-2014:0186 mysql55-mysql 2014-02-19
Red Hat RHSA-2014:0186-01 mysql55-mysql 2014-02-18
Mandriva MDVSA-2014:028 mariadb 2014-02-13
CentOS CESA-2014:0164 mysql 2014-02-12
Red Hat RHSA-2014:0173-01 mysql55-mysql 2014-02-13
Mandriva MDVSA-2014:029 mysql 2014-02-13
Red Hat RHSA-2014:0164-01 mysql 2014-02-12
Scientific Linux SLSA-2014:0164-1 mysql 2014-02-12
Oracle ELSA-2014-0164 mysql 2014-02-12

Comments (none posted)

numpy: insecure temp files

Package(s):numpy CVE #(s):CVE-2014-1858 CVE-2014-1859
Created:February 17, 2014 Updated:March 29, 2015
Description: From the Red Hat bugzilla:

Jakub Wilk found that f2py insecurely used a temporary file. A local attacker could use this flaw to perform a symbolic link attack to modify an arbitrary file accessible to the user running f2py.

Alerts:
Mandriva MDVSA-2015:077 python-numpy 2015-03-27
Mageia MGASA-2014-0089 python-numpy 2014-02-21
Fedora FEDORA-2014-2387 numpy 2014-02-22
Fedora FEDORA-2014-2289 numpy 2014-02-15

Comments (none posted)

openswan: denial of service

Package(s):openswan CVE #(s):CVE-2013-6466
Created:February 19, 2014 Updated:November 24, 2014
Description: From the Red Hat advisory:

A NULL pointer dereference flaw was discovered in the way Openswan's IKE daemon processed IKEv2 payloads. A remote attacker could send specially crafted IKEv2 payloads that, when processed, would lead to a denial of service (daemon crash), possibly causing existing VPN connections to be dropped.

Alerts:
Gentoo 201411-07 openswan 2014-11-23
Debian DSA-2893-1 openswan 2014-03-31
Mageia MGASA-2014-0097 openswan 2014-02-25
Scientific Linux SLSA-2014:0185-1 openswan 2014-02-18
Oracle ELSA-2014-0185 openswan 2014-02-18
Oracle ELSA-2014-0185 openswan 2014-02-18
CentOS CESA-2014:0185 openswan 2014-02-18
CentOS CESA-2014:0185 openswan 2014-02-18
Red Hat RHSA-2014:0185-01 openswan 2014-02-18

Comments (none posted)

perl-Capture-Tiny: insecure tmpfile use

Package(s):perl-Capture-Tiny CVE #(s):CVE-2014-1875
Created:February 14, 2014 Updated:February 24, 2014
Description: From the Mageia advisory:

perl-Capture-Tiny before 0.24 used files in /tmp in an insecure manner (CVE-2014-1875).

Alerts:
Fedora FEDORA-2014-2261 perl-Capture-Tiny 2014-02-22
Fedora FEDORA-2014-2321 perl-Capture-Tiny 2014-02-22
Mageia MGASA-2014-0068 perl-Capture-Tiny 2014-02-13

Comments (none posted)

php: denial of service

Package(s):php CVE #(s):CVE-2013-7226
Created:February 13, 2014 Updated:March 4, 2014
Description: Inadequate checking of the arguments to the imagecrop() function can lead to a heap overflow, see the PHP bug entry for lots more info.
Alerts:
Gentoo 201408-11 php 2014-08-29
Ubuntu USN-2126-1 php5 2014-03-03
Mandriva MDVSA-2014:027 php 2014-02-12

Comments (none posted)

piranha: access restriction bypass

Package(s):piranha CVE #(s):CVE-2013-6492
Created:February 14, 2014 Updated:February 19, 2014
Description: From the Red Hat advisory:

It was discovered that the Piranha Configuration Tool did not properly restrict access to its web pages. A remote attacker able to connect to the Piranha Configuration Tool web server port could use this flaw to read or modify the LVS configuration without providing valid administrative credentials. (CVE-2013-6492)

Alerts:
CentOS CESA-2014:0174 piranha 2014-02-13
Red Hat RHSA-2014:0174-01 piranha 2014-02-13
Scientific Linux SLSA-2014:0174-1 piranha 2014-02-13
Scientific Linux SLSA-2014:0175-1 piranha 2014-02-13
Oracle ELSA-2014-0174 piranha 2014-02-13
CentOS CESA-2014:0175 piranha 2014-02-13
Red Hat RHSA-2014:0175-01 piranha 2014-02-13

Comments (none posted)

python: code execution

Package(s):python CVE #(s):CVE-2014-1912
Created:February 14, 2014 Updated:April 14, 2014
Description: From the Red Hat bugzilla entry:

A vulnerability was reported in Python's socket module, due to a boundary error within the sock_recvfrom_into() function, which could be exploited to cause a buffer overflow. This could be used to crash a Python application that uses the socket.recvfrom_info() function or, possibly, execute arbitrary code with the permissions of the user running vulnerable Python code.

Alerts:
Scientific Linux SLSA-2015:1330-1 python 2015-08-03
Red Hat RHSA-2015:1330-01 python 2015-07-22
Red Hat RHSA-2015:1064-01 python27 2015-06-04
Mandriva MDVSA-2015:076 python3 2015-03-27
Mandriva MDVSA-2015:075 python 2015-03-27
Gentoo 201503-10 python 2015-03-18
openSUSE openSUSE-SU-2014:1734-1 python 2014-12-31
openSUSE openSUSE-SU-2014:0597-1 python3 2014-05-02
openSUSE openSUSE-SU-2014:0518-1 python 2014-04-11
openSUSE openSUSE-SU-2014:0498-1 python3 2014-04-09
Debian DSA-2880-1 python2.7 2014-03-17
openSUSE openSUSE-SU-2014:0380-1 python 2014-03-15
Ubuntu USN-2125-1 python2.6, python2.7, python3.2, python3.3 2014-03-03
Mageia MGASA-2014-0085 python & python3 2014-02-19
Mandriva MDVSA-2014:041 python 2014-02-19
Fedora FEDORA-2014-2418 python3 2014-02-15
Fedora FEDORA-2014-2394 python 2014-02-14

Comments (none posted)

xen: information leak

Package(s):xen CVE #(s):CVE-2014-1895
Created:February 17, 2014 Updated:February 25, 2014
Description: From the Red Hat bugzilla:

The FLASK_AVC_CACHESTAT hypercall, which provides access to per-cpu statistics on the Flask security policy, incorrectly validates the CPU for which statistics are being requested.

An attacker can cause the hypervisor to read past the end of an array. This may result in either a host crash, leading to a denial of service, or access to a small and static region of hypervisor memory, leading to an information leak.

Alerts:
Gentoo 201407-03 xen 2014-07-16
openSUSE openSUSE-SU-2014:0483-1 xen 2014-04-04
SUSE SUSE-SU-2014:0373-1 Xen 2014-03-14
CentOS CESA-2014:X007 xen 2014-02-25
Fedora FEDORA-2014-2170 xen 2014-02-16
Fedora FEDORA-2014-2188 xen 2014-02-16

Comments (none posted)

zarafa: denial of service

Package(s):zarafa CVE #(s):CVE-2014-0037 CVE-2014-0079
Created:February 17, 2014 Updated:March 3, 2014
Description: From the Red Hat bugzilla [1, 2]:

Robert Scheck discovered a flaw in Zarafa that could allow a remote unauthenticated attacker to crash the zarafa-server daemon, preventing access to any other legitimate Zarafa users. (CVE-2014-0037)

Robert Scheck discovered another flaw in Zarafa that could allow a remote unauthenticated attacker to crash the zarafa-server daemon, preventing access to any other legitimate Zarafa users.

The issue affects all Zarafa versions from at least Zarafa 6.20.0 (maybe even from at least Zarafa 5.00) up to (including) Zarafa 7.1.8 final. Please note that I was not able to crash the zarafa-server daemon using official upstream Zarafa binary packages just all community builds from the source code such as shipped in Fedora. This different behaviour might be caused that upstream uses different built-time flags or other system libraries and headers. (CVE-2014-0079)

Alerts:
Mageia MGASA-2014-0112 zarafa 2014-03-01
Mandriva MDVSA-2014:044 zarafa 2014-02-19
Fedora FEDORA-2014-1900 zarafa 2014-02-15
Fedora FEDORA-2014-1883 zarafa 2014-02-15

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>


Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds