I recall a story, probably from here in Canada, that a utility had to replace wind generators on remote sites with much more expensive solar panels, because "hunters" found the moving blades an irresistible target. (yes there are yahoos here too - you can find informal rifle ranges up logging roads. They're just a bit quieter and more polite
I have to wonder at the brains of someone who would try to shoot down a high-voltage transmission line, considering what might happen if they succeeded and the line landed anywhere near them, their truck or friends.
I'd like to see the actual paper, which doesn't seem to be linked. Do they mean 25 purchases to one location, or 25 purchases per delivery run?
Buses, by the way, have a similar problem. Buses have good energy efficiency when full and when going roughly from source to destination. They have terrible efficiency when they're running winding routes designed to cover as much area as possible, carrying few people. Which is the typical suburban bus situation.
The figure for 25 purchases refers to "25 orders delivered at the same time" This is from Plepy's paper "the grey side of ict" http://www.graduateinstitute.ch/aspd/wsis/DOC/200EN.PDF, which quotes a 1999 paper by G. Jönson, F. Orremo, C. Wallin and K. Ringsberg. Which I could not find
Not having the actual study, it's hard to say, but it seems like there's some big assumptions here.
http://www.theiet.org/factfiles/transport/unintended-page.cfm
Looks like it's a meta-study; it seems to quote this: http://is4ie.net/images/Matthews.pdf, quoted by someone else, which is a 2001 study from the US. Also this: http://onlinelibrary.wiley.com/doi/10.1162/108819802763471816/pdf - a study of online book retailing in Japan in 2001.
I may have got this all wrong, and there may be some new UK research I didn't find.
A rootkit as I understand is a software package run after one has got root. The intent of the rootkit is to hide the nefarious activity (IRC server, warez stash etc.) from the user or admin. LKM rootkits tell the kernel to ignore certain process id's, ip addresses etc. while old-style rootkits overwrite programs like ps, top, ls with modified ones.
A rootkit might contain a backdoor as part of the kit.
The situation appears to be exactly as described by Ksplice.
CVE-2010-3081 has been discussed on RedHat forums and elsewhere.
The Ac1db1tch3z exploit published on the full disclosure list http://seclists.org/fulldisclosure/2010/Sep/268
does indeed appear to contain a backdoor (0p3n1ng th3 m4giq p0rt4l).
From the comments, the vulnerability was found in 2008 and the exploit has been used by the author for some time, and may have been circulating in the underground. When the vulnerability was found and disclosed by Ben Hawkes, the exploit was published to a wider audience.
A number of sysadmins may well have run the exploit on their systems to prove to themselves that this was a real threat. In doing so they may unknowingly have left a backdoor.
More commonly, proof-of-concept exploits posted on full-disclosure lists are crafted by security researchers, do not contain backdoors, and are relatively easy to read. In this case, the disclosed exploit is crafted by a hacker, may well contain a backdoor, and is written with leetspeak runtime messages and obfuscated code.
I admit I do not fully understand the code in the exploit or in the detection tool, or indeed the nature of the backdoor. However, on a Fedora 9 system, running the detector says there is no backdoor. After the exploit is run, the detector says there is a backdoor, so
the exploit must have changed the state of the system in some way. The detector looks for 3 separate backdoors; the one on my
test system disappears after reboot. As I thought the fix was to update the kernel to a patched version, which requires a reboot, I'm not sure how the backdoor could survive. I do not see how having the backdoor is riskier than having an unpatched system.
I can say, though, that the vulnerability exists in stock kernels 2.6.25 - 2.6.36, and was back-ported by RedHat into 2.6.18 used
in RHEL 5 (hence CENTOS 5). As stated by others, an unprivileged user account is required in order to exploit the vulnerability, which exists only on 64-bit x86 systems which also can run 32-bit code. One published mitigation step, which does not require a reboot, is to disable 32-bit compatibility mode by writing into
Give up passwords, move to certificates, SSH keys, biometrics etc. It doesn't matter how good your password is, it's toast if someone grabs it off a hacked server/client/WiFi (BTW there's some Brazilian hackers busy installing trojan sshd everywhere they can get to).
Re. stupid website passwords, I've started generating random 20-char passwords and using FireFox to remember them (with a master password, of course). A bit of a pain moving between computers, I really need to get some secure sync scheme sorted out (they do exist)
The flow chart is a most thoroughly oversold piece of program documentation. -- Frederick Brooks, "The Mythical Man Month"
