10 ms·

My first reaction: This never ends, does it? Second reaction: Security is notoriously hard, nice that people are looking at the code and being thorough, it's fo

My first reaction: This never ends, does it? Second reaction: Security is notoriously hard, nice that people are looking at the code and being thorough, it's for the collective best.

deleted 10y ago
[deleted]
hannob 10y ago
What never ends? Low severity memory safety bugs in a large C codebase? Probably not. You may think this is a lot. It's not. This largely appears a lot because OpenSSL treats a lot of very low impact issues as vulnerabilities. A lot of other projecs would rather start arguing that this is not exploitable, should never get a CVE etc. This is a good sign. OpenSSL is taking security seriously by treating even low impact things as vulns. More severe stuff still happens, but I'm pretty positive there is a decline in severe issues.
- nine_k 10y ago
  Exactly. With C, it will effectively never end. Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Tools Of similar nature for C do exist, but probably they are harder to apply, and likely not free.
  - bjourne 10y ago
    It won't end with Rust either since it is so appealing and easy to jump into unsafe territory.
    - mbrock 10y ago
      This kind of resource DoS attack doesn't seem like it's directly related to safe/unsafe. I think you would be just as likely to forget to put a resource limit if you were writing in Haskell.
    - danarmak 10y ago
      Easy is not the same as necessary. At least high-security projects like OpenSSL could enforce a policy of not using unsafe code, and it's easy to validate that there's no unsafe code or that the few known instances are very well vetted.
      - bjourne 10y ago
        You could do the same with C code -- it is getting everyone to follow the policies that is the hard part. Even compiling Rust code in release mode instead of debug removes some essential safety features. Should be clear by now that "policies" just doesn't work, but no, project are repeating the exact same mistake over and over again. :)
        danarmak 10y ago
        The crucial difference is between a policy, which people can not follow (and you might not catch them), and a language or compiler restriction, which people can't work around without doing something drastic like shelling out to a new process, which you can catch (in a well built language).
        rustywut 10y ago
        But Rust is ugly and C is beautiful. Why would someone want to work in an ugly language all day?
        danarmak 10y ago
        Is the beauty you see in C inseparable from its unsafety? Are the unsafe parts that other languages don't have the most beautiful ones? There's a big difference between arguing for safety and arguing for Rust specifically. Everyone likes some languages and dislikes others. Can you design a safe(r) language that you would consider to be beautiful?
        rustywut 10y ago
        Your points seem valid, I don't know why you're getting downvoted. Butt hurt Rust lovers I guess?
    - Manishearth 10y ago
      > so appealing and easy to jump into unsafe territory. I've almost never seen unnecessary unsafe code being used in Rust. I've seen it very few times for performance, but it's carefully done.
    - rustywut 10y ago
      If Rust is performant, why does it need unsafe code?
  - fredmorcos 10y ago
    I hope I don't come across too harsh. Is HN still really up for that argument? Yes, we know the downsides of C. But the upside is that _we know the downsides of C_. Constantly complaining about C isn't going to get anyone anywhere. It's been shown over and over again that secure C coding is possible and doable and feasible and exists in the real world. Some of the most secure software is written in C, and that's not attributed to enough fingers banging at a keyboard over a C program, but because C forces the programmer that _wants_ to write a secure program think about all the issues, the universe and everything. So please, pave the road and show us the safer OpenSSL-rust you have. Until then good luck and thank you for your feedback.
    - jerf 10y ago
      It's not Rust, but: https://golang.org/pkg/crypto/tls/ https://golang.org/pkg/crypto/tls/ I know it says "partial" implementation, but it's quite good even so, and has had everything I need. It doesn't do SSLv2, but nowadays that's more virtue than vice. Erlang has an independent SSL implementation as well; it binds to OpenSSL but as I understand it just uses the heavy-duty math parts, not the protocol parts, which are instead written in Erlang. Non-C SSL implementations in memory-safe languages exist. Note that "but are they as well road-tested" or similar such things would be moving the goal posts. Not necessarily wrong or bad objections, but different objections. Probably nothing, not even the other C implementations, is as well "road tested" as OpenSSL, but, then again, OpenSSL hasn't exactly passed that road testing with flying colors now, has it?
      - fredmorcos 10y ago
        (Just my opinion) I completely agree with everything you point out. The argument I am bringing up is not about implementation, it's about "if they didn't use C, they would have less (security) problems": No. C is the way it is towards secure coding because there are compromises to satisfy other dimensions. <Fancy new language that promises to solve all of C's problems> is either making huge sacrifices in these other dimensions or is at best an experiment. We understand C's weak points so well (due to being widespread, battle tested, really simple, or what have you), that most of the time it's safer (read: more secure) to tread dangerous well-understood territories carefully than uncharted ones only promising to be safe.
  - caf 10y ago
    Is the "Severity: High" issue here the kind of thing that would be caught by Rust's static analysis, though? The bug isn't a case where the language rules are broken, but rather a failure to set a reasonable limit on the resource consumption that a client can cause.
  - josefx 10y ago
    > Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Wont help when developers then go out of their way to write a large amount of unsafe code. OpenSSL went out of its way to reimplement the C standard library wrong, making it impossible to use with analysis tools like valgrind or a checked malloc and generally confusing developers. iirc it even used malloc(pop)/ free(push) as a stack to pass data around at some point.
  - ninja-wannabe-7 10y ago
    It's too easy to just blame C, it's their slap-dash, design-by-committee kitchen-sink features, lack of process, absense of rigor and generally amateurish "engineering," if it can be called that, of a now critical security framework. Why isn't every release first run through valgrind tools and some commercial C bug-finding tools used by embedded / safety-critical systems and why aren't there proofs of it's correctness? They have and/or could get the money/resources.
