Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSL after Heartbleed

lwn.net

Post reply on HN
Print view View original

71–80 of 80 posts

Re: OpenSSL after Heartbleed

#71

Post by nickpsecurity »

duneroadrunner wrote: post #66
nickpsecurity wrote: post #44

Earlier quoted context omitted.

I'll add that SAFEcode and Softbound+CETS automatically make C programs memory-safe against lots of problems. There was also the Clay language that could've been updated. C0 is a subset that was easier to verify used in Verisoft's microkernel and apps. Rod Chapman found an error in reference implementation recoding it in SPARK Ada. So that could be used. All kinds of things could solve the C-level problems or substit…

SAFEcode and Softbound+CETS would be ideal, but seem to have a few problems in practice. First, the resulting executables are apparently quite slow. Like several times slower that executables compiled normally. The sanitizers are much faster, but even so the "address sanitizer" alone has a 2x performance cost. The other problem with SAFEcode and Softbound+CETS is that they don't always work. The TOR project tried to…

"Like several times slower that executables compiled normally. "

That's usually true if it's a naive scheme for safety. The main benefit of clever ones like Softbound+CETS or SAFEcode is they try to optimize away a lot of that. The first, SAFEcode paper reported worst-case of 30% overhead in their tests. SVA-OS overhead was mostly well under 2x with a few cases that did 2-4x. I can't remember what the S+C was. Remember that these also knock out almost every root cause of code injections in C apps with SVA-OS covering whole Linux kernel. Might be worth buying a second CPU to cover the overheads. ;)

"The TOR project tried to build firefox using them, but they couldn't successfully build it"

I wasn't aware of that. Thanks for telling me. Shows some work needs to be done. Would've been nice if they were more specific than "they didn't work." I was holding off on applying them to Tor anyway since such services must do covert-channel analyses. I'm not sure what effect these techs have on that. I recommended redoing it in SPARK Ada with Kemmerer's method for covert channel analysis.

"And I think SaferCPlusPlus is now a more practical "some code modification required" solution than previous alternatives."

I disagree. The reason is that there's way more tooling for statically analyzing, verifying, certifying object code of, and so on for C programs. Very little for C++ in comparison. So, taking up C++ gives you the few measures of safety it provides while forgoing tech you can get in C such as Astree Analyzer or CompCert. Too much a sacrifice. People stuck in legacy codebases might want to apply or improve on Ironclad, though.

http://acg.cis.upenn.edu/papers/ironclad-oopsla.pdf

https://github.com/crdelozier/ironclad

Re: OpenSSL after Heartbleed

#72

Post by mSparks »

duneroadrunner wrote: post #66
nickpsecurity wrote: post #44

Earlier quoted context omitted.

I'll add that SAFEcode and Softbound+CETS automatically make C programs memory-safe against lots of problems. There was also the Clay language that could've been updated. C0 is a subset that was easier to verify used in Verisoft's microkernel and apps. Rod Chapman found an error in reference implementation recoding it in SPARK Ada. So that could be used. All kinds of things could solve the C-level problems or substit…

SAFEcode and Softbound+CETS would be ideal, but seem to have a few problems in practice. First, the resulting executables are apparently quite slow. Like several times slower that executables compiled normally. The sanitizers are much faster, but even so the "address sanitizer" alone has a 2x performance cost. The other problem with SAFEcode and Softbound+CETS is that they don't always work. The TOR project tried to…

"Safe/Secure" code - by definition must be slower than unsafe code.

Because every operation must pass over a series of hurdles to make sure it is safe. - does the code have permission to do this, is everything being supplied within bounds, is the system in a stable state.

Every language is about the same with all these checks in place. In fact C is quite possibly slower, because so many of the memory jumps will be so far away, and compilers are much better at optimising for this than people.

In my opinion not having these checks is only acceptable when the permissions of all developers and all users - potential and actual are identical. While there are rare cases this is true, much to many developers chargrin, in nearly every case it is not.

