LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityUnpredictable sequence numbersIt has been known for 15 years or more that using predictable network sequence numbers is a security risk, so most implementations, including Linux, have randomized the initial sequence number (ISN) for TCP connections. Due to performance concerns, though, Linux used a combination of the MD4 cryptographic hash, along with changing the random seed every five minutes, to create the ISN. In addition, only a partial MD4 implementation was used, which effectively limited the ISNs to 24 bits of randomness. That's all changed with a recent patch that has been merged into the mainline as well as the stable and longterm kernels. Sequence numbers are used by TCP to keep the bytes in the connection stream in order. An ISN is established at the time the connection is made, and incremented by the number of data bytes in each packet. That way, both sides of the connection can recognize when they have received out-of-order packets and ensure that the data that gets handed off to the application is properly sequenced. Initially, TCP specified that ISNs would increment every four microseconds to avoid having multiple outstanding connections with the same sequence number. But, in the mid-90s, it was recognized that predictability in choosing ISNs could be used by attackers to potentially inject packets into the set up of a connection, or into an established session itself. That led to RFC 1948, which suggested establishing a separate sequence number space for each connection, and randomizing the ISNs based on the connection parameters. Basically, the idea is that by using the source address/port and destination address/port as input to a cryptographic hash (the RFC suggests MD5), along with a random seed generated at boot time, an unpredictable ISN can be created. But Linux went its own way, using the partial MD4 and resetting the random seed frequently (which was meant to add some additional unpredictability). According to the description in David Miller's patch, Dan Kaminsky recently alerted the kernel security mailing list (i.e. security@kernel.org, which is a closed list for security discussions) that the Linux ISN generation was vulnerable to brute force attacks. Presumably, the increased speed of today's computers coupled with the higher bandwidth available means that a brute force attack against a 24-bit space is more plausible today. Also, as Miller points out, the increase in computer speed also means that the need for using MD4 for performance reasons has likely passed. Over the years since RFC 1948, MD5 has been considerably weakened, so SHA-1 was also considered for the Linux fix. But, as Miller describes it, the performance cost was simply too high:
MD5 was selected as a compromise between performance loss and
theoretical ability to be compromised. Willy Tarreau did extensive
testing and SHA1 was found to harm performance too much to be
considered seriously at this time.
Down the road, a sysctl knob may be added to select different modes, Miller said. That could include the "super secure" SHA-1 version, as well as a mode that turns off any hashing for networks that run in trusted environments. While it may have made sense at the time, it is clear that using MD4 (and effectively limiting it to 24 bits of randomness) is just too risky today. Attacks against the earlier implementation may be hard to pull off, but the effects can be rather serious. The RFC describes an attack that would inject commands into a remote shell session. While rsh is not used very frequently—at all?—any more, there are other kinds of attacks that are possible too. It's good to see this particular hole get filled.
Brief items Security quotes of the week
Turns out we have a large index of the web, so we cranked through 20
terabytes of SWF file downloads followed by 1 week of run time on 2,000 CPU
cores to calculate the minimal set of about 20,000 files. Finally, those
same 2,000 cores plus 3 more weeks of runtime were put to good work
mutating the files in the minimal set (bitflipping, etc.) and generating
crash cases. These crash cases included an interesting range of
vulnerability categories, including buffer overflows, integer overflows,
use-after-frees and object type confusions.
-- Google
security team on fuzzing Flash at "Google scale"
Is losing your genomic privacy an excessive price to pay for surviving cancer and evading plagues?
-- Charlie
Stross's USENIX 2011 keynote: Network Security in the Medium Term, 2061-2561 AD
Is compromising your sensory privacy through lifelogging a reasonable price to pay for preventing malicious impersonation and apprehending criminals? Is letting your insurance company know exactly how you steer and hit the gas and brake pedals, and where you drive, an acceptable price to pay for cheaper insurance?
One year of Android malwarePaolo Passeri has put up a list of malevolent Android applications discovered over the last year. "Scroll down my special compilation showing the long malware trail which characterized this hard days for information security. Commenting the graph, in my opinion, probably the turning point was Android.Geinimi (end of 2010), featuring the characteristics of a primordial Botnet, but also Android.DroidDream (AKA RootCager) is worthwhile to mention because of its capability to root the phone and potentially to remotely install applications without direct user intervention."
Cox: Six years of Red Hat Enterprise Linux 4Red Hat security team lead Mark J. Cox writes about the "Six Years of Red Hat Enterprise Linux 4" report [PDF] on his blog. It looks at the vulnerabilities that were found and fixed in RHEL 4, along with their severity. "The data we publish is interesting to get a feel for the risk of running Enterprise Linux, but isn't really useful for comparisons with other distributions, or operating systems. One important difference is that it is Red Hat policy to count vulnerabilities and allocate CVE names to all issues that we fix, including ones that are found internally. This is not true for many other vendors including folks like Microsoft and Adobe who do not count or disclose issues they fix which were found internally."
New vulnerabilities cgit: cross-site scripting
firefox: multiple vulnerabilities
isc-dhcp: denial of service
libmodplug: multiple vulnerabilities
libxfont: privilege escalation
Mozilla products: multiple vulnerabilities
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||