5 ms·

These tools are parsing untrusted input (tshark and wireshark are parsing a very large number of different protocols), and considering these are all written in

These tools are parsing untrusted input (tshark and wireshark are parsing a very large number of different protocols), and considering these are all written in a memory unsafe language (C), they are at a high risk of remote command execution vulnerabilities. And since they don't actually require root permissions, just permission to access raw sockets and a few other network related things, it's simply best practices to use as little privileges as possible and only as much as necessary.

rixrax 4y ago
Sometimes when no other options exist, and I need to capture untrusted traffic as root, I use 'tcpdump -i eth0 -s0 -n -w some.pcap' to save the packets to a .pcap. Just recording the frames shouldn't (invoke any parsing code although I have never actually checked). Then I open the .pcap with wire/tshark or even tcpdump in some safer sandbox.
- hamburglar 4y ago
  You can also send the pcap to stdout and pipe it to stdin of a tshark running as non-root. And if you provide the right capture filters on tcpdump you can even have the tcpdump in an ssh session piping to a local tshark so you don’t even have to have tshark on the server.
  - mr_mitm 4y ago
    Wireshark is also able to capture traffic of remote interfaces over ssh.
  - lexh 4y ago
    I was delighted when I discovered that you can also pipe stdin into Wireshark (GUI). I've not seen a lot of GUI applications that support this flow. e.g. > wireshark -k -i <(ssh -l root remote-host "dumpcap -P -w - -f 'not tcp port 22'") https://wiki.wireshark.org/CaptureSetup/Pipes.md#remote-capture https://wiki.wireshark.org/CaptureSetup/Pipes.md#remote-capt...
    - hamburglar 4y ago
      I prefer a ‘not host <x>’ filter using info found in $SSH_CONNECTION to filtering all port 22 out, but yeah, good stuff.
varjag 4y ago
While the principle itself is sound, this is seriously exaggerating the threat. I mean sure the tools are written in C, but so is your whole network stack. Have your prod boxes set up with proper permissions for sure but there's hardly a practical risk doing this in dev/testing.
- b112 4y ago
  Tcpdump is a unique codebase, has its own flaws/issues, and most certainly can be vulnerable, even if the overall stack is not. Run nothing as root, unless absolutely required. And this had nothing to do with C or rust, running rust based software, any software as root, when not required,is unnecessary, and risky as well. Nothing is safe. Behave that way, or you do your oeg, and yourself, wrong. And its not OK to treat a dev env as fine to get compromised. Many orgs get borked by someone taking over dev machines, or infra, and sliding in that way.
  - lelanthran 4y ago
    > Run nothing as root, unless absolutely required. Good advice, to be sure. Especially anything getting network input[1]. In a reddit thread once, I pointed out that there is no need for any server/service program to have any access to the file holding the startup configuration. There really isn't. If the user needs to write that configuration, use a different program with elevated privileges that do nothing but write that file. When the server starts up and needs to read config, it should start up as a user with elevated privileges, read the entire file in the first 3 lines of `main()`, then drop privileges and continue execution as normal. It will never be able to access that file during the rest of its execution. I don't think I've ever had a comment downvoted on reddit so hard! [1] No need to say "untrusted network input" - all input is untrusted unless you are literally in control of both parties.
    - kqr 4y ago
      This would add complexity and in particular couple the application to a specific combination of operating system/privileges model/file system. How great is the benefit, really? How many things are exploited by the application writing to its own startup config?
client4 4y ago
At the defcon ctf in 2016(?) One of the teams used a Wireshark 0day to pwn another team and see/use all of their flags.
- red-iron-pine 4y ago
  tell me more

rixrax 4y ago

Sometimes when no other options exist, and I need to capture untrusted traffic as root, I use 'tcpdump -i eth0 -s0 -n -w some.pcap' to save the packets to a .pcap. Just recording the frames shouldn't (invoke any parsing code although I have never actually checked). Then I open the .pcap with wire/tshark or even tcpdump in some safer sandbox.

hamburglar 4y ago
You can also send the pcap to stdout and pipe it to stdin of a tshark running as non-root. And if you provide the right capture filters on tcpdump you can even have the tcpdump in an ssh session piping to a local tshark so you don’t even have to have tshark on the server.
- mr_mitm 4y ago
  Wireshark is also able to capture traffic of remote interfaces over ssh.
- lexh 4y ago
  I was delighted when I discovered that you can also pipe stdin into Wireshark (GUI). I've not seen a lot of GUI applications that support this flow. e.g. > wireshark -k -i <(ssh -l root remote-host "dumpcap -P -w - -f 'not tcp port 22'") https://wiki.wireshark.org/CaptureSetup/Pipes.md#remote-capture https://wiki.wireshark.org/CaptureSetup/Pipes.md#remote-capt...
  - hamburglar 4y ago
    I prefer a ‘not host <x>’ filter using info found in $SSH_CONNECTION to filtering all port 22 out, but yeah, good stuff.

varjag 4y ago

While the principle itself is sound, this is seriously exaggerating the threat. I mean sure the tools are written in C, but so is your whole network stack. Have your prod boxes set up with proper permissions for sure but there's hardly a practical risk doing this in dev/testing.

b112 4y ago
Tcpdump is a unique codebase, has its own flaws/issues, and most certainly can be vulnerable, even if the overall stack is not. Run nothing as root, unless absolutely required. And this had nothing to do with C or rust, running rust based software, any software as root, when not required,is unnecessary, and risky as well. Nothing is safe. Behave that way, or you do your oeg, and yourself, wrong. And its not OK to treat a dev env as fine to get compromised. Many orgs get borked by someone taking over dev machines, or infra, and sliding in that way.
- lelanthran 4y ago
  > Run nothing as root, unless absolutely required. Good advice, to be sure. Especially anything getting network input[1]. In a reddit thread once, I pointed out that there is no need for any server/service program to have any access to the file holding the startup configuration. There really isn't. If the user needs to write that configuration, use a different program with elevated privileges that do nothing but write that file. When the server starts up and needs to read config, it should start up as a user with elevated privileges, read the entire file in the first 3 lines of `main()`, then drop privileges and continue execution as normal. It will never be able to access that file during the rest of its execution. I don't think I've ever had a comment downvoted on reddit so hard! [1] No need to say "untrusted network input" - all input is untrusted unless you are literally in control of both parties.
  - kqr 4y ago
    This would add complexity and in particular couple the application to a specific combination of operating system/privileges model/file system. How great is the benefit, really? How many things are exploited by the application writing to its own startup config?

client4 4y ago

At the defcon ctf in 2016(?) One of the teams used a Wireshark 0day to pwn another team and see/use all of their flags.

red-iron-pine 4y ago
tell me more