The whole point of SSL is that developers, users and users of the users permissions are totally different.

Re: OpenSSL after Heartbleed

#73

Post by pjmlp »

sidlls wrote: post #64
pjmlp wrote: post #55

Earlier quoted context omitted.

You are right, but any systems programming language that comes from the Algol or ML family doesn't suffer from "every line of code is a possible memory corruption" that C and its derivatives suffer from. Rust or any other memory safe systems programming languages don't make all type of programming errors go away, but at least they make the memory corruption ones less likely to happen. Also most of the C tools that he…

I mostly agree. However I have this prediction: if Rust gains popularity, then in 5-10 years (or perhaps fewer!) someone will be complaining about memory issues in a Rust library that is peppered with "unsafe" blocks that don't properly respect the safe/unsafe boundary contract. Even the core under-the-hood Rust std library is a human-vetted set of unsafe code that the compiler simply cannot prove as much about as Sa…

Which is why on those languages most compilers have the option to turn unsafe blocks usage into compiler errors.

Which is something impossible in C, where even using plain vectors, strings or doing arithmetic requires unsafe code.

It is easier to vet lets say 10% of the code than 100%.

Re: OpenSSL after Heartbleed

#74

Post by duneroadrunner »

nickpsecurity wrote: post #71
duneroadrunner wrote: post #66

Earlier quoted context omitted.

SAFEcode and Softbound+CETS would be ideal, but seem to have a few problems in practice. First, the resulting executables are apparently quite slow. Like several times slower that executables compiled normally. The sanitizers are much faster, but even so the "address sanitizer" alone has a 2x performance cost. The other problem with SAFEcode and Softbound+CETS is that they don't always work. The TOR project tried to…

"Like several times slower that executables compiled normally. " That's usually true if it's a naive scheme for safety. The main benefit of clever ones like Softbound+CETS or SAFEcode is they try to optimize away a lot of that. The first, SAFEcode paper reported worst-case of 30% overhead in their tests. SVA-OS overhead was mostly well under 2x with a few cases that did 2-4x. I can't remember what the S+C was. Rememb…

Not my area of expertise, but a little googling yields:

"SAFECode performance was reduced on average by a factor of 41.72 times, and the average slowdown for SoftBound was 5.36 (that is, a program runs 5.36 times slower with bounds checking than without it)." [1]

As for the C versus C++ question, I don't take a position on that. The practicality of sticking with straight C (or some subset) will vary by project. SaferCPlusPlus just introduces a memory-safe subset of C++ as an option. But a subset that doesn't require the re-architecting of existing C/C++ code as it provides safe compatible substitutes for C/C++'s unsafe elements.

> People stuck in legacy codebases might want to apply or improve on Ironclad, though.

SaferCPlusPlus only exists because Ironclad was/is not a practical solution. In particular because Ironclad is abandonware. In my opinion, Ironclad was a brilliant and impressive solution. SaferCPlusPlus strives to be a solution in the same vein, but one that takes advantage of modern C++ in its implementation. The non-viability of Ironclad exposed key problems shared with many other approaches. Namely, portability and, more importantly, dependency risk. SaferCPlusPlus is just a simple open source library written in pure, portable C++. It works on any platform with a reasonably modern C++ compiler. If you adopt it and at some point in the future it becomes abandonware, there is no risk to your project. It will continue to build properly, and the code won't be stuck with some idiosyncratic paradigm that will interfere with future coding strategies. And the library is simple enough that it should be fairly easy to add new features or customizations as needed.

[1] https://www.semanticscholar.org/paper/Performance-of-Compile...

Re: OpenSSL after Heartbleed

#75

Post by nickpsecurity »

duneroadrunner wrote: post #74
nickpsecurity wrote: post #71

Earlier quoted context omitted.