- deleted 10y ago
  [deleted]
- dimino 10y ago
  OpenSSL considers this a "high" severity issue.
easytiger 10y ago
What never ends? Dramatic over reaction for the ske of internet prosthelytising
barkingcat 10y ago
Why would it end? There is no perfect software if that's what you're looking for.
cm3 10y ago
Short answer: unlikely to end anytime soon, but likely that we start to focus on higher level bugs more than lower level issues. Long answer: If Unix and C hadn't won the fight in the 1980s like VHS did, we wouldn't deal with such low-level bugs. It took 30 years, but we're finally getting CPUs (like lowRISC) that were inspired by BS5000 or i960 and the languages to go with it are getting mainstream. To be fair, had we as an industry taken security more seriously decades ago, we would have written critical pieces of the stack in a high-assurance Ada profile, and put microkernel design capability kernels into production. We can extend 1960s kernel designs with all kinds of features, but without a coherent design it's impossible to provide the same assurance. This is why it's great that we have L4 descendants that incorporate a capability scheme and also support a multikernel scheme (ala Barrelfish) for making better use of a cluster of cpu cores.
- sitkack 10y ago
  We can't burn the world down and remake it. These things WILL happen over time, the next generations definitely are focused on safety and correctness. 1 we need to remove unsafe-machismo for the landscape, vector that energy into correctness instead of living with danger. 2, we need to figure out how to partition, segment, wrap the unsafe legacy stuff into a safe operating regime. The single biggest win is if we could load a library in another process and make cross-process calls to it.
  - ygjb-dupe 10y ago
    > The single biggest win is if we could load a library in another process and make cross-process calls to it. What? Setting aside the fact that this can already be done in numerous different ways on many platforms, how is this a win? It's hard enough for developers to write correct code, let alone maintaining the correctness of that code while loading and executing unknown code from other parties (see web browsers, and the last 20 years of security bugs related to plugins, extensions, addons, etc).
    - sitkack 10y ago
      The user should be able to load 3rd party libraries in out of process sandboxes, transparently for applications which weren't written with that in mind. I am not asking for new programmer features, new end user / sys admin features in the loader.
