7 ms·

The problem here was that the coverage of the fuzz testing was not being examined. Using parsers for untrusted input in C is a legacy of when this was written.

by er4hn 4y ago

The problem here was that the coverage of the fuzz testing was not being examined. Using parsers for untrusted input in C is a legacy of when this was written. Requiring the parsing portion (or any version of OpenSSL) to be rewritten in Rust or whatever new language is a massive change given the length of time the OpenSSL project has been around.

duped 4y ago
It's not that big of a change, in the grand scheme of things. But it's also not the only thing you can do. The memory safe subset of C++ is also an option. Shipping a CVE in critical infrastructure because of a trivial memory safety bug is borderline negligence in 2022. This is why people get upset over new code being written in C. The cost of writing new portions of the software with memory safety in mind dwarfs the cost of writing in C because it's more convenient for the build tooling. The bigger question is why hasn't OpenSSL bitten the bullet and adopted some memory safety guarantees in their tooling, given the knowledge of the sources of these bugs and prevalent literature and tools in avoiding them!
- coder543 4y ago
  > The memory safe subset of C++ is also an option. This does not actually exist, as far as I'm aware. There are certain things people propose doing in C++ that eliminate a small number of issues, but I haven't seen anyone clearly define and propose a subset of C++ that is reasonably described as memory safe. Even if such a subset existed, you would still need some way to statically enforce that people only use that. Even just writing the parsers in Lua should be a safer choice than writing it in C, but I think now is as good of a time as any to start writing critical code paths in Rust. If the Linux kernel is beginning to allow Rust for kernel modules, then it is high time that OpenSSL looked more seriously at Rust too As others have pointed out, parser generators could be a useful intermediate option for some of this.
  - duped 4y ago
    You can write memory safe C++ easier than memory safe C. The problem of statically verifying it the C++ is actually memory safe because of the numerous ways to write unsafe code in C++ is a different goalpost. My point is that there isn't a compelling reason to write new code in C for something where safety is critical.
  - pjmlp 4y ago
    It is called C++ Core Guidelines.
    - saagarjha 4y ago
      No, it's not. There is no set of guidelines that exists today that creates a memory safe subset of C++. If you claim to have one, and it have a way of verifying that a program satisfies those guidelines, I'll find you a program that has unsafe behavior.
      - pjmlp 4y ago
        That is your opinion, many folks at ISO C++ see it differently. Hence why the ongoing efforts to improve static analysis tooling in regards to mechanical enforcement of C++ Core Guidelines across all major C++ compilers, IDEs and commercial static analysers. It is perfect? Don't let perfect be the enemy of good. In any case, anyone that cares about secure code shouldn't be touching any language that is copy-paste compatible with C, unless they can't avoid it.
        saagarjha 4y ago
        I think you fundamentally misunderstand what memory safety means. "Kinda sorta better" is not memory safety. It's when you can pick out a safe subset of the language and guarantee, barring errors in the language implementation itself, that certain kinds of errors are not possible. C++ cannot do this today and implementations I have seen for C have required semi-invasive changes to the language itself.
        pjmlp 4y ago
        I think you fundamentally misunderstand how static analysers and check-in hooks can be used to force everyone to play by the rules, assuming management plays ball with SecDevOps best practices. As for the rest, I was quite clear where I stand on my last sentence.
        4y ago
gizmo686 4y ago
Parser generators are one of the oldest ideas in computer science. YACC was written in the 70s; and had to be ported to C because it's original implementation was written in B. The idea of not writing parsers directly was well established by the time OpenSSL started in the late 90s.
- stcredzero 4y ago
  Given that so many of these bugs are parsing bugs, maybe we should have a new emphasis on compiler compilers which generate fast, provably correct code? (Fast, because most of the bugs and exploits are accompanied by some form of optimization.)
  - gizmo686 4y ago
    Fast and provably correct are more or less solved problems (at least for a large class of languages). The main drawback is that it is difficult to get good error messages when a parse fails.
  - nyrikki 4y ago
    I think you may run into the halting problem here.
    - stcredzero 4y ago
      You don't have to solve the halting problem every time it presents itself. Otherwise, things like Valgrind and fuzzing wouldn't be valid at all. You just have to improve your odds. EDIT: An important note to newbs: The Halting Problem is correct. However, a problem which maps to the halting problem can still be solved often enough in practice to make it worthwhile. In fact, entire industries have been born of heuristic solutions to such problems.
      - nyrikki 4y ago
        Note that I was responding to post mentioning 'provably correct code' which is very different opportunistic efforts to improve code. Valgrind and fuzzing are useful tools, but there is no general method. Being semi-decidable, with enumerable inputs. This means that fuzzing can be useful both with random walks and constrained random walks. But it doesn't come close to generating 'provably correct code'. The 'Post correspondence problem' is maybe an easier way to see how this applies at the compiler level. But tools that help are opportunistic, but that doesn't change the undecidability of generalizations. While crossing domains, but because it is commonly used, considering the VC dimensionality of the problem also helps, or pure math problems like the Collatz conjecture that generalize to the same halting problem. Generating 'provably correct code' in the general case is simply not possible without major advances in math. There is room to improve with many paths to do so, just not going down this particular path.
