Breakage is not necessary. 2.4 will happily fail to mount/sys as sysfs, and it doesn't even look at/etc/modprobe.conf. The sysinit changes can be solved with a tiny bit of shell scripting. Move/etc/rc.sysinit to/etc/rc.sysinit.24 and/etc/rc.sysinit.26, and make your changes in the latter.
Then create a new/etc/rc.sysinit with the following:
#!/bin/bash
KERNEL=$(uname -r | awk -F. '{print $1"."$2}')
if [ $KERNEL = "2.6" ]; then ./etc/rc.sysinit.26 else ./etc/rc.sysinit.24 fi
I attended a talk on this topic last night given by the author of the paper. While it's a very interesting problem, people are missing the real kicker: This had been going on for a long time. The network guys would see blips every once in a while (and wonder "who would try to DoS the ntp server?"), but it wasn't until May that they saw a bit spike.
So they did the most reasonable thing, given that the traffic was easily identifiable (source port 23457): block it at the router. That's when the shit hit the fan. Each one of those 700,000 little boxes was configure, not just with a fixed IP address, but upon failing to receive a reply, to keep asking ONCE PER SECOND until it got a reply.
The end result is that the CSL *can't* block the traffic, or let the machine go down, etc etc. ntp1.cs.wisc.edu just became one of their most important servers, because it will cost them $60,000/mo in bandwidth if it goes down.
Options (at the end of the paper) include: doing clever things to keep the machine up, reliable, and spread bandwidth a bit, or sacrificing a/20 range to push the problem to the leaves of the network, where cable providers will only have to deal with ~10,000 rogue routers instead of the UW dealing with 700,000.
These devices seem to be deriving all their randomness by the natural (and intentional) "imperfections" of the creation process. This means that they only become secure when the devices are first analyzed -- *after* they are made. There is an inherent benefit and weakness to creating things in this hit-and-miss way.
Because the manufacturers are not trying to create pseudo-randomness themselves (invariably according to some algorithm, like creditcard numbers), it really is much harder for blackhats to reverse the one-way function. However, because there are no rules governing what a "valid" key looks like (they're just supposed to be unique), someone could very carefully create a number of these token that are, instead of random, very similar. Because practical implementations of this scheme are likely to scan these keys from pre-determines angles, the amount of difference allowed between these similar keys may be large enough to create "duplicates".
Note that this doesn't mean that blackhats can duplicate your key, but they may be able to create a matching pair and swap yours with theirs in the middle of the night...
Slashdot Mirror
I attended a talk on this topic last night given by the author of the paper. While it's a very interesting problem, people are missing the real kicker: This had been going on for a long time. The network guys would see blips every once in a while (and wonder "who would try to DoS the ntp server?"), but it wasn't until May that they saw a bit spike.
/20 range to push the problem to the leaves of the network, where cable providers will only have to deal with ~10,000 rogue routers instead of the UW dealing with 700,000.
So they did the most reasonable thing, given that the traffic was easily identifiable (source port 23457): block it at the router. That's when the shit hit the fan. Each one of those 700,000 little boxes was configure, not just with a fixed IP address, but upon failing to receive a reply, to keep asking ONCE PER SECOND until it got a reply.
The end result is that the CSL *can't* block the traffic, or let the machine go down, etc etc. ntp1.cs.wisc.edu just became one of their most important servers, because it will cost them $60,000/mo in bandwidth if it goes down.
Options (at the end of the paper) include: doing clever things to keep the machine up, reliable, and spread bandwidth a bit, or sacrificing a
These devices seem to be deriving all their randomness by the natural (and intentional) "imperfections" of the creation process. This means that they only become secure when the devices are first analyzed -- *after* they are made. There is an inherent benefit and weakness to creating things in this hit-and-miss way.
Because the manufacturers are not trying to create pseudo-randomness themselves (invariably according to some algorithm, like creditcard numbers), it really is much harder for blackhats to reverse the one-way function. However, because there are no rules governing what a "valid" key looks like (they're just supposed to be unique), someone could very carefully create a number of these token that are, instead of random, very similar. Because practical implementations of this scheme are likely to scan these keys from pre-determines angles, the amount of difference allowed between these similar keys may be large enough to create "duplicates".
Note that this doesn't mean that blackhats can duplicate your key, but they may be able to create a matching pair and swap yours with theirs in the middle of the night...