Security
Random numbers for ASLR
Two weeks ago on this page, we looked at two problems in the Linux implementation of address space layout randomization (ASLR). At the time, neither had been addressed by kernel hackers, but, since then, both have been. One was a rather trivial fix, but the other, regarding random number generation (RNG), led to a bit of a contentious thread on linux-kernel.
There is always some tension between performance and security, and that is part of why there was disagreement about how to fix a, clearly faulty, RNG that is used for ASLR. As noted in our earlier article, recently reported research had shown that the address space of a process could be reconstructed because of the poor RNG used to generate the values. Some part of the early discussion of the problem, along with the patch originally proposed by Matt Mackall, occurred on the private security@kernel.org mailing list. It surfaced on linux-kernel when Linus Torvalds asked for opinions on Mackall's fix:
Quite frankly, the way "get_random_bytes()" works now (it does a _full_ sha thing every time), I think it's insane overkill. But I do have to admit that our current "get_random_int()" is insane _underkill_.
I'd like to improve the latter without going to [quite] the extreme that matt's patch did.
Mackall's patch used get_random_bytes()—a kernel-internal source of random numbers which is equivalent to user space reading from /dev/urandom—to define a get_random_u32(). That function had a much better name as well as better random numbers. But, as Torvalds pointed out, it does a lot more work. Mackall believed that was a reasonable starting point:
Torvalds came up with a patch that improved the randomness of get_random_int() by keeping the calculated hash data between invocations, using that and a bit of noise from the system (pid + jiffies) to feed back into the half_md4_transform() function. Though it still uses the key that changes every five minutes, there is general agreement that this increased the strength of the RNG without impacting performance.
But, half_md4_transform() does a reduced round version of the MD4 hash. MD4 itself is essentially "broken" in that collisions can be trivially generated, so a reduced round version is weaker still. That concerns Mackall:
Instead of using the MD4 variant or his original patch, Mackall suggested using SHA1 as a compromise of sorts. He did some benchmarks on the two and found that the SHA1 variant was about half as fast as the MD4 (.660us vs. .326us), which seemed like an acceptable tradeoff to him. Ingo Molnar disagreed, noting that it came to roughly 1% of the performance of fork() (which uses get_random_int() for the starting stack_canary value). He also wanted to know what threat model necessitated using SHA1. Mackall replied:
In fact, it's been known for over a decade that reduced-round MD4 such as ours is *not one way* and that preimages (aka our hidden state) can be found in less than an hour on a *mid-90s era PC*:
Torvalds, though, is unimpressed by
Mackall's "only twice as
long
" argument: "In the kernel, we tend to never even talk
about how many
_times_ slower something is. We talk about cycles or small
percentages
". In his typical fashion, Torvalds also points out
another flaw he
sees in Mackall's argument:
In other words, YOUR WHOLE ARGUMENT IS TOTALLY INSANE. You talk about "cryptographically secure hashes" for some 8-bit value. Listen to yourself. At that point, any cryptographer will just ridicule you. There's no point in trying to break the randomness, because you'll be much better off just trying a lot of different values.
In the end, Torvalds's code (with a small addition by Molnar) went in to the kernel, without the random driver maintainer's, Mackall's, "Acked-by" tag. While the uses of get_random_int() in today's kernel may not require that much in the way of randomness, it does seem wrong, at some level, to have a function of that name, which doesn't really perform its job. But, clearly this alleviates much, perhaps all, of the ASLR problems that prompted the change. That can only be a good thing.
New vulnerabilities
gnutls: multiple vulnerabilities
| Package(s): | gnutls | CVE #(s): | CVE-2009-1415 CVE-2009-1416 | ||||||||||||
| Created: | May 11, 2009 | Updated: | May 25, 2009 | ||||||||||||
| Description: | From the CVE entries: CVE-2009-1415: lib/pk-libgcrypt.c in libgnutls in GnuTLS before 2.6.6 does not properly handle invalid DSA signatures, which allows remote attackers to cause a denial of service (application crash) and possibly have unspecified other impact via a malformed DSA key that triggers a (1) free of an uninitialized pointer or (2) double free. CVE-2009-1416: lib/gnutls_pk.c in libgnutls in GnuTLS 2.5.0 through 2.6.5 generates RSA keys stored in DSA structures, instead of the intended DSA keys, which might allow remote attackers to spoof signatures on certificates or have unspecified other impact by leveraging an invalid DSA key. | ||||||||||||||
| Alerts: |
| ||||||||||||||
kernel: denial of service
| Package(s): | linux-2.6 | CVE #(s): | CVE-2009-1336 | ||||||||||||||||||||||||
| Created: | May 7, 2009 | Updated: | July 2, 2009 | ||||||||||||||||||||||||
| Description: | The 2.6 kernel has a denial of service vulnerability. The National Vulnerability Database Entry description states: fs/nfs/client.c in the Linux kernel before 2.6.23 does not properly initialize a certain structure member that stores the maximum NFS filename length, which allows local users to cause a denial of service (OOPS) via a long filename, related to the encode_lookup function. | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
kernel: information disclosure
| Package(s): | kernel | CVE #(s): | CVE-2009-0787 | ||||||||
| Created: | May 7, 2009 | Updated: | May 13, 2009 | ||||||||
| Description: | The kernel has an information disclosure vulnerability. The National Vulnerability Database entry states: The ecryptfs_write_metadata_to_contents function in the eCryptfs functionality in the Linux kernel 2.6.28 before 2.6.28.9 uses an incorrect size when writing kernel memory to an eCryptfs file header, which triggers an out-of-bounds read and allows local users to obtain portions of kernel memory. | ||||||||||
| Alerts: |
| ||||||||||
ldns: buffer overflow
| Package(s): | ldns | CVE #(s): | CVE-2009-1086 | ||||||||
| Created: | May 7, 2009 | Updated: | May 13, 2009 | ||||||||
| Description: | ldns has a heap-based buffer overflow vulnerability. From the Debian alert: Stefan Kaltenbrunner discovered that ldns, a library and set of utilities to facilitate DNS programming, did not correctly implement a buffer boundary check in its RR DNS record parser. This weakness could enable overflow of a heap buffer if a maliciously-crafted record is parsed, potentially allowing the execution of arbitrary code. The scope of compromise will vary with the context in which ldns is used, and could present either a local or remote attack vector. | ||||||||||
| Alerts: |
| ||||||||||
libmodplug: buffer overflow
| Package(s): | libmodplug | CVE #(s): | CVE-2009-1513 | ||||||||||||||||||||
| Created: | May 8, 2009 | Updated: | December 4, 2009 | ||||||||||||||||||||
| Description: | From the CVE entry: Buffer overflow in the PATinst function in src/load_pat.cpp in libmodplug before 0.8.7 allows user-assisted remote attackers to cause a denial of service and possibly execute arbitrary code via a long instrument name. | ||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||
pango: denial of service
| Package(s): | pango1.0 | CVE #(s): | CVE-2009-1194 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | May 8, 2009 | Updated: | February 16, 2010 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | From the Ubuntu advisory: Will Drewry discovered that Pango incorrectly handled rendering text with long glyphstrings. If a user were tricked into displaying specially crafted data with applications linked against Pango, such as Firefox, an attacker could cause a denial of service or execute arbitrary code with privileges of the user invoking the program. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||
quagga: denial of service
| Package(s): | quagga | CVE #(s): | CVE-2009-1572 | ||||||||||||||||||||||||
| Created: | May 11, 2009 | Updated: | July 3, 2009 | ||||||||||||||||||||||||
| Description: | From the Mandriva advisory: The BGP daemon (bgpd) in Quagga 0.99.11 and earlier allows remote attackers to cause a denial of service (crash) via an AS path containing ASN elements whose string representation is longer than expected, which triggers an assert error (CVE-2009-1572). | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
squirrelmail: multiple vulnerabilities
| Package(s): | squirrelmail | CVE #(s): | CVE-2009-1578 CVE-2009-1579 CVE-2009-1580 CVE-2009-1581 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | May 13, 2009 | Updated: | January 14, 2010 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | The SquirrelMail 1.4.18 release fixes a number of vulnerabilities: "including a couple XSS exploits, a session fixation issue, and an obscure but dangerous server-side code execution hole." | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
zsh: buffer overflow
| Package(s): | zsh | CVE #(s): | CVE-2009-1214 CVE-2009-1215 | ||||
| Created: | May 7, 2009 | Updated: | May 13, 2009 | ||||
| Description: | Zsh has a buffer overflow vulnerability. From the Mandriva alert: A stack-based buffer overflow was found in the zsh command interpreter. An attacker could use this flaw to cause a denial of service (zsh crash), when providing a specially-crafted string as input to the zsh shell | ||||||
| Alerts: |
| ||||||
Page editor: Jake Edge
Next page:
Kernel development>>