full-disclosure - Re: Using hardware to attack software

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <E5F2DA89AC9B40438C9049B666781D9925697E50@ORSMSX102.amr.corp.intel.com>
Date: Tue, 27 Dec 2011 21:57:35 +0000
From: "Forristal, Jeff" <jeff.forristal@...el.com>
To: Gage Bystrom <themadichib0d@...il.com>,
	"full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Using hardware to attack software

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