What is a parser mismatch vulnerability? (2022)

I did research on parser differentials for my bachelor's thesis. My initial hope was that I would find a few mismatches for formats without a formal specification. I found mismatches for _every single_ pair of parsers I looked at and that included formats with formal specifications. My personal takeaway was "If you use one parser for validation and another parser for evaluation, you're fucked. No exceptions."

As the article mentions, Postel's Law is likely to create vulnerabilities. It makes individual systems more robust, but the whole becomes fragile.

&gt; Well, these browsers &quot;helpfully&quot; fix the URL to change backslashes into regular forward slashes, I suppose because people sometimes type in URLs and get their forward and back slashes confused.<p>More likely because Windows has historically used \ rather than the &#x2F; that&#x27;s standard in Unixish systems. Windows people are used to typing \, so it&#x27;s indeed somewhat helpful for the browser to accept either (e.g., in file:&#x2F;&#x2F; URLs).

Odd that the article doesn&#x27;t use the more standard term &quot;parser differential&quot;, with &quot;differential fuzzing&quot; as the fuzzing community&#x27;s method for finding those.

This is a LANGSEC concept. A broader survey can be found at: <a href="https:&#x2F;&#x2F;www.computer.org&#x2F;csdl&#x2F;proceedings-article&#x2F;spw&#x2F;2023&#x2F;123600a105&#x2F;1P5ZnKk745O" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.computer.org&#x2F;csdl&#x2F;proceedings-article&#x2F;spw&#x2F;2023&#x2F;1...</a>

Somewhat related to &quot;Parse, don&#x27;t validate&quot;: <a href="https:&#x2F;&#x2F;lexi-lambda.github.io&#x2F;blog&#x2F;2019&#x2F;11&#x2F;05&#x2F;parse-don-t-validate&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;lexi-lambda.github.io&#x2F;blog&#x2F;2019&#x2F;11&#x2F;05&#x2F;parse-don-t-va...</a> , <a href="https:&#x2F;&#x2F;hn.algolia.com&#x2F;?query=Parse%2C%20don%27t%20validate&amp;type=story&amp;dateRange=all&amp;sort=byDate&amp;storyText=false&amp;prefix&amp;page=0" rel="nofollow noreferrer">https:&#x2F;&#x2F;hn.algolia.com&#x2F;?query=Parse%2C%20don%27t%20validate&amp;...</a>

I guess if we add all the problems in IT that were caused by bugs and poor designs of parsers&#x2F;serializations, e.g. SQL injections, XSS, null byte vulns etc., we get billions of human hours in damages.<p>What should be instead is an absolutely clear serialization format into a byte string of ANY data structure that must processed by two different programs.<p>Parsers are programs, they should &quot;parse&quot; bytes, not strings, like we humans do.

If BABLR succeeds in creating a shared instruction set for defining parsers, you&#x27;d just have portable parser grammars running on compatible parser VMs

Usually? a result of the parser not having a machine-readable specification.<p>For parsing proper, `bison --xml` is useful if you&#x27;re allergic to code-generation. I don&#x27;t have an equivalent for lexing.

Honestly we should have a name for such class of bugs. It&#x27;s not an &quot;I didn&#x27;t know&quot; kind of mistake. Every person sufficiently intelligent to program should figure out by themselves that having 2 parser implementations can cause various undesired consequences.

Usually, some not verified and cleaned enough external input text managed to get into some complex and often brain damaged text parser (printf,sql,etc).