Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.
Wireshark logo

Wireshark-users: Re: [Wireshark-users] Windows: use low integrity level to restrict privileges?

Date Prev · Date Next · Thread Prev · Thread Next
Date Index · Thread Index · Other Months · All Mailing Lists
From: Julien T <julien.t43@xxxxxxxxx>
Date: Sun, 27 Jul 2014 18:41:44 -0400



2014-07-26 1:09 GMT-04:00 Guy Harris <guy@xxxxxxxxxxxx>:

On Jul 25, 2014, at 6:40 PM, Julien T <julien.t43@xxxxxxxxx> wrote:

> As I'm back to use more Windows, I checked about privileges/sandboxing and I ask myself why not use low integrity level (like browsers).

Note that Wireshark is not a "Windows application", it's a multi-platform application for platforms including but not limited to Windows, so a concept particular to some platform might not be familiar to all developers or users.

Of course, but many multi-platform applications try to improve their security be it chromium, firefox, adobe reader, ... [1]


Presumably you're referring to

        http://msdn.microsoft.com/en-us/library/bb625964.aspx


Yes, that's the parent article of the link I provided.
 


> A quick test with icacls [1] got me running fine at low integrity level, checking just a few options. An extra point, it supposes a ntfs partition, no good for PortableWireshark on vfat usb.

Or for a server using ReFS?

        http://msdn.microsoft.com/en-us/library/windows/desktop/hh848060(v=vs.85).aspx


AFAIK, ResilientFS fully supported NTFS ACL [2], so there should be no problem. can't test though.
Low integrity level seems a little investment (can do it per user install) for extra little security.
Win8 seems to offers more advanced mecanisms like AppContainer but not sure if it's possible outside of VisualStudio [3]
 


> Ideally a two (or three) process separation would be done to handle user gui / dissectors & misc / admin capture and to be integrated in the executable.
>
> I check the roadmap [2] and Privilege Separation for Unix and Windows are mentionned but I'm unsure if they were fully implemented for 1.0 or still work in progress? (3 process separation as said previously)

3 processes?  No.

2 processes, as per "At a minimum, the capture role should be separated out." at

        http://wiki.wireshark.org/Development/PrivilegeSeparation

Yes, we did that ages ago, on all platforms.

I don't think 1.0 it's age ago.
PrivSep was with vulnerability history the reason than ethereal was removed from OpenBSD ports tree. It recently made its way back but partial privsep is still an issue as explained here
 

(Another interesting separation, at least on UN*X, might be to split libpcap into a library that reads packets and a separate program that handles all the operations that require privilege, such as opening a capture device, turning on monitor mode on some platforms, setting the Wi-Fi channel on some platforms, etc., so that the library either connects to a daemon running that program or runs a privileged version of that program, and that program hands the library a file descriptor from which it can read or which it can memory-map.

agree. 

I don't know whether Windows supports sending HANDLEs or anything such as that over any local interprocess communication mechanism, as most if not all UN*Xes do.  If so, then this could be done on Windows as well.)

of course, there is [4]. I would be surprise any modern OS has not.
 

The main reason to separate the UI and the dissection, at least as I see it, is that dissection is mostly done by C code generated by humans.  It's not code downloaded from the Internet, so it's not *quite* as untrustworthy, in some sense, as, for example, _javascript_ - or ActiveX - code downloaded from the Internet, so that you can *somewhat* believe it has no malicious intent, but, as it's C code, it's potentially more hackable than _javascript_ code.

yeah, but on modern OS, _javascript_ or activex are done in low integrity process be it for chromium or internet explorer

It might be interesting to see how much security could be improved by using protocol descriptions written in declarative languages such as ASN.1 or some DCE RPC IDL or some CORBA IDL or ONC RPC's rpcgen or X11's protocol description language or the WSGD language:

        http://wsgd.free.fr

or... rather than C code.)

yes, but hopefully will happen. I still think than it's on a longer term roadmap than user security.


Cheers,

J 


[1]
[2]
[3]
[4]
[5]
Wireshark logo footer

© Wireshark Foundation · Privacy Policy

Facebook·Mastodon·Twitter·YouTube