Re: Using hardware to attack software

["Forristal, Jeff" <jeff.forristal () intel com>]

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/