2015-09-01 11:38 GMT+08:00 John Criswell <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 anycomplete program to show that cfi can protect control flow? It's just a basic theory display, not academic paper!> 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.> 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. - mudongliang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150901/09ae4821/attachment.html>
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>
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