adekok 10y ago
I maintain a project (http://freeradius.org http://freeradius.org) which a similar amount of code, and (arguably) similar complexity. While we've had issues, they aren't as numerous as OpenSSL. And, the issues in the latest major version are negligible. Why? We have a requirement for code quality. The code can't just work, it has to make sense. The OpenSSL people don't seem to care about badly formatted and/or non-understandable code. All commits MUST build cleanly without warnings on multiple operating systems, and under multiple compilers. We have test cases for a large chunk of the code base. We scan all releases through three different static analysis tools. Security is important. We make it important because we care. I wish other projects would do the same.
- cortesoft 10y ago
  I would posit another reason you don't have as many issues; you don't have as many people trying to find them. I think it is pretty foolhardy to assume that just because security issues haven't been found means they don't exist.
  - ultramancool 10y ago
    There's definitely some truth to this, FreeRADIUS is just not that valuable of a target since not many people have RADIUS exposed to the world, however if you look at other highly valuable targets like OpenSSH, which is probably in the top 10 if not the most valuable target in the world, you see far fewer significant exploits. It's definitely possible to have better quality than OpenSSL and a lot of OpenSSL's issues are due to legacy code and what amount to experiments being run in production software.
    - adekok 10y ago
      For the record, the fixes for that CVE contain new CVEs. https://www.openssl.org/news/secadv/20160926.txt https://www.openssl.org/news/secadv/20160926.txt <sigh> No one can reasonably say that the practices of the OpenSSL programmers result in secure code. No one can reasonably say that lots of people examining it later for defects is a good idea. We have lots of legacy code in C. The only sane way to maintain it is tests: unit tests, functional tests, and static code analysis. > a lot of OpenSSL's issues are due to legacy code i.e. the OpenSSL people don't care to actively maintain / clean up their software. What a depressing statement to make.
throwaway12344 10y ago
If you don't know what you're talking about, please refrain from commenting. It only proves your ignorance. In the Rails land (as your profile says you are), you wouldn't have these issues, and quite frankly these types of thing seem to be beyond you at this point. You're in no position to criticize the OpenSSL project.

My first reaction: This never ends, does it? Second reaction: Security is notoriously hard, nice that people are looking at the code and being thorough, it's for the collective best.

deleted 10y ago

[deleted]

hannob 10y ago

What never ends? Low severity memory safety bugs in a large C codebase? Probably not. You may think this is a lot. It's not. This largely appears a lot because OpenSSL treats a lot of very low impact issues as vulnerabilities. A lot of other projecs would rather start arguing that this is not exploitable, should never get a CVE etc. This is a good sign. OpenSSL is taking security seriously by treating even low impact things as vulns. More severe stuff still happens, but I'm pretty positive there is a decline in severe issues.

nine_k 10y ago
Exactly. With C, it will effectively never end. Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Tools Of similar nature for C do exist, but probably they are harder to apply, and likely not free.
- bjourne 10y ago
  It won't end with Rust either since it is so appealing and easy to jump into unsafe territory.
  - mbrock 10y ago
    This kind of resource DoS attack doesn't seem like it's directly related to safe/unsafe. I think you would be just as likely to forget to put a resource limit if you were writing in Haskell.
  - danarmak 10y ago
    Easy is not the same as necessary. At least high-security projects like OpenSSL could enforce a policy of not using unsafe code, and it's easy to validate that there's no unsafe code or that the few known instances are very well vetted.
    - bjourne 10y ago
      You could do the same with C code -- it is getting everyone to follow the policies that is the hard part. Even compiling Rust code in release mode instead of debug removes some essential safety features. Should be clear by now that "policies" just doesn't work, but no, project are repeating the exact same mistake over and over again. :)
      - danarmak 10y ago
        The crucial difference is between a policy, which people can not follow (and you might not catch them), and a language or compiler restriction, which people can't work around without doing something drastic like shelling out to a new process, which you can catch (in a well built language).
        rustywut 10y ago
        But Rust is ugly and C is beautiful. Why would someone want to work in an ugly language all day?
        danarmak 10y ago
        Is the beauty you see in C inseparable from its unsafety? Are the unsafe parts that other languages don't have the most beautiful ones? There's a big difference between arguing for safety and arguing for Rust specifically. Everyone likes some languages and dislikes others. Can you design a safe(r) language that you would consider to be beautiful?
      - rustywut 10y ago
        Your points seem valid, I don't know why you're getting downvoted. Butt hurt Rust lovers I guess?
  - Manishearth 10y ago
    > so appealing and easy to jump into unsafe territory. I've almost never seen unnecessary unsafe code being used in Rust. I've seen it very few times for performance, but it's carefully done.
  - rustywut 10y ago
    If Rust is performant, why does it need unsafe code?
- fredmorcos 10y ago
  I hope I don't come across too harsh. Is HN still really up for that argument? Yes, we know the downsides of C. But the upside is that _we know the downsides of C_. Constantly complaining about C isn't going to get anyone anywhere. It's been shown over and over again that secure C coding is possible and doable and feasible and exists in the real world. Some of the most secure software is written in C, and that's not attributed to enough fingers banging at a keyboard over a C program, but because C forces the programmer that _wants_ to write a secure program think about all the issues, the universe and everything. So please, pave the road and show us the safer OpenSSL-rust you have. Until then good luck and thank you for your feedback.
  - jerf 10y ago
    It's not Rust, but: https://golang.org/pkg/crypto/tls/ https://golang.org/pkg/crypto/tls/ I know it says "partial" implementation, but it's quite good even so, and has had everything I need. It doesn't do SSLv2, but nowadays that's more virtue than vice. Erlang has an independent SSL implementation as well; it binds to OpenSSL but as I understand it just uses the heavy-duty math parts, not the protocol parts, which are instead written in Erlang. Non-C SSL implementations in memory-safe languages exist. Note that "but are they as well road-tested" or similar such things would be moving the goal posts. Not necessarily wrong or bad objections, but different objections. Probably nothing, not even the other C implementations, is as well "road tested" as OpenSSL, but, then again, OpenSSL hasn't exactly passed that road testing with flying colors now, has it?
    - fredmorcos 10y ago
      (Just my opinion) I completely agree with everything you point out. The argument I am bringing up is not about implementation, it's about "if they didn't use C, they would have less (security) problems": No. C is the way it is towards secure coding because there are compromises to satisfy other dimensions. <Fancy new language that promises to solve all of C's problems> is either making huge sacrifices in these other dimensions or is at best an experiment. We understand C's weak points so well (due to being widespread, battle tested, really simple, or what have you), that most of the time it's safer (read: more secure) to tread dangerous well-understood territories carefully than uncharted ones only promising to be safe.
- caf 10y ago
  Is the "Severity: High" issue here the kind of thing that would be caught by Rust's static analysis, though? The bug isn't a case where the language rules are broken, but rather a failure to set a reasonable limit on the resource consumption that a client can cause.
- josefx 10y ago
  > Libraries like that would probably benefit most from using a language with strict static analysis, like Rust. Wont help when developers then go out of their way to write a large amount of unsafe code. OpenSSL went out of its way to reimplement the C standard library wrong, making it impossible to use with analysis tools like valgrind or a checked malloc and generally confusing developers. iirc it even used malloc(pop)/ free(push) as a stack to pass data around at some point.
- ninja-wannabe-7 10y ago
  It's too easy to just blame C, it's their slap-dash, design-by-committee kitchen-sink features, lack of process, absense of rigor and generally amateurish "engineering," if it can be called that, of a now critical security framework. Why isn't every release first run through valgrind tools and some commercial C bug-finding tools used by embedded / safety-critical systems and why aren't there proofs of it's correctness? They have and/or could get the money/resources.
deleted 10y ago
[deleted]
dimino 10y ago
OpenSSL considers this a "high" severity issue.

easytiger 10y ago

What never ends? Dramatic over reaction for the ske of internet prosthelytising

barkingcat 10y ago

Why would it end? There is no perfect software if that's what you're looking for.

cm3 10y ago

Short answer: unlikely to end anytime soon, but likely that we start to focus on higher level bugs more than lower level issues. Long answer: If Unix and C hadn't won the fight in the 1980s like VHS did, we wouldn't deal with such low-level bugs. It took 30 years, but we're finally getting CPUs (like lowRISC) that were inspired by BS5000 or i960 and the languages to go with it are getting mainstream. To be fair, had we as an industry taken security more seriously decades ago, we would have written critical pieces of the stack in a high-assurance Ada profile, and put microkernel design capability kernels into production. We can extend 1960s kernel designs with all kinds of features, but without a coherent design it's impossible to provide the same assurance. This is why it's great that we have L4 descendants that incorporate a capability scheme and also support a multikernel scheme (ala Barrelfish) for making better use of a cluster of cpu cores.

sitkack 10y ago
We can't burn the world down and remake it. These things WILL happen over time, the next generations definitely are focused on safety and correctness. 1 we need to remove unsafe-machismo for the landscape, vector that energy into correctness instead of living with danger. 2, we need to figure out how to partition, segment, wrap the unsafe legacy stuff into a safe operating regime. The single biggest win is if we could load a library in another process and make cross-process calls to it.
- ygjb-dupe 10y ago
  > The single biggest win is if we could load a library in another process and make cross-process calls to it. What? Setting aside the fact that this can already be done in numerous different ways on many platforms, how is this a win? It's hard enough for developers to write correct code, let alone maintaining the correctness of that code while loading and executing unknown code from other parties (see web browsers, and the last 20 years of security bugs related to plugins, extensions, addons, etc).
  - sitkack 10y ago
    The user should be able to load 3rd party libraries in out of process sandboxes, transparently for applications which weren't written with that in mind. I am not asking for new programmer features, new end user / sys admin features in the loader.

adekok 10y ago

I maintain a project (http://freeradius.org http://freeradius.org) which a similar amount of code, and (arguably) similar complexity. While we've had issues, they aren't as numerous as OpenSSL. And, the issues in the latest major version are negligible. Why? We have a requirement for code quality. The code can't just work, it has to make sense. The OpenSSL people don't seem to care about badly formatted and/or non-understandable code. All commits MUST build cleanly without warnings on multiple operating systems, and under multiple compilers. We have test cases for a large chunk of the code base. We scan all releases through three different static analysis tools. Security is important. We make it important because we care. I wish other projects would do the same.

cortesoft 10y ago
I would posit another reason you don't have as many issues; you don't have as many people trying to find them. I think it is pretty foolhardy to assume that just because security issues haven't been found means they don't exist.
- ultramancool 10y ago
  There's definitely some truth to this, FreeRADIUS is just not that valuable of a target since not many people have RADIUS exposed to the world, however if you look at other highly valuable targets like OpenSSH, which is probably in the top 10 if not the most valuable target in the world, you see far fewer significant exploits. It's definitely possible to have better quality than OpenSSL and a lot of OpenSSL's issues are due to legacy code and what amount to experiments being run in production software.
  - adekok 10y ago
    For the record, the fixes for that CVE contain new CVEs. https://www.openssl.org/news/secadv/20160926.txt https://www.openssl.org/news/secadv/20160926.txt <sigh> No one can reasonably say that the practices of the OpenSSL programmers result in secure code. No one can reasonably say that lots of people examining it later for defects is a good idea. We have lots of legacy code in C. The only sane way to maintain it is tests: unit tests, functional tests, and static code analysis. > a lot of OpenSSL's issues are due to legacy code i.e. the OpenSSL people don't care to actively maintain / clean up their software. What a depressing statement to make.

throwaway12344 10y ago

If you don't know what you're talking about, please refrain from commenting. It only proves your ignorance. In the Rails land (as your profile says you are), you wouldn't have these issues, and quite frankly these types of thing seem to be beyond you at this point. You're in no position to criticize the OpenSSL project.