Full Disclosure mailing list archives
Re: Using hardware to attack software
From: Gage Bystrom <themadichib0d () gmail com>
Date: Tue, 27 Dec 2011 14:30:42 -0800
Well for doing it right you pretty much just did. My main criticisms involved presentation of your work that I believed could wind up coining useless buzz words, proliferation of bad terminology, and enforcing incorrect paradigms. Your post here clarifies much of that, I just believe it should have been emphasized in the paper more as to avoid the chances of creating poor buzz words, bad terminology, etc. Perhaps refocusing the paper around some sort of 'driver vulnerability taxonomy', or as you said was intended 'overlooked/poorly understood driver attacks'. Something along those lines would have been closer to doing it right, if not nailed it. As is, the paper seems to focus on presenting the concept of utilizing hardware to beat software, when the meat of the paper is concerned with driver attack surfaces and what not. I hope that is clear as I sometimes have a bad habit of rambling. On Dec 27, 2011 1:57 PM, "Forristal, Jeff" <jeff.forristal () intel com> wrote:
Hi Gage, thanks for the feedback. Drivers certainly are a big player here, since they are the main interfacers [sic] to hardware along with BIOS and VMMs. There's also some corner-case stuff that talks to hardware like TXT ACMs, a la ITL's published SINIT work. Yes, the weaknesses live in the software. That's why the paper focused on the use of software-influenced hardware elements to facilitate an attack on (presumably more privileged) software. So your observation about 'hardware attacks' is correct, but that's not what the paper was about. Attacking the hardware directly ('hardware attacks') was claimed in the paper to be out of scope--it was always about attacking/reaching a vulnerability located in software. I believe the topic of hardware facilitated attacks is a conversation about attack surface (specifically the surface the driver exposes to the hardware), how much trust the driver gives to the hardware, and how it (is? may be?) a direction of attacks that is not as 'fortified' as other attack surfaces pointed in other directions. Drivers may expect to be attacked from above (i.e. the conceptual PC stack), but are drivers being designed and implemented to robustly withstand attacks coming from below? Should they? And I agree, 'hardware reflected injection' is not a new vulnerability. Neither is '2nd order injection.' But both of those terms provide additional context to the attack pattern & circumstances being used to reach a software weakness. My whitepaper was focusing on under-considered attacks, not new vulnerabilities specifically. Let me know if I mixed up the language somewhere--I had thought I had successfully preserved the distinction between attacks and vulnerabilities throughout. As for "doing it wrong," that's fair. What do you consider to be "doing it right"? Thanks, - Jeff -----Original Message----- From: Gage Bystrom [mailto:themadichib0d () gmail com] Sent: Saturday, December 24, 2011 5:21 PM To: Forristal, Jeff; full-disclosure () lists grok org uk Subject: Re: [Full-disclosure] Using hardware to attack software While it was slightly interested to read, and I do not doubt the intention of the whitepaper, I believe it to be nearly useless. All it is, as they say, is a 'call-to-arms' to add additional classification of vulnerabilities. Almost all of those attacks described are really driver attacks. The ones that were not driver attacks was malicious hardware.(wow I was really fighting myself on the grammar/word choice on that sentence, but I think it makes sense so screw it). I do believe that kernel/driver related vulnerabilities should have better classification in order to identify, exploit, and fix them better(much in the vein that classifying some code segment as an integer overflow aids working with memory corruption bugs); however, because almost all of those are driver bugs, a software issue, I believe they can hardly be considered 'hardware attacks'. One slight pet peeve is that 'hardware reflected injection' sounds just like a lame attempt to create a new buzzword. Saying that failure for hardware/drivers to sanitize malicious data that can lead to defects higher up, is like calling the failure to sanitize return values from nested functions leading to a buffer overflow a 'function reflected injection' vulnerability. I do not believe that 'function reflected injection' warrants a classification of it's own just as I believe that hardware blah blah deserves to be a classification of it's own. I still respect their intent, I just think this whitepaper is completely doing it wrong.
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Using hardware to attack software Forristal, Jeff (Dec 24)
- Re: Using hardware to attack software Gage Bystrom (Dec 24)
- Re: Using hardware to attack software Forristal, Jeff (Dec 29)
- Re: Using hardware to attack software Gage Bystrom (Dec 27)
- Re: Using hardware to attack software coderman (Dec 27)
- Re: Using hardware to attack software Forristal, Jeff (Dec 29)
- Re: Using hardware to attack software Gage Bystrom (Dec 24)
- Re: Using hardware to attack software coderman (Dec 27)
- Re: Using hardware to attack software Valdis . Kletnieks (Dec 27)