Once nice thing about this is that it's memory-safe, which is something you really want for a packet capture tool.
Hrm. Interesting point. There have been a fair number of parser CVEs, but GoLang isn't immune to some of the (based on an admittedly cursory look) parser issues.
A protocol analyzer implemented in anything short of formally-verified code is going to be "vulnerable" to logic errors, such that it might print (or not print) the wrong things. But a protocol analyzer implemented in C standard a decent chance of coughing up RCE.
(Playing devil's advocate): What would the RCE accomplish?
"Parse this packet and get a reverse shell on analyst's workstation?"
To be clear: I am not in any way attempting to disparage the project. It is damned cool, and as a neophyte Go practitioner myself, I very much appreciate its existance and utility. Just working through all the edge cases :)
I assume one reason for these console versions is that people run them directly on the server. Maybe sometimes even as root.
Yes, that's what it would accomplish.
Re:Gosniff: A TUI-Based Tcpdump
by freedomben on Sunday May 01, 2022 @09:00PM
(#31230306)
My thoughts as well. Tshark supports a ton of dissectors. How does this project compare? Being in go, can it reuse the Wireshark dissectors that are written in C?
How does it compare to Wireshark' console cousin tshark?