@alessandrogario My read on that discussion is there is potentially, or even likely, a Remote Code Execution vulnerability with how that http_events PR parses untrusted network data as the root user. Is that a correct read on that PR discussion?

I'll let Alessandro speak for himself, but I do not think any RCE vuln has been identified. The concern is with parsing untrusted data. Yes, osquery does this with many tables. But in this case a remote attacker can cause osquery to parse the data without osquery initiating a connection. Contrast this with the

curl

table which has to actively reach out to an endpoint (and is controversial in itself).

Got it, so there may be an increased risk for RCE due to lack of mitigation against that general risk (like spawning a process that immediately drops privileges)

Yes, I personally believe that parsing untrusted packets as root is a problem, as already documented by many sources (see Wireshark for example). That's because generating input for that piece of code is extremely easy if you can reach that machine one way or another. It's possible to do this the right way by using a secondary process that drops privileges for good, with no chance of regaining them. Additionally, I think that if something like this is used in production it should be split in many functions, with unit tests, and more importantly heavily fuzzed. The PR in question does not address those concern. Speaking about reliability: without adding support for re-assembling the TCP conversations, it's prone to lose events (example: connections that are re-used) and parse packets that are not supposed to be handled (i.e.: a network problem causes some packets to be re-sent due to data corruption. they need to be identified and ignored)

I agree with @alessandrogario RE: parsing as root. These issues have been widely discussed in the network security monitoring community with Snort / Suricata / Zeek etc I would not recommend widespread production usage for something that is parsing network data as root.