Most Linux kernels have a slightly different sort of vulnerability in the
networking subsystem. For most users, the new problem is nothing to be
particularly worried about. For systems that export important services to
the net (i.e. web servers), however, this one is worth paying attention to.
The networking code maintains a number of internal hash tables to speed
lookups. In the networking code, for example, one table is used to quickly
find the route to a remote system; another is used in the netfilter
connection tracking code. The problem is that the hashing function used
for these tables is predictable and can be influenced by outsiders. In
particular, a suitably clever attacker can, through careful choices of
(false) source packet addresses, create a great many entries in a single
hash chain.
Once the chain gets long, the kernel will begin to take a long time to look
up each packet which hashes to that chain. This behavior enables a simple
denial of service attack: send a bunch of packets with the right addresses
and watch the target system slow to a crawl. By exploiting this
vulnerability, an attacker can get many of the effects of a large,
distributed denial of service attack without having to arrange the
"distributed" part - a single system will do.
Fixing the problem is a simple matter of picking a better hash function
which does not have such predictable behavior. Patches are available for
the 2.4 kernel, though, as of this writing, few vendors have released
updates; this LWN vulnerability entry
will track the updates as they are received. The 2.4.21-rc2 and 2.5.69
kernels also contain the fix - but nobody should be running important
services on either of those.
Comments (5 posted)
Bruce Schneier's CRYPTO-GRAM newsletter for May is out; it looks at
encryption and wiretapping, using unique email addresses for spam
avoidance, and cash register receipts. "
This wiretapping report
provides hard evidence that a closed security design methodology -- the
'trust us because we know these things' way of building security
products -- doesn't work. The U.S. government hasn't encountered a
telephone encryption product that they couldn't easily break.
"
Full Story (comments: 1)
Two weeks ago, this page
reported that OpenBSD does not yet have executable stack protection on the
x86 architecture. That statement, as it turns out, aligns poorly with
reality. OpenBSD has had non-executable stacks since 3.2; what it does not
(yet) have is protection for the other data areas - that is the protection
offered by the "W^X" technology in OpenBSD 3.3, but which will not be
available for x86 until the 3.4 release. We blew it, and we regret the
error.
Comments (2 posted)
