[llvm-dev] llvm cfi

[John Criswell via llvm-dev]

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

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

>     is an active area of research.  My students and I are working to
>     devise methods of evaluating defenses, but as the work is in its
>     very early stages, that's all I can say about it at present.
>
> This is an interesting topic I think.
> Thank you for your reply.

Thank you.

Regards,

John Criswell

-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150901/934f6328/attachment.html>