similar to: [LLVMdev] Adding diversity for security (and testing)

On 26 August 2013 11:39, Stephen Crane <sjcrane at uci.edu> wrote: > Greetings LLVM Devs! > > I am a PhD student in the Secure Systems and Software Lab at UC > Irvine. We have been working on adding randomness into code generation > to create a diverse population of binaries. This diversity prevents > code-reuse attacks such as return-oriented-programming (ROP) by >

On 8/28/13 4:37 PM, Nick Lewycky wrote: > On 26 August 2013 11:39, Stephen Crane <sjcrane at uci.edu > <mailto:sjcrane at uci.edu>> wrote: > > Greetings LLVM Devs! > > I am a PhD student in the Secure Systems and Software Lab at UC > Irvine. We have been working on adding randomness into code generation > to create a diverse population of

On 08/28/2013 02:37 PM, Nick Lewycky wrote: > 1. I'm concerned about the deployment problem. I realize that being in > the compiler means you can transform the program in more exciting > ways, but it gives you a much worse deployment story than something > which modifies the program on disk like "prelink". Yes, definitely. Deployment is an issue which users will need

Hi Stephen, > Greetings LLVM Devs! > > I am a PhD student in the Secure Systems and Software Lab at UC > Irvine. We have been working on adding randomness into code generation > to create a diverse population of binaries. This diversity prevents > code-reuse attacks such as return-oriented-programming (ROP) by > denying the attacker information about the exact code layout.

On Aug 26, 2013, at 2:39 PM, Stephen Crane <sjcrane at uci.edu> wrote: > We have been working on adding randomness into code generation > to create a diverse population of binaries. This diversity prevents > code-reuse attacks such as return-oriented-programming (ROP) by > denying the attacker information about the exact code layout. Putting on my security hat (as opposed to

On Aug 26, 2013, at 11:39 AM, Stephen Crane <sjcrane at uci.edu> wrote: > I am a PhD student in the Secure Systems and Software Lab at UC > Irvine. We have been working on adding randomness into code generation > to create a diverse population of binaries. This diversity prevents > code-reuse attacks such as return-oriented-programming (ROP) by > denying the attacker

On Aug 28, 2013, at 1:50 PM, Paul Robinson <pogo.work at gmail.com> wrote: > On Mon, Aug 26, 2013 at 9:14 PM, Todd Jackson <quantum.skyline at gmail.com>wrote: > >> Personally, I think it is necessary to go for the strongest random number >> generator possible. Cryptographically secure pseudorandom number >> generators have good properties that make them

On 08/28/2013 12:01 PM, Stephen Checkoway wrote: > 2. Local attacker who cannot read the contents of the binary. (This is a pretty strange one, but it's possible.) The attacker is forced to rely on side channel information such as timing channels in an attempt to discover the length of the inserted NOP sleds. This sounds like an extraordinarily difficult task, but possibly doable. With a

On 29 August 2013 15:29, Stephen Crane <sjcrane at uci.edu> wrote: > On 08/28/2013 02:37 PM, Nick Lewycky wrote: > >> 1. I'm concerned about the deployment problem. I realize that being in >> the compiler means you can transform the program in more exciting ways, but >> it gives you a much worse deployment story than something which modifies >> the program

Awesome! Thanks so so much! I'm very interested in doing some work with compilers. Yeah, I'm considering writing a research proposal where I work for JIT-SFI, SFI Evasion Technique and Mitigation, and a few other things. Considering your experience working on modifying llvm, what would you say would be a topic where I could start out doing some good work on, either in a new direction or

> > We would also include a secure random number generator which links > > against OpenSSL. This would of course be an optional module disabled > > by default, but is necessary so the randomization is cryptographically > > secure and useful in security applications. > > I am not sure why you need this feature. You can provide LLVM with a > SEED value that can be

On Mon, Aug 26, 2013 at 9:14 PM, Todd Jackson <quantum.skyline at gmail.com>wrote: > > > We would also include a secure random number generator which links >> > against OpenSSL. This would of course be an optional module disabled >> > by default, but is necessary so the randomization is cryptographically >> > secure and useful in security applications.

Thanks for all the feedback! It seems there is some interest, so I thought I'd try to summarize discussions so far, and provide patches for closer inspection. I'm not sure if patches should end up here or on a different list in this instance, so if I should instead send this to a different list, I'm happy to do so. - Is diversity needed, or are existing protections sufficient? As

I read a lot of white papers, but is there not any open source implementation of SFI or artificial diversity? I google around, but I can't find anywhere anything regarding what I could openly download. In the same respect, I would also like to make an innovation proposal to create such an endeavor if there is not one already. -------------- next part -------------- An HTML attachment was

On 4 Nov 2014, at 00:36, Kostya Serebryany <kcc at google.com> wrote: > You at least increase the memory footprint by doubling the stack sizes. Not quite. The space overhead is constant for each stack frame - you just need to keep track of the top of two stacks, rather than one. The important overhead is that you reduce locality of reference. You will need a minimum of two cache

On Mon, Aug 10, 2020 at 3:34 AM David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > > Thanks, > > On 07/08/2020 23:28, Kees Cook wrote: > > On Fri, Aug 7, 2020 at 1:18 AM David Chisnall > > <David.Chisnall at cl.cam.ac.uk> wrote: > >> I think it would be useful for the discussion to have a clear threat model that this intends to defend against and

Hello, thank you very much for answering. I am trying to do the following: get the encoding for each instruction and if that encoding contains a C3 byte, insert a NOP instruction (or multiple NOP instructions, or any other instructions) before that instruction. The idea behind this is to protect against ROP (Return Oriented Programming) attacks. By inserting a NOP the attacker can no longer abuse

Nick, Thanks so much for such a detailed review. I definitely missed a few of the details of the LLVM standards. Sorry. Here's a new patch that should resolve the issues you pointed out. I've also included a few comments below -- anything I haven't replied to has been fixed. In particular, I'd like to discuss RNG seeding with the list. I currently use a static singleton to make

On Fri, Aug 7, 2020 at 1:18 AM David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > I think it would be useful for the discussion to have a clear threat model that this intends to defend against and a rough analysis of the security benefits that this is believed to bring. I view this as being even more about a ROP defense. Dealing with spill slots is, IMO, a separate issue, more

Hi, I have a basic machine function pass in this fashion: bool Foo::runOnMachineFunction(MachineFunction &Fn) { for (auto &BB : Fn) { for (MachineBasicBlock::iterator I = BB.begin(), E = BB.end(); I != E; ++I) { if (I->isPseudo()) continue; // inspect opcode of I here } } } return true; } As the comment suggests I want to inspect the