Exploit Found to Brick Most HP and Compaq Laptops 294
Ian Lamont writes "A security researcher calling himself porkythepig has published attack code that can supposedly brick most HP and Compaq laptops. The exploit uses an ActiveX control in HP's Software Update. It would 'let an attacker corrupt Windows' kernel files, making the laptop unbootable, or with a little more effort, allow hacks that would result in a PC hijack or malware infection.' The same researcher last week outlined a batch of additional vulnerabilities in HP and Compaq laptops, for which HP later issued patches."
Re:Argh (Score:3, Interesting)
Okay, "bricked" was the wrong word...but! (Score:5, Interesting)
Re:Argh (Score:5, Interesting)
A couple goes on vacation to a fishing resort. The husband likes to fish at the crack of dawn. The wife likes to read. One morning the husband returns after several hours of fishing and decides to take a short nap. Although she isn't familiar with the lake, the wife decides to take the boat. She motors out a short distance, anchors, and continues to read her book. Along comes the game warden in his boat. He pulls up alongside her and says,"Good morning, Ma'am, what are you doing?" "Reading my book," she replies, thinking isn't that obvious? "You're in a restricted fishing area," he informs her. "But officer, I'm not fishing. Can't you see that?" "Yes, but you have all the equipment. I'll have to take you in and write you up." "If you do that, I'll have to charge you with rape," says the woman. "But I haven't even touched you," says the game warden. "That's true, but you do have all the equipment."
The capability does not equal the crime, thankfully, so while you might put the laptop in a position it's brickable, it's not. Also, with dual bios's, bricking something like a laptop requires quite a bit of effort!
Re:Two points about the article's headline. (Score:5, Interesting)
Agree with both points. (Score:5, Interesting)
2) This hilights the dangers of any holes in a sandbox. The only secure way to design a sandbox is for there to be no mechanism from inside the sandbox to request access outside it... whether by installing a plugin, executing an external application, or otherwise elevating privileges. Even if the request is normally denied, the existince of that mechanism itself creates a new class of attacks.
The corollary to point two is that ActiveX is not just a security hole, it's a different *kind* of security hole.
On the other hand, all three of the most common browsers have a mechanism to request access outside the sandbox. None of them are as bad as ActiveX, but they're all unnecessary.
* Any browser on Windows is subject to URI quoting attacks on helper applications, due to the lack of a guaranteed quote-safe command line and the use of a single set of helper bindings for trusted and untrusted sources.
* LaunchServices on OS X duplicates the second problem as well.
* Firefox and Safari both allow web pages to request plugins be installed: XPI in Firefox and Dashboard plugins in Safari on OSX. They both wrap these interfaces in multiple levels of "approval dialogs", but my experience is that there are too many people who can be relied upon to eventually hit "go ahead and infect me" by reflex.
* Safari and Internet Explorer can both be made to, with various amounts of approval dialogs, open downloaded documents automatically. Safari used to do this by default but thankfully it's now an option... but really that capability should not be there at all.
None of these holes in the sandbox actually make things more convenient for users. They look like they might, but it's actually easier to download a document or a plugin and than (as a separate step) request that it be opened or installed from a file browser or from a download manager, because making the operation asynchronous and deliberate like that means you don't have to go crazy with approval dialogs, because you're not running the risk of an unexpected dialog coming up for a user with an itchy mouse button...
A theory... (Score:5, Interesting)
In defense of "brick" (Score:2, Interesting)
b) Brick clearly means more than "a small glitch in a basically working device," but "renders useless until a complete system re-install" doesn't seem too crazy; I've seen this use many times, esp. wrt gadgets whose firmware can be replaced with firmware. It's certainly used sometimes to refer to the kind of situation where (as here) the device becomes a doorstop until a complete new system image is installed.
You can choose to fixate on the word (hey, it's a free world!
And if anyone would like to argue some sort of Ur-grammar definition into "brick" in the hyper-recent use to refer to borked electronics, complain about how today's kids aren't true enough to their l447sp3@k roots, may I introduce the brick (older meaning) [xinhuanet.com].
Re:Two points about the article's headline. (Score:5, Interesting)
There was back in the days of DOS and ESDI, MFM, and early IDE drives, when it was the user's responsibility to run a drive head parking utility (properly configured for the right cylinder count for parking out past the edge of the drive) before physically moving the machine because auto-parking wasn't built into drives yet, a virus that did something really nasty. It'd take the cylinder count for your drive, cut that in half, set your park cylinder to that number, and tell the drive to park and shut down. The heads would move to the center of the platters, the spindle would slow down on its way to stopping, the air cushion between head and platter went away, and the heads plowed into the platters either then or when the drive would spin back up. I don't recall the name of this one.
Either of these could be considered bricking actual hardware, but you probably won't ever have to worry about Chernobyl and the other is obsolete.