Priviledge Seperation

Posted Dec 10, 2015 12:35 UTC (Thu) by pwfxq (subscriber, #84695)
Parent article: Wireshark 2.0: Now with Qt

Maybe Wireshark should copy a technique used by other programs and implement privilege separation when capturing packets.

Priviledge Seperation

Posted Dec 10, 2015 13:00 UTC (Thu) by NAR (subscriber, #1313) [Link]

I'm not sure that would help much. It is already possible to capture the packets via tcpdump, then load it in unprivileged wireshark - but if that unprivileged user account is used to do online banking, then it might be a more interesting target than the root account...

Priviledge Seperation

Posted Dec 10, 2015 13:14 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

Wireshark has separated out capture from the UI for many, many years now.

Priviledge Seperation

Posted Dec 12, 2015 9:18 UTC (Sat) by Lekensteyn (guest, #99903) [Link]

This is true, the capture process ("dumpcap") is a separate process which is run by Wireshark/tshark to capture packets. This process does not need setuid root, it is sufficient to give it CAP_NET_RAW and CAP_NET_ADMIN capabilities. See https://wiki.wireshark.org/CaptureSetup/CapturePrivileges... for instructions.

Priviledge Seperation

Posted Dec 10, 2015 13:20 UTC (Thu) by jlayton (subscriber, #31672) [Link]

If you're running on an OS that has file capabilities, then you don't need to be root to run a capture. On recent Fedora, for instance you just need to be in the "wireshark" group and you can run a live capture as an unprivileged user.

Priviledge Seperation

Posted Dec 10, 2015 17:59 UTC (Thu) by iabervon (subscriber, #722) [Link] (3 responses)

It might be interesting to consider isolating the packet analysis from the UI, and running the packet analysis in a process without the ability to use nearly any system calls. Even without any special privileges, it's easy to imagine an attack that uses a bug in a dissector to send the whole packet dump somewhere over TOR, which could reveal a bunch of local network secrets in response to having attacker-generated packets in the same dump.

Priviledge Seperation

Posted Dec 10, 2015 20:00 UTC (Thu) by bronson (subscriber, #4806) [Link] (2 responses)

I had the same thought... If ever there was a case for tight sandboxing, dissectors are it.

I assume the catch is that Wireshark is cross-platform and sandboxing is not. Very very not.

Priviledge Seperation

Posted Dec 10, 2015 22:33 UTC (Thu) by johill (subscriber, #25196) [Link] (1 responses)

Writing dissectors is already a huge pain ;-)
Seriously though - it could probably be done since the dissectors interact with an abstract representation of the parse tree, but you'd have to serialize that across some kind of protocol which is likely quite awful ...

I think the cross-platform angle seems a bit of a red herring; once you've split it out to a separate process you could get the security where it's supported?

Priviledge Seperation

Posted Dec 11, 2015 15:27 UTC (Fri) by raven667 (subscriber, #5198) [Link]

As far as cross platform sandboxing, it seems the browser vendors have lead the way, Chrome was designed around the needs of sandboxing and has researched it thoroughly on all supported operating systems, so using that as a template to start from seems the smart move.

It seems you only need a file descriptor in/out, input would be pcap data, output would have to be structured for consumption by the Wireshark UI, which provides its own attack surface and potential for failure, but it should be lower than that of the dissectors themselves, even as the dissectors are re-written in a safer way. How is that done in browser land, what validation does the display process have of data being fed from the parser?

Privilege Seperation

Posted Dec 11, 2015 7:34 UTC (Fri) by robbe (guest, #16131) [Link] (1 responses)

I’m not too worried about capturing. See other answers.

More interesting at the moment would be privilege-seperating the dissectors from the GUI. They are a prime example where even simple seccomp could do wonders.

Privilege Seperation

Posted Dec 12, 2015 19:18 UTC (Sat) by jmayer (guest, #595) [Link]

IIRC, there was a project called echild. The code is still part of the source but it was never built by default. The code quality in that directory is sad.