[llvm-dev] llvm cfi

mudongliang via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 1 07:41:12 PDT 2015



On 09/01/2015 09:44 PM, John Criswell wrote:
> On 9/1/15 1:10 AM, 慕冬亮 wrote:
>>
>>
>> 2015-09-01 11:38 GMT+08:00 John Criswell <jtcriswel at gmail.com
>> <mailto:jtcriswel at gmail.com>>:
>>
>>     On 8/31/15 10:43 PM, 慕冬亮 via llvm-dev wrote:
>>>     I want to create an experiment to show the effectiveness of cfi : 
>>>     For example , 
>>>     I first need a program with vulnerability so that we can hijack
>>>     its control flow;
>>>
>>>     then I enforce cfi of llvm and we can't hijack its control flow.
>>>
>>>     Do you have any advice for me?
>>
>>     The CFI implementation we updated to work with x86-64 for the
>>     KCoFI project is available at
>>     <https://github.com/jtcriswell/SVA>https://github.com/jtcriswell/SVA. 
>>     You'll need to create the exploit code (and potentially the
>>     vulnerability) yourself.  If you read the literature on CFI and
>>     memory safety (some of which is cataloged at
>>     http://sva.cs.illinois.edu/menagerie), you should be able to find
>>     programs and vulnerabilities that have been used in such experiments.
>>
>> I think there are lots of program fragment in the literature. Is there
>> any complete program to show that cfi can protect control flow? 
>> It's just a basic theory display, not academic paper!
> 
> I'm pretty sure that some of the academic papers try out CFI on real
> vulnerabilities in real programs.  You will simply need to read through
> them to figure out what exploits they tried and on which programs they
> tried them.
> 
> For example, the Out-of-Control paper from the 2014 IEEE Security and
> Privacy Symposium shows how to do an attack against a CFI system.  If I
> recall correctly, they do a real exploit on a real program.  The same is
> true for the "Hacking in the Blind" paper from the same conference.
> 
> Something else you might want to check out is Code Pointer Integrity. 
> The source code is publicly available, and it's built using LLVM.  The
> paper was in OSDI 2014 and most likely contains a URL for getting the
> source code.  Code Pointer Integrity is, in a way, CFI on steroids.

I have heard those two papers(Hacking Blind,CPI), Out-Of-Control is
fresh. I will check those papers and find out the experiment on real
programs.
Thank you for your tips.
> 
>>  
>>
>>     That said, doing an experiment will not show that CFI is
>>     effective; it will only show that CFI stops that one particular
>>     attack that you are demonstrating.  While this was done in past
>>     research papers, it was only done because it was one of the few
>>     methods of evaluating CFI available.  More recent work is showing
>>     the deficiencies of evaluating CFI in this way (in a nutshell,
>>     simple CFI defenses can be thwarted).
>>
>>     Determining how to measure the effectiveness of defenses against
>>     code-reuse attacks (such as Return-Oriented programming, Return to
>>     Libc attacks, and Non-Control data attacks)
>>
>> I don't think Non-Control data attacks is a kind of code-reuse attack.
>> It is better to call it Data-Oriented attacks.
> 
> Actually, it is, though it may not be obvious.  A non-control data
> attack changes the data on which instructions compute without injecting
> new instructions or modifying the control data.  Therefore, the attack
> is reusing the existing code but feeding that code corrupted data as
> input.  Ergo, non-control data attacks are code reuse attacks.
> 
I think code reuse attack means using the existing code not normally,
especially like ROP. It use density of intel instruction. It always
needs break control flow integrity I think.
But non-control data will use the existing code normally. It will lose
lots of controls enforced by many defenses.
I think you can refer PaX document:
   these techniques can affect the attacked task at three
   different levels:

 (1) introduce/execute arbitrary code
 (2) execute existing code out of original program order
 (3) execute existing code in original program order with arbitrary data

code-reuse attack should be in (2), and non-control data attack should
be (3). And the final attack topic must in (3).

	- mudongliang


More information about the llvm-dev mailing list