"Like several times slower that executables compiled normally. " That's usually true if it's a naive scheme for safety. The main benefit of clever ones like Softbound+CETS or SAFEcode is they try to optimize away a lot of that. The first, SAFEcode paper reported worst-case of 30% overhead in their tests. SVA-OS overhead was mostly well under 2x with a few cases that did 2-4x. I can't remember what the S+C was. Rememb…

Not my area of expertise, but a little googling yields: "SAFECode performance was reduced on average by a factor of 41.72 times, and the average slowdown for SoftBound was 5.36 (that is, a program runs 5.36 times slower with bounds checking than without it)." [1] As for the C versus C++ question, I don't take a position on that. The practicality of sticking with straight C (or some subset) will vary by project. Safer…

re SAFEcode/Softbound. That's horrific vs the initial numbers. Good that they dug in to find most of it was in the bookkeeping. Work there might greatly reduce the overhead. That MPX is a Softbound-like scheme with hardware extensions for bookkeeping is already hopeful. Author needs to port it to MPX. Paper also mentions Ironclad C++.

"SaferCPlusPlus just introduces a memory-safe subset of C++ as an option."

True. This has at least basic benefit.

" Namely, portability and, more importantly, dependency risk."

What was the portability issue?

"there is no risk to your project. It will continue to build properly, and the code won't be stuck with some idiosyncratic paradigm that will interfere with future coding strategies. "

This would be a good selling point to enterprise customers or large FOSS projects that use C++.

Re: OpenSSL after Heartbleed

#76

Post by duneroadrunner »

nickpsecurity wrote: post #75
duneroadrunner wrote: post #74

Earlier quoted context omitted.

Not my area of expertise, but a little googling yields: "SAFECode performance was reduced on average by a factor of 41.72 times, and the average slowdown for SoftBound was 5.36 (that is, a program runs 5.36 times slower with bounds checking than without it)." [1] As for the C versus C++ question, I don't take a position on that. The practicality of sticking with straight C (or some subset) will vary by project. Safer…

re SAFEcode/Softbound. That's horrific vs the initial numbers. Good that they dug in to find most of it was in the bookkeeping. Work there might greatly reduce the overhead. That MPX is a Softbound-like scheme with hardware extensions for bookkeeping is already hopeful. Author needs to port it to MPX. Paper also mentions Ironclad C++. "SaferCPlusPlus just introduces a memory-safe subset of C++ as an option." True. Th…

One of the sanitizer guys tested the mpx instructions on skylake [1]. Tl;dr - Kind of underwhelming. But then, skylake is just the first iteration.

> What was the portability issue?

Oh, it was a long time ago that I investigated it and I don't remember the details very clearly, but for one, I needed a solution that supported Windows. Either it didn't support Windows, or its support for Windows was obsolete or something. I don't really remember. And iirc, it used assembly code and platform specific hacks to try to determine if an object was allocated on the stack or not. Yeah, I don't really remember the details, but it wasn't my intention to develop SaferCPlusPlus. If I could've gotten Ironclad to work for me, I probably would've been happy with that.

> This would be a good selling point to enterprise customers

Yeah, unfortunately I'm not selling anything, otherwise there would be marketing budget :)

[1] https://github.com/google/sanitizers/wiki/AddressSanitizerIn...

Re: OpenSSL after Heartbleed

#77

Post by nickpsecurity »

duneroadrunner wrote: post #76
nickpsecurity wrote: post #75

Earlier quoted context omitted.

re SAFEcode/Softbound. That's horrific vs the initial numbers. Good that they dug in to find most of it was in the bookkeeping. Work there might greatly reduce the overhead. That MPX is a Softbound-like scheme with hardware extensions for bookkeeping is already hopeful. Author needs to port it to MPX. Paper also mentions Ironclad C++. "SaferCPlusPlus just introduces a memory-safe subset of C++ as an option." True. Th…

