Message-ID: <CAM2Hf5kKZxeQVY2kd-NZSv=6BRNaA9MzEAG4ub5xLLyp0x1Ozg@mail.gmail.com>
Date: Tue, 27 Dec 2011 14:30:42 -0800
From: Gage Bystrom <themadichib0d@...il.com>
To: "Forristal, Jeff" <jeff.forristal@...el.com>, 
	"full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: Using hardware to attack software

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@...el.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@...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.
>
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists