[\Device\] entries in Full File Access (OpenPipePath)?

If it's not about a problem in the program
Post Reply
steel8
Posts: 3
Joined: Fri Jan 06, 2017 5:35 am

[\Device\] entries in Full File Access (OpenPipePath)?

Post by steel8 » Mon Jan 09, 2017 7:17 am

When I was changing settings for the default sandbox (DefaultBox), I noticed some entries in Full File Access that I haven't added there myself, that applies to all programs. (See the screenshot below)
Sandboxie_fullaccess_device_entries.png
Sandboxie_fullaccess_device_entries.png (7.38 KiB) Viewed 606 times
My questions are:
1. Simply explained, what is "\Device\" entries? What is "named pipes"?
2. Why are these entries listed? I think it has something to do with the software compability settings, but why should the sandboxed applications have full file access to these entries?
3. Why are these entries listed in "Full File Access"? Do the sandboxed applications have to write to these "\Device\" things also?
4. Is this a safety issue? Can a sandboxed malicious application use this to infect the computer (infect the computer outside of the sandbox)?

/steel8

Syrinx
Sandboxie Guru
Sandboxie Guru
Posts: 620
Joined: Fri Nov 13, 2015 4:11 pm

Re: [\Device\] entries in Full File Access (OpenPipePath)?

Post by Syrinx » Mon Jan 09, 2017 10:52 am

OpenPipePaths do weaken Sandboxie and punch some holes.
https://www.sandboxie.com/index.php?OpenPipePath
The ones you see there are likely from templates meant to allow things running sandboxed to operate properly. The QWAVE one is mainly for Chrome I believe but is used for anything that makes use of Quality Windows Audio/Video Experience in windows and is added to all new boxes since a past Sandboxie update.

Most of the other entries are related to F-Secure
The LGLCDPIPE-* one is related to a Logitech Keyboard

If you check software compatibility you'll likely see those listed under it and enabled.
Goo.gl/p8qFCf

steel8
Posts: 3
Joined: Fri Jan 06, 2017 5:35 am

Re: [\Device\] entries in Full File Access (OpenPipePath)?

Post by steel8 » Wed Jan 11, 2017 11:03 am

Thanks @Syrinx for your answer and sorry for my late reply.

So, if the sandboxed applications have FULL access to F-Secure's named pipes, for example, they can control antivirus settings and turn off the antivirus or something similar? I also don't really understand what these entries technically actually are (why they exist there). What sort of stuff is listed under "[\Device\]"? Is Named Pipes something different applications/processes can use to communicate with each other? Also, why would the sandboxed applications need to communicate with my antivirus for example?

Question summary:
1. What are "["\Device\"]" entries actually, and what is listed there?
2. Is Named Pipes something different applications/processes can use to communicate with each other?
3. Why is QWAVEdrv not listed under Named Pipes? Is it something different?
4. Why would the sandboxed applications need to communicate with my antivirus?
5. Could malicious applications, without exploiting any vulnerability in Sandboxie, use the "Device" and "NamedPipe" entries to infect the computer outside of the sandbox/execute code outside of the sandbox?


Thanks for replying
/steel8

Syrinx
Sandboxie Guru
Sandboxie Guru
Posts: 620
Joined: Fri Nov 13, 2015 4:11 pm

Re: [\Device\] entries in Full File Access (OpenPipePath)?

Post by Syrinx » Thu Jan 12, 2017 11:08 am

1) \Device\ covers several things from instances of real devices, virtual devices, filters, harddrive partitions, symboliclinks and maybe more. You can view this information [and lots of other types] with a nifty program called WinObj to see what's on your system.

2) Yes, Named Pipes are used between processes so that applications can communicate locally or remotely.

3) QWAVEdrv is a service that comes with Windows, it is not a Named Pipe used for communication. I suppose the OpenPipePath part being used for both could be confusing but it's actually because the Named Pipes are handled and treated very similar to the file system including having their own security descriptors.

4) I don't think it's so much that the sandboxed apps usually need to communicate with the antivirus but normally it's related to information the antivirus tries to send out, be it via a dll that it injects or otherwise. If all the AV program did was scan files when created or ran then these likely wouldn't be needed. However they've gotten much more involved and now cover other aspects which can require getting some information back to its services.

5) This ones a bit tougher to answer as I don't actually know much about windows internals or how exactly sandboxie does what it does related to this level.
Technically I suppose it could happen but at some point a token would need to be used and Sandboxie issues a specific token for things running inside which in turn limits what anything running inside can modify and also routes some APIs through its own handlers.
In addition to all this we should circle back to the security descriptors of the pipes themselves. If the programers created the pipes properly and set up appropriate access control then it already has its own protection from modification. With an AV it would be highly likely they've done this properly otherwise they'd constantly be an attack vector for anything to target since not everyone uses sandboxie.
Something more like the Logitech keyboard might not be as resilient (I can't say one way or the other) it just depends on if the people who made the software bothered to set up proper access control. If someone were to identify a weak pipe that you have also opened up in sandboxie and then created a highly targeted attack for it I can't say that it would be impossible to use it for an escape which is why it's often described as 'punching holes' in sandboxies protection.
Perhaps Curt or someone else who better understands this stuff will be able to answer the question more clearly.
Goo.gl/p8qFCf

Syrinx
Sandboxie Guru
Sandboxie Guru
Posts: 620
Joined: Fri Nov 13, 2015 4:11 pm

Re: [\Device\] entries in Full File Access (OpenPipePath)?

Post by Syrinx » Thu Jan 12, 2017 7:39 pm

Sorry I failed to address one of your earlier questions
So, if the sandboxed applications have FULL access to F-Secure's named pipes, for example, they can control antivirus settings and turn off the antivirus or something similar?
Full Access, as you put it, in this case means Sandboxie isn't blocking like it normally would. That doesn't mean that suddenly a sandboxed program has every possible right if you Open a path. If they [the software involved running outside of the box] have things set up properly (many even have some type of self-protection these days that extends further) they shouldn't be able to abuse the pipes this way.

That said: I am aware of at least one instance in the last few years, with a specific security program which I shall not name, where it was possible to abuse it this way and get it to turn itself off. That instance has been corrected and is no longer vulnerable to that particular attack. I haven't tested F-Secure this way but I'm not really the person who should be doing such tests anyway. I would imagine/hope F-Secure hasn't left itself vulnerable to such an attack. :-/

If you are really worried about it, you can disable the compatibility settings in sandboxie and see if you notice any new problems. If not, you could keep them confined...but you may also be limiting how effective the other protections your AV [eg non scan/signature] product uses are in relation to a sandboxed program, think Anti-Exploit, behavior monitoring and other goodies. It's hard to say for sure as each product is different and they don't usually explain exactly how they do what they do or what type of communication is expected from a monitored program.

So would it be possible to abuse it while using an OpenPipe to turn the AV off while sandboxed? Maybe, but only if the program doesn't have the appropriate security in the first place - It'd be down to just like it is if the program wasn't running sandboxed at all but (perhaps) a bit harder to pull of while sandboxed.
Goo.gl/p8qFCf

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest