[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