sitkack 4y ago
"Massive" 338 line file. https://github.com/openssl/openssl/blob/openssl-3.0.6/crypto/punycode.c#L118 https://github.com/openssl/openssl/blob/openssl-3.0.6/crypto...
zasdffaa 4y ago
Rewriting the parser portion of anything is not 'massive'. Boring as anything, but mot difficult and not much time consuming.

by er4hn 4y ago

duped 4y ago

It's not that big of a change, in the grand scheme of things. But it's also not the only thing you can do. The memory safe subset of C++ is also an option. Shipping a CVE in critical infrastructure because of a trivial memory safety bug is borderline negligence in 2022. This is why people get upset over new code being written in C. The cost of writing new portions of the software with memory safety in mind dwarfs the cost of writing in C because it's more convenient for the build tooling. The bigger question is why hasn't OpenSSL bitten the bullet and adopted some memory safety guarantees in their tooling, given the knowledge of the sources of these bugs and prevalent literature and tools in avoiding them!

coder543 4y ago
> The memory safe subset of C++ is also an option. This does not actually exist, as far as I'm aware. There are certain things people propose doing in C++ that eliminate a small number of issues, but I haven't seen anyone clearly define and propose a subset of C++ that is reasonably described as memory safe. Even if such a subset existed, you would still need some way to statically enforce that people only use that. Even just writing the parsers in Lua should be a safer choice than writing it in C, but I think now is as good of a time as any to start writing critical code paths in Rust. If the Linux kernel is beginning to allow Rust for kernel modules, then it is high time that OpenSSL looked more seriously at Rust too As others have pointed out, parser generators could be a useful intermediate option for some of this.
- duped 4y ago
  You can write memory safe C++ easier than memory safe C. The problem of statically verifying it the C++ is actually memory safe because of the numerous ways to write unsafe code in C++ is a different goalpost. My point is that there isn't a compelling reason to write new code in C for something where safety is critical.
- pjmlp 4y ago
  It is called C++ Core Guidelines.
  - saagarjha 4y ago
    No, it's not. There is no set of guidelines that exists today that creates a memory safe subset of C++. If you claim to have one, and it have a way of verifying that a program satisfies those guidelines, I'll find you a program that has unsafe behavior.
    - pjmlp 4y ago
      That is your opinion, many folks at ISO C++ see it differently. Hence why the ongoing efforts to improve static analysis tooling in regards to mechanical enforcement of C++ Core Guidelines across all major C++ compilers, IDEs and commercial static analysers. It is perfect? Don't let perfect be the enemy of good. In any case, anyone that cares about secure code shouldn't be touching any language that is copy-paste compatible with C, unless they can't avoid it.
      - saagarjha 4y ago
        I think you fundamentally misunderstand what memory safety means. "Kinda sorta better" is not memory safety. It's when you can pick out a safe subset of the language and guarantee, barring errors in the language implementation itself, that certain kinds of errors are not possible. C++ cannot do this today and implementations I have seen for C have required semi-invasive changes to the language itself.
        pjmlp 4y ago
        I think you fundamentally misunderstand how static analysers and check-in hooks can be used to force everyone to play by the rules, assuming management plays ball with SecDevOps best practices. As for the rest, I was quite clear where I stand on my last sentence.
        4y ago

gizmo686 4y ago

Parser generators are one of the oldest ideas in computer science. YACC was written in the 70s; and had to be ported to C because it's original implementation was written in B. The idea of not writing parsers directly was well established by the time OpenSSL started in the late 90s.

stcredzero 4y ago
Given that so many of these bugs are parsing bugs, maybe we should have a new emphasis on compiler compilers which generate fast, provably correct code? (Fast, because most of the bugs and exploits are accompanied by some form of optimization.)
- gizmo686 4y ago
  Fast and provably correct are more or less solved problems (at least for a large class of languages). The main drawback is that it is difficult to get good error messages when a parse fails.
- nyrikki 4y ago
  I think you may run into the halting problem here.
  - stcredzero 4y ago
    You don't have to solve the halting problem every time it presents itself. Otherwise, things like Valgrind and fuzzing wouldn't be valid at all. You just have to improve your odds. EDIT: An important note to newbs: The Halting Problem is correct. However, a problem which maps to the halting problem can still be solved often enough in practice to make it worthwhile. In fact, entire industries have been born of heuristic solutions to such problems.
    - nyrikki 4y ago
      Note that I was responding to post mentioning 'provably correct code' which is very different opportunistic efforts to improve code. Valgrind and fuzzing are useful tools, but there is no general method. Being semi-decidable, with enumerable inputs. This means that fuzzing can be useful both with random walks and constrained random walks. But it doesn't come close to generating 'provably correct code'. The 'Post correspondence problem' is maybe an easier way to see how this applies at the compiler level. But tools that help are opportunistic, but that doesn't change the undecidability of generalizations. While crossing domains, but because it is commonly used, considering the VC dimensionality of the problem also helps, or pure math problems like the Collatz conjecture that generalize to the same halting problem. Generating 'provably correct code' in the general case is simply not possible without major advances in math. There is room to improve with many paths to do so, just not going down this particular path.

sitkack 4y ago

"Massive" 338 line file. https://github.com/openssl/openssl/blob/openssl-3.0.6/crypto/punycode.c#L118 https://github.com/openssl/openssl/blob/openssl-3.0.6/crypto...

zasdffaa 4y ago

Rewriting the parser portion of anything is not 'massive'. Boring as anything, but mot difficult and not much time consuming.