3 ms·

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. Hav

by 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?
    - lelanthran 4y ago
      > This would add complexity It would add fair bit of code, sure, but nicely isolated and not complex: It's three extra lines of code in the main function, and a separate utility to write the config. Balance that against the fact that the server then never writes its own config - that code is moved into the configuration-writing application, which removes complexity from the server application. > and in particular couple the application to a specific combination of operating system/privileges model/file system. It does indeed couple it to those systems that are sufficiently POSIX-like; however if you are writing a server that doesn't run on a Linux or BSD-derived system, you are out in the left field anyway. > How great is the benefit, really? How many things are exploited by the application writing to its own startup config? Well, the comment I made was in a thread discussing a vulnerability in the Microsoft Teams application[1] which was exploitable to retrieve the user's secrets[2] from their config file. So, that particular comment was very much on-topic and in-context. [1] Not sure if it was on all platforms or not. [2] Or something - I forget exactly what was leaked.
    - bawolff 4y ago
      most methods of getting persistence involve writing to some config file somewhere. Having your app not have rights to write to any sort of config or code files probably is fairly beneficial. How much is probably going to depends on how everything is configured, what your threat model is, what service it is, and a million other things.
  - msm_ 4y ago
    Interesting idea, I quite like it. At the same time we have things like kubernetes, where most people store secrets in the environment variables that every single process in the container can read.
  - peanball 4y ago
    This is what HAProxy does. At least the reading then dropping privileges. The admin writes the config themselves (or uses their own tool).
- jeroenhd 4y ago
  I think the point is that so what if you don't run these tools as root? If a malicious actor compromises your normal user account, they can also compromise your configuration files and alias sudo or set up a keylogger or do all kinds of nasty stuff. Going from standard user to root isn't much of a challenge for all but the most minimal infections in almost every standard setup for common Linux distributions. Malicious hackers don't need anything other than your current user permissions anyway; your API/ssh keys/crypto wallets are all stored in your home directory or other places a malicious program can get access to. There are exceptions, but I very much doubt that most people develop on QubesOS levels of Linux security. There is no practical antivirus software on Linux that will catch anyone sophisticated enough to exploit tcpdump. You need a LOT of know-how to run a "safe" Linux system that you're more likely to learn as a sysadmin than as a developer. Security is hard, especially on the Linux desktop, and it will be as long as attempts to add it are met with responses like "they're trying to take our freedom away". Common internet resources aren't much better ("just disable selinux") and current solutions for usability problems in this space (i.e. sandboxed applications not being able to access the directories you chose because they don't correspond to what the dev expected) aren't very great either. I definitely think we should use the resources for secure desktop computing that we do have, which includes running tshark and friends at the lowest level of privilege possible, but I can definitely understand why people ask "why should I bother" when most of their setup runs at Windows XP levels of security out of the box.
  - bawolff 4y ago
    > Malicious hackers don't need anything other than your current user permissions anyway; your API/ssh keys/crypto wallets are all stored in your home directory or other places a malicious program can get access to. I mean, are you really running tcpdump on your local computer? I imagine you would be running it on the server you are trying to debug. So the security setup would plausibly be a bit different than that. But generally i agree. Good practise not to run things as root, especially this type of tooling, but its not exactly putting your private key into a public git repo level of insecurity by any means.
    - jeroenhd 4y ago
