http://ask.slashdot.org/comments.pl?sid=138603&cid=11599438
A comment in Slashdot reminding me of why ethereal is no longer ported to OpenBSD, and the fact that I just upgraded my oBSD firewall (lamenting this exclusion), has prompted me to write this.
Perhaps it's time to build some firewalls into ethereal. This would actually consist of two different parts:
One is priveledge seperation. The other is dissector categorization.
Priveledge seperation would allow the capture and dissection parts of ethereal to run as a non-root user. Generally the only reason why you need root prives for ethereal is to open the ethernet ports. Once this is done, you can safely drop permissions to a regular user (or 'nobody') to peel apart the received packets.
This would cut down on the probability of any exploit in being potentially escalatable into a remote-root exploit.
Categorizing disssectors based on their security would have two purposes: 1) I propose that, by default, only the most 'secure' of dissectors be enabled by default. Users who want the less secure dissectors (because they need them and/or they'r not in an overtly 'hostile' environment. could enable the rest explicitly. This would cut down on the possibly of being remotely compromised by someone sending a packet that engages a little=used but buggy dissector to hack your system.
2) It would encourage people to design their code well and run it thru an audit process. I think that most people would prefer to have their dissector in the 'tier 1' class. To do so would require a bit of extra work, but there would be a noticable increase in the prestige gained by tneir module by doing so. At the moment, there seems to be little, if any, impetus to 'clean up' a dissector once it's been accepted into the ethereal family.
-------------------------------------------------------- Priv sep:
Some things that I can think of: Privelege separation, in it's first form would take the form of forking off a non-priveldged child process to do the actual work of dealing with packets. If ethereal is run natively as root, this would be done after files are opened. If ethereal is run setuid, then it would be done after the interface is opened but before the file is opened. It might be appropriate to give users the option of switching to 'nobody' permissions to do the processing even if they're not root. (compile-time switch, I'd guess).
File I/O is a bit more of a sticky wicket when using rotating logs. I think that this could be handled by having the capture process write related packets to a pipe. The pipe would be read by a priv-sep process which would open the appropriate file, and then fork off a child to do the actual reading. The child would exet once it's file was full, causing it's parent to fork off yet another child to write to the next file.
Since the work it does is relatively minimal, the child process would (should) be relatively easy to audit and keep secure.
Make sense?
-- Stephen Samuel +1(604)876-0426 samnospam@xxxxxxxxxxx http://www.bcgreen.com/ Powerful committed communication. Transformation touching the jewel within each person and bringing it to light.
Powered by MHonArc 2.6.10