9 ms·

Why is that?

mr_mitm 4y ago
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
yakubin 4y ago
You’re parsing untrusted input. Doing it with the smallest set of privileges possible seems like a common sense thing to do.
ye-olde-sysrq 4y ago
These other responses are great justification to always dig into what someone's threat model is. I've had so many "security" conversations get resolved something like this: other dev: this is insecure me: what's your threat model? other dev: <convoluted, opportunistic-only highly-timing-sensitive scenario that assumes attacker has gained internal network access> me: you do realize all our boxes have an "admin:password"-esque standard login available and passwordless sudo. if they're on our network they can already just do basically anything. People (well, devs) love to think about security in very fine-grained detail, and honestly that's good. We should all be thinking about this. But your security is only as good as your weakest link, and when your security policy already literally codifies "we will trust the firewall to make intranet security less annoying/complicated" then unless you want to go change that or your threat model is describing an attack on that security model, then please don't try to get overly clever. Now - that said - I do wish more orgs just did defense-in-depth from the beginning. It's so easy to provision certs nowadays that there's almost no reason not to do mTLS etc even in something like a homelab setting.
- tptacek 4y ago
  This isn't a convoluted, timing-sensitive scenario; it's more like, there is the possibility that if you have tcpdump running anywhere, an attacker can strobe a packet that will trip a memory corruption vulnerability in some tcpdump printer, which is not, like, out of the realm of possibility.

Why is that?

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

yakubin 4y ago

You’re parsing untrusted input. Doing it with the smallest set of privileges possible seems like a common sense thing to do.

ye-olde-sysrq 4y ago

These other responses are great justification to always dig into what someone's threat model is. I've had so many "security" conversations get resolved something like this: other dev: this is insecure me: what's your threat model? other dev: <convoluted, opportunistic-only highly-timing-sensitive scenario that assumes attacker has gained internal network access> me: you do realize all our boxes have an "admin:password"-esque standard login available and passwordless sudo. if they're on our network they can already just do basically anything. People (well, devs) love to think about security in very fine-grained detail, and honestly that's good. We should all be thinking about this. But your security is only as good as your weakest link, and when your security policy already literally codifies "we will trust the firewall to make intranet security less annoying/complicated" then unless you want to go change that or your threat model is describing an attack on that security model, then please don't try to get overly clever. Now - that said - I do wish more orgs just did defense-in-depth from the beginning. It's so easy to provision certs nowadays that there's almost no reason not to do mTLS etc even in something like a homelab setting.

tptacek 4y ago
This isn't a convoluted, timing-sensitive scenario; it's more like, there is the possibility that if you have tcpdump running anywhere, an attacker can strobe a packet that will trip a memory corruption vulnerability in some tcpdump printer, which is not, like, out of the realm of possibility.