6 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.
        • 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.
          • jstimpfle 4y ago
            If you make argument 2) could you explain how writing a parser is more security critical than any other code that has a (direct or indirect) interaction with the network? At least recursive descent parsers are close to trivial. I usually start by writing a "next_byte" function and then "next_token". You'll have to look very hard to find any pointer code there. It's close to impossible to get this wrong and I don't see how the fact that it's a parser would make it any more dangerous.
            • thaumasiotes 4y ago
              > It's close to impossible to get this wrong and I don't see how the fact that it's a parser would make it any more dangerous. I can answer that one. The parser is more dangerous because a parser, essentially by definition, takes untrusted input. Nothing the parser does is any more dangerous than the rest of the code; it's all about the parser's position in the data flow.
  • 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.