mr_mitm 4y ago
I find it even more convenient to just add my user account to the correct group. Now I can call tcpdump anytime without having to invoke sudo. I get more security and convenience at the same time, so why not do it? I recommend giving the nmap binary the right capabilities for exactly the same reason. Sure, the attack surface of tcpdump is much smaller than wireshark, so the issue is not as pronounced, but wireshark indeed had a lot of vulnerabilities in the past: https://www.cvedetails.com/vulnerability-list/vendor_id-4861/product_id-8292/Wireshark-Wireshark.html https://www.cvedetails.com/vulnerability-list/vendor_id-4861... It has tons of dissectors which aren't nearly as battle tested as my network stack.
- msm_ 4y ago
  I agree in theory, but on my personal machine (and probably most other peoples' machines) all the interesting things are accessible by my account anyway. I'm not worried about malware changing my system configuration, I'm worried about a trojan stealing my passwords, keylogger watching what I type, stealer exfiltrating my data, or ransomware encrypting it. All of these don't really need a root account. Maybe the solution would be to use `sudo -u safe_tcpdump_user tcpdump`? I'm also going to add that I have passwordless sudo, so there's no meaningful difference in my case.
  - deleted 4y ago
    [deleted]
  - jamal-kumar 4y ago
    Weird security posture to be advertising to the world when two clicks gets me your first and last name Assuming you care about infosec from your profile, privilege escalation is definitely something you want to avoid especially if you're using these tools in for example a CTF engagement where the first thing I'll be doing is enumerating my adversaries
  - varjag 4y ago
    Root escalation was kinda Big Deal in the days of multi-user systems and cohosting. Now I think it's mostly important in the context of breaking out from unprivileged services that would normally have no access to broader filesystem.
tptacek 4y ago
tcpdump is risky because it parses (way, way) more protocols than your network stack does, and because tcpdump's parsers are tooling-grade code, not kernel network code.
- varjag 4y ago
  I mean yes it's relatively more risky but no it's not risky enough for me to not do occasional sudo tcpdump -X on an unconfigured machine in a problematic spot. The risk of me getting targeted by tcpdump zero-day while diagnosing some UDP broadcast problem on a LAN is diminutively low. Your situation is likely very different.
  - tptacek 4y ago
    No, I mean, I generally agree, it's not high on my list of threat vectors, but the general advice to be mindful about a giant memory-unsafe blob of tooling-grade protocol parsers written by hundreds of different people over 3 decades seems astute.

by varjag 4y ago

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?
  - lelanthran 4y ago
    > This would add complexity It would add fair bit of code, sure, but nicely isolated and not complex: It's three extra lines of code in the main function, and a separate utility to write the config. Balance that against the fact that the server then never writes its own config - that code is moved into the configuration-writing application, which removes complexity from the server application. > and in particular couple the application to a specific combination of operating system/privileges model/file system. It does indeed couple it to those systems that are sufficiently POSIX-like; however if you are writing a server that doesn't run on a Linux or BSD-derived system, you are out in the left field anyway. > How great is the benefit, really? How many things are exploited by the application writing to its own startup config? Well, the comment I made was in a thread discussing a vulnerability in the Microsoft Teams application[1] which was exploitable to retrieve the user's secrets[2] from their config file. So, that particular comment was very much on-topic and in-context. [1] Not sure if it was on all platforms or not. [2] Or something - I forget exactly what was leaked.
  - bawolff 4y ago
    most methods of getting persistence involve writing to some config file somewhere. Having your app not have rights to write to any sort of config or code files probably is fairly beneficial. How much is probably going to depends on how everything is configured, what your threat model is, what service it is, and a million other things.
- msm_ 4y ago
  Interesting idea, I quite like it. At the same time we have things like kubernetes, where most people store secrets in the environment variables that every single process in the container can read.
- peanball 4y ago
  This is what HAProxy does. At least the reading then dropping privileges. The admin writes the config themselves (or uses their own tool).
jeroenhd 4y ago
I think the point is that so what if you don't run these tools as root? If a malicious actor compromises your normal user account, they can also compromise your configuration files and alias sudo or set up a keylogger or do all kinds of nasty stuff. Going from standard user to root isn't much of a challenge for all but the most minimal infections in almost every standard setup for common Linux distributions. Malicious hackers don't need anything other than your current user permissions anyway; your API/ssh keys/crypto wallets are all stored in your home directory or other places a malicious program can get access to. There are exceptions, but I very much doubt that most people develop on QubesOS levels of Linux security. There is no practical antivirus software on Linux that will catch anyone sophisticated enough to exploit tcpdump. You need a LOT of know-how to run a "safe" Linux system that you're more likely to learn as a sysadmin than as a developer. Security is hard, especially on the Linux desktop, and it will be as long as attempts to add it are met with responses like "they're trying to take our freedom away". Common internet resources aren't much better ("just disable selinux") and current solutions for usability problems in this space (i.e. sandboxed applications not being able to access the directories you chose because they don't correspond to what the dev expected) aren't very great either. I definitely think we should use the resources for secure desktop computing that we do have, which includes running tshark and friends at the lowest level of privilege possible, but I can definitely understand why people ask "why should I bother" when most of their setup runs at Windows XP levels of security out of the box.
- bawolff 4y ago
  > Malicious hackers don't need anything other than your current user permissions anyway; your API/ssh keys/crypto wallets are all stored in your home directory or other places a malicious program can get access to. I mean, are you really running tcpdump on your local computer? I imagine you would be running it on the server you are trying to debug. So the security setup would plausibly be a bit different than that. But generally i agree. Good practise not to run things as root, especially this type of tooling, but its not exactly putting your private key into a public git repo level of insecurity by any means.
  - jeroenhd 4y ago

mr_mitm 4y ago

I find it even more convenient to just add my user account to the correct group. Now I can call tcpdump anytime without having to invoke sudo. I get more security and convenience at the same time, so why not do it? I recommend giving the nmap binary the right capabilities for exactly the same reason. Sure, the attack surface of tcpdump is much smaller than wireshark, so the issue is not as pronounced, but wireshark indeed had a lot of vulnerabilities in the past: https://www.cvedetails.com/vulnerability-list/vendor_id-4861/product_id-8292/Wireshark-Wireshark.html https://www.cvedetails.com/vulnerability-list/vendor_id-4861... It has tons of dissectors which aren't nearly as battle tested as my network stack.

msm_ 4y ago
I agree in theory, but on my personal machine (and probably most other peoples' machines) all the interesting things are accessible by my account anyway. I'm not worried about malware changing my system configuration, I'm worried about a trojan stealing my passwords, keylogger watching what I type, stealer exfiltrating my data, or ransomware encrypting it. All of these don't really need a root account. Maybe the solution would be to use `sudo -u safe_tcpdump_user tcpdump`? I'm also going to add that I have passwordless sudo, so there's no meaningful difference in my case.
- deleted 4y ago
  [deleted]
- jamal-kumar 4y ago
  Weird security posture to be advertising to the world when two clicks gets me your first and last name Assuming you care about infosec from your profile, privilege escalation is definitely something you want to avoid especially if you're using these tools in for example a CTF engagement where the first thing I'll be doing is enumerating my adversaries
- varjag 4y ago
  Root escalation was kinda Big Deal in the days of multi-user systems and cohosting. Now I think it's mostly important in the context of breaking out from unprivileged services that would normally have no access to broader filesystem.

tptacek 4y ago

tcpdump is risky because it parses (way, way) more protocols than your network stack does, and because tcpdump's parsers are tooling-grade code, not kernel network code.

varjag 4y ago
I mean yes it's relatively more risky but no it's not risky enough for me to not do occasional sudo tcpdump -X on an unconfigured machine in a problematic spot. The risk of me getting targeted by tcpdump zero-day while diagnosing some UDP broadcast problem on a LAN is diminutively low. Your situation is likely very different.
- tptacek 4y ago
  No, I mean, I generally agree, it's not high on my list of threat vectors, but the general advice to be mindful about a giant memory-unsafe blob of tooling-grade protocol parsers written by hundreds of different people over 3 decades seems astute.