Re: [Full-disclosure] Using hardware to attack software

["Forristal, Jeff" <jeff.forristal@xxxxxxxxx>]

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@xxxxxxxxx] 
Sent: Saturday, December 24, 2011 5:21 PM
To: Forristal, Jeff; full-disclosure@xxxxxxxxxxxxxxxxx
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/