One of the sanitizer guys tested the mpx instructions on skylake [1]. Tl;dr - Kind of underwhelming. But then, skylake is just the first iteration. > What was the portability issue? Oh, it was a long time ago that I investigated it and I don't remember the details very clearly, but for one, I needed a solution that supported Windows. Either it didn't support Windows, or its support for Windows was obsolete or somethi…

I didn't realize you developed SaferCPlusPlus or that it was an actual thing. I don't follow C++ anymore past what I see in a few forums. I mistakenly thought you were referring to attempts at standardization of safer stuff that they were calling Safer C++ or something in prior articles. So, you actually learned from projects like Ironclad then tried to do it simpler and better in your own project that you coded up. Great attitude and work!

"And iirc, it used assembly code and platform specific hacks to try to determine if an object was allocated on the stack or not."

My plan was to get some academics with an appreciation for making money to dig into it for non-sense like that, test its mechanisms, clean it up, and put in a concurrent, low-latency scheme for dynamic stuff. Then test it against common compilers and FOSS codebases before marketing it to companies to get some safety in various apps. :)

Of course, I have limited influence in current condition and you have no marketing budget for yours. Progress on Great Change stalls once again. Least you're keeping at your own project that might turn into something later.

Re: OpenSSL after Heartbleed

#78

Post by DasIch »

mSparks wrote: post #72
duneroadrunner wrote: post #66

Earlier quoted context omitted.

SAFEcode and Softbound+CETS would be ideal, but seem to have a few problems in practice. First, the resulting executables are apparently quite slow. Like several times slower that executables compiled normally. The sanitizers are much faster, but even so the "address sanitizer" alone has a 2x performance cost. The other problem with SAFEcode and Softbound+CETS is that they don't always work. The TOR project tried to…

"Safe/Secure" code - by definition must be slower than unsafe code. Because every operation must pass over a series of hurdles to make sure it is safe. - does the code have permission to do this, is everything being supplied within bounds, is the system in a stable state. Every language is about the same with all these checks in place. In fact C is quite possibly slower, because so many of the memory jumps will be so…

This isn't true at all. The language has an impact on whether you can make perform these checks at runtime or at compile time. If you can do them at compile time, performance isn't affected at all and the code won't run slower.

Re: OpenSSL after Heartbleed

#79

Post by nickpsecurity »

DasIch wrote: post #78
mSparks wrote: post #72

Earlier quoted context omitted.

"Safe/Secure" code - by definition must be slower than unsafe code. Because every operation must pass over a series of hurdles to make sure it is safe. - does the code have permission to do this, is everything being supplied within bounds, is the system in a stable state. Every language is about the same with all these checks in place. In fact C is quite possibly slower, because so many of the memory jumps will be so…

This isn't true at all. The language has an impact on whether you can make perform these checks at runtime or at compile time. If you can do them at compile time, performance isn't affected at all and the code won't run slower.

"If you can do them at compile time, performance isn't affected at all and the code won't run slower."

That's not universally true. Compiler people tell me some optimizations happen using undefined behavior. Personal experience shows some, esp hand-optimized assembly, rely on stuff that a static analyzer just couldn't handle. These are common in compression, encryption, and multimedia libraries. So, you indeed might sacrifice performance writing code in a language that can knock out all kinds of problems at compile time working within the coding style it needs to do that.

In the general case, though, your point holds so far as lots of problems can be knocked out at compile time without affecting performance enough for the user to care.

Re: OpenSSL after Heartbleed

#80

Post by vtlynch »

LukeShu wrote: post #41
vtlynch wrote: post #33

Earlier quoted context omitted.

The first date that Archive.org has that page is August 2015, after heartbleed. Do you know for sure that they offered this service before heartbleed?

Yes. https://web.archive.org/web/20120805001248/http://www.openss... August 2015 is just when they did a website redesign, which caused some URLs to change.

Good find. This is an excellent question. Knowing how much OpenSSL made through this is certainly important.
Post reply on HN