Mechanisms to control/tune parsing parameters from Zeek

[jsiwek]

In the PE parser I worked on, I used a handful of global constants to enforce parsing constraints that aren't technically given by the formal specification of the file format, but that "reasonable" parsing applications may think about in order to avoid DoS hazards:

https://github.com/zeek/spicy/compare/topic/jsiwek/pe#diff-36ceb1dc5c1f8f65e1fb3553b2d552ef12f58b3651f1df59aafa9e6c3fafc63eR14-R22

A couple of these are currently used in the existing BinPAC PE parser due to real-life encounters with files that looked like PE, but had unreasonable length fields for certain string data and could cause excessive amounts of data to be buffered in memory.

Using static constants like I did is sufficient, and is at parity with the BinPAC parser, but an idea for improving this is to allow some external control of the values. E.g. to help mitigate potential evasion attempts of someone creating their executable with a field that is 1-byte past the hard-coded constraint, we could add uncertainty of whether any given Zeek deployment has customized their parsing constraints from the default.

Outside the security/evasion realm, such control could also be useful for general performance optimization: if I've defined the Spicy parser to be able parse PE import/export tables, but Zeek has not defined any event handlers to make use of that information, it's inefficient to spend time parsing that information, so Zeek could be more efficient if it had control over some simple flags that could control how deeply a Spicy parser goes (e.g. so I can conditionally parse a field as a recursive unit or just to skip over as some arbitrary bytes, etc.)