[LLVMdev] [PROPOSAL] Adding support for -fstack-protector-strong

[Magee, Josh]

At 1349203977 seconds past the Epoch, John Criswell wrote:
> If you're looking for a project to learn about LLVM and Clang, then I 
> think this is a great project.  If the LLVM  /Clang community wants this 
> feature so that it is feature-compatible with GCC, then I think 
> including this feature into LLVM/Clang makes sense.

Yes, this is one reason - it seems like a reasonable project to get more
involved with the LLVM and Clang community.  The other reason is that
this feature has been requested by developers at my place-of-work.

> 
> If you want to protect applications from attack, then I think there are 
> far more productive and interesting things to work on than stack 
> protectors.  Stack protectors are really a hack and, at best, only 
> protect against a single kind of attack (and with buffer overread 
> attacks, I'm not even sure if they do that very well).  Even if they 
> work against stack buffer overflows, stack protectors don't protect the 
> application from heap overflows, invalid free attacks, dangling pointer 
> attacks, and non-control data attacks.

I agree: Stack protectors only protect against one very specific kind of attack.

> 
> The fastest countermeasure that I think is worth looking at is Control 
> Flow Integrity (CFI); CFI adds checks to return instructions and 
> indirect jumps to ensure that they're jumping to a valid target 
> address.  As far as I know, there's no control-hijack attack that works 
> against it, although non-control data attacks are still possible.  The 
> fastest CFI implementation at present has an average overhead of 7.74% 
> on 32-bit x86, and by using a very conservative callgraph, you can use 
> it without whole program analysis.  I've got the LLVM implementation 
> from the authors at LeHigh and am updating the code for x86_64 and LLVM 
> 3.1 for use in one of my research projects.  If you're interested in the 
> code, I can ask them if they'd be willing to release the code as 
> open-source.

This sounds quite interesting - I'll definitely do some investigation into CFI.
If the authors are willing to release the source code as open-source
that would be great.

> Optimizations for memory safety tools like ASan, SAFECode, and SoftBound 
> would be even better since they also stop non-control data attacks.  
> Getting good performance out of them is difficult, though, and depending 
> on what sorts of overhead you're willing to tolerate, getting good 
> performance is still an open research question.
> 
> You might want to check out the memory safety menagerie 
> (http://sva.cs.illinois.edu/menagerie).  It has lots of papers on 
> various techniques and optimizations for those techniques.  You might 
> find something that will give you the security you want at the 
> performance you need.
> 
> In short, I think working on something that provides more comprehensive 
> protection is better than working on a partial hack.
> 
> My two (maybe four?) cents.

Thanks for the input.  I agree that there are better security techniques
and countermeasures than SSP.  At the end of the day SSP-strong is still
something I want to implement.  Still, you have given me some food for
thought and a number of interesting tools and techniques to explore.

- Josh