4 ms·

We've invested quite a bit of energy in static analysis tools over the years, but so far the return hasn't been there. There are still ongoing efforts, and we'l

We've invested quite a bit of energy in static analysis tools over the years, but so far the return hasn't been there. There are still ongoing efforts, and we'll see if those pan out, but up to this point we've just run into a very low hit rate and a false positive rate that drowns everything else out from a security perspective. Formal methods are a different question, but I can't imagine the size of the undertaking needed to convert even a subset of Chromium over to formal methods. Instead, we've focused pretty heavily on more conventional anti-exploit mitigations applied to existing C++ code. Our sandboxing is the most obvious one, but we have a variety of other protections on top of typical stuff like ASLR and NX (e.g. heap partitioning, a safe integer handling toolkit, etc). We're also leading efficient control-flow integrity work in clang, and busily working it up to a stable release. And then we have fuzzing as part of our continuous integration, running across thousands of cores of instrumented builds.

nickpsecurity 11y ago
Sorry to hear that. Yeah, they're not as strong for C++ yet as it's more complex and has less R&D in that sector. My idea for C++ would be to try to find or even encourage development of those that catch the interface and concurrency errors at the least. So, that's Design-by-Contract [1] [2] along with something like ConSeq [3] if it's available or usable for your build. D-by-C, done right, gets a lot of mileage w/ ConSeq showing promise. Do keep the exploit mitigation tech, though. The NaCl paper was one of best reads I had that year. Most interesting one right now is Code Pointer Integrity [4]. Curious, is there a configuration that swaps out the sandbox for something with the same interface but no real sandbox? Point is if we can swap out the existing sandbox (esp CFI) for a different technology (eg CPI, Softbound + CETS). [1] http://www.drdobbs.com/an-exception-or-a-bug/184401686 http://www.drdobbs.com/an-exception-or-a-bug/184401686 [2] http://www.codeproject.com/Articles/8293/Design-by-Contract-in-C http://www.codeproject.com/Articles/8293/Design-by-Contract-... [3] https://webcache.googleusercontent.com/search?q=cache:WZAQPu7dJgQJ:research.cs.wisc.edu/wpis/papers/asplos11.pdf+&cd=3&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:WZAQPu... [4] https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-kuznetsov.pdf https://www.usenix.org/system/files/conference/osdi14/osdi14...

nickpsecurity 11y ago

Sorry to hear that. Yeah, they're not as strong for C++ yet as it's more complex and has less R&D in that sector. My idea for C++ would be to try to find or even encourage development of those that catch the interface and concurrency errors at the least. So, that's Design-by-Contract [1] [2] along with something like ConSeq [3] if it's available or usable for your build. D-by-C, done right, gets a lot of mileage w/ ConSeq showing promise. Do keep the exploit mitigation tech, though. The NaCl paper was one of best reads I had that year. Most interesting one right now is Code Pointer Integrity [4]. Curious, is there a configuration that swaps out the sandbox for something with the same interface but no real sandbox? Point is if we can swap out the existing sandbox (esp CFI) for a different technology (eg CPI, Softbound + CETS). [1] http://www.drdobbs.com/an-exception-or-a-bug/184401686 http://www.drdobbs.com/an-exception-or-a-bug/184401686 [2] http://www.codeproject.com/Articles/8293/Design-by-Contract-in-C http://www.codeproject.com/Articles/8293/Design-by-Contract-... [3] https://webcache.googleusercontent.com/search?q=cache:WZAQPu7dJgQJ:research.cs.wisc.edu/wpis/papers/asplos11.pdf+&cd=3&hl=en&ct=clnk&gl=us https://webcache.googleusercontent.com/search?q=cache:WZAQPu... [4] https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-kuznetsov.pdf https://www.usenix.org/system/files/conference/osdi14/osdi14...