5 ms·

I'm confused and very far from an expert here. What is wrong with parsers, and what is the alternative?

• jcims 4y ago
  A specific class of parsers >parsers for untrusted input in C
  • thaumasiotes 4y ago
    That didn't answer anything. If you want to do anything with your input, you have to run it through a parser. Doesn't matter if it's untrusted or not. Your only options are ignoring the input, echoing it somewhere, or parsing it.
    • Diggsey 4y ago
      They're saying don't write such a parser in C. Use something else (memory safe language, parser generator, whatever).
      • lazide 4y ago
        And then do what with it? Throw it away? If it hands it to a C program, that C program needs to parse (in some form!) those values! How is a C program expected to ever do anything if it can’t safely handle input?
        • tsimionescu 4y ago
          Untrusted input -> memory-safe parser -> trusted input -> C program. Probably not that important for `ls`, probably worth it for OpenSSL.
          • lazide 4y ago
            The challenge of course is the links to the ‘memory safe parser’, or how it gets from the untrusted input to it mediated by C, correct?
    • nicoburns 4y ago
      Right, but you do have the option of writing that parser in a language other than C. And given how often severe security issues are caused by such parsers written in C, one probably ought to choose a different language, or at least use C functions and string types that store a length rather than relying on null termination.
      • thaumasiotes 4y ago
        >>>>> Why are people still using parsers for untrusted input in C? No matter what the parser itself is written in, if you're writing in C you'll be using the parser in C.
        • wongarsu 4y ago
          If you have the input in a buffer of known length in C, hand it off to a (dynamic or static) library written in a safe language, and get back trusted parsed output, then there's much less attack surface in your C code.
          • lazide 4y ago
            The issue in many of these cases is there appears to be no canonical safe way to know the length of the input in C, and people apparently screw up keeping track of the lengths of the buffers all the time.
            • saagarjha 4y ago
              This is why you reduce the amount of C code that has to keep track of it to as little as possible.
        • nicoburns 4y ago
          1. Well don’t write in C then if your program is security critical or going to be exposed over a network. Sure, there are some targets that require C, but that’s not the case for the vast majority of platforms running OpenSSL. 2. That’s still less of a problem as the C will then be handling trusted data validated by the safe langauge.
  • lazide 4y ago
    Pretty much all input is untrusted unless it originated (exclusively!) from something with more permissions that is trustworthy. The kernel is written in C. So that pretty much means all parsers written in C and every other language should consider all input untrustworthy, no?
    • Gigachad 4y ago
      Linux is probably the most carefully constructed C codebase in existence and still falls in to C pitfalls semi regularly. Every other project has no hope of safely using C. It's looking more and more like Linux should be carefully rewritten in Rust. It's a monstrous task but I can see it happening over the next decade.
      • Shared404 4y ago
        I agree with the spirit of your comment. > Linux is probably the most carefully constructed C codebase in existence and still falls in to C pitfalls semi regularly. My guess is that it would actually be OpenBSD, but I'm not sure either way.