8

I was trying to work with Named Pipe as a communication channel between injected stubs in various processes.

I was reading and it states

Process Isolation

Sandboxing the application kernel objects, the AppContainer environment prevents the application from influencing, or being influenced by, other application processes. This prevents a properly contained application from corrupting other processes in the event of an exception.

It also states here that

Windows 10, version 1709: Pipes are only supported within an app-container; ie, from one UWP process to another UWP process that's part of the same app. Also, named pipes must use the syntax "\.\pipe\LOCAL\" for the pipe name.

Does this mean I can no longer access kernel objects from NtFsControlFile (FSCTL_PIPE_LISTEN, FSCTL_PIPE_WAIT, FSCTL_PIPE_DISCONNECT) to communicate with pipes in other processes than my own App Container? Or is it simply saying that the semantics of this operation changed?

My question is, does this change implicate an actual problem, or can I still use one named pipe from one process to talk with another; but it's not advised to do so?

  • 2
    You can only use a named pipe to communicate either between two UWP processes that are part of the same app, or between two non-UWP processes. I don't believe `NtFsControlFile` will work at all in a UWP process. – Ross Ridge Sep 29 '17 at 23:20
  • 2
    Ooooh, so UWP is specifically if I want to deploy an app from the Windows App Store? Haha, okay thats silly they even mention it. I'm not making an app for the windows app store. My app is going to be downloaded by the users of my website from my page, deployed outside the windows app store. That's fine then, thanks! I just misunderstood the explanation. –  Sep 29 '17 at 23:24
  • 3
    Yah, if you're not interested in selling your application through the Windows Store then it doesn't need to be an UWP app, and so you don't have to worry about any of this. – Ross Ridge Sep 29 '17 at 23:27
  • It might still be an issue if you intend to inject into UWP processes. Although I doubt the sandboxing affects the kernel. – Harry Johnston Sep 29 '17 at 23:54
  • Why is it silly to mention this. Don't UWP devs deserve documentation? – David Heffernan Sep 30 '17 at 06:05
  • 6
    @DavidHeffernan: It's silly because assuming what Ross wrote is right the documentation is wrong. It should say "**Windows Store apps**: ..." The current text makes it look as if it applies to *all* applications since 1709. Hence this question. See for example the documentation for [`CreateFile2`](https://msdn.microsoft.com/en-us/library/windows/desktop/hh449422(v=vs.85).aspx), [`TlsAlloc`](https://msdn.microsoft.com/en-us/library/windows/desktop/ms686801(v=vs.85).aspx) (and the rest of `TlsXxx` funcstions), etc. – conio Oct 01 '17 at 03:43
  • @conio thank-you for the emphasis. I think so too! It confused me. –  Oct 01 '17 at 06:48
  • @HarryJohnston: Hmm. My application does inject into other processes, which may be UWP. So say, if I created a named pipe server by calling `CreateNamedPipe` from a non-UWP app (or a service), provided that it has the ACL that grants access, can my remote thread injected into a UWP process succeed in calling `ConnectNamedPipe` or `CreateFile(OPEN_EXISTING)` on that same named pipe? – c00000fd Nov 09 '17 at 01:09
  • @c00000fd, if not, you could always create the client handle in your server and duplicate it into the UWP app at the same time that you inject the thread. – Harry Johnston Nov 09 '17 at 04:45
  • @HarryJohnston: Hmm. Yeah, I guess. It's just such a weird restriction to impose on something that has been working so well. I'll have to install that v.1709 and try it out... – c00000fd Nov 09 '17 at 07:08
  • @c00000fd, not so weird, named pipes are an obvious target for attackers trying to escape from the UWP sandbox. – Harry Johnston Nov 09 '17 at 07:20
  • @HarryJohnston: Well in that case they also need to address: file mapping objects, file system itself, mail slots, RPC, raw sockets, and ... Windows architecture in general. Heck, a hacker can probably code messages back and forth in hundreds of named events using them for some sort of binary code transmission. – c00000fd Nov 09 '17 at 07:31
  • @c00000fd, AFAIK, the sandbox does restrict access to all those things. Not named events, of course, but it is unlikely to be feasible to gain code execution via an attack against named events. (You can of course use them for communication between cooperating processes, but that isn't what the sandbox is trying to block, it just wants to prevent a malicious or compromised UWP app from attacking a non-malicious desktop app.) – Harry Johnston Nov 09 '17 at 07:41
  • ... I'm not sure, but I suspect that prior to 1709 a sandboxed app wasn't allowed to use named pipes at all. Of course that wouldn't necessary affect injected code, since it isn't subject to the certification process. – Harry Johnston Nov 09 '17 at 07:43
  • @HarryJohnston: Why not? It runs in a thread just like any other code in that process. But, you raised a good question. I'll check tomorrow. – c00000fd Nov 09 '17 at 08:00
  • @c00000fd, see [The app certification process](https://learn.microsoft.com/en-us/windows/uwp/publish/the-app-certification-process). I don't think you're submitting your injected code to Microsoft! – Harry Johnston Nov 09 '17 at 08:08
  • @HarryJohnston: Yes. I know how UWP certification works. I have my apps in the Windows store. What I'm saying is that the code injection happens into an already running (certified) UWP app via `CreateRemoteThread` function. Heck, if you want you can inject it even into a start menu on Windows 10 that is a UWP app of sorts. – c00000fd Nov 09 '17 at 08:13
  • @c00000fd, you probably know more about it than I do then. As far as I understand things, some of the rules about what you're allowed to do in a UWP app are enforced by the kernel, and some of them are enforced by the certification process. Injected code can bypass the second kind, but not the first kind. I'm speculating that "you aren't allowed to use named pipes" was a restriction of the second kind which has now been replaced with "you can only use named pipes in a safe way" which is a restriction of the first kind. – Harry Johnston Nov 09 '17 at 08:20
  • The documentation...I will be damm if the normal app are not able to use namedpipe as there is not app-container for normal .NET framework app? Namedpipe can be target of impersonator, so I even consider to check GetNamedPipeClientProcessId if the client process use the namedpipes is my process by checking the name, or it is possible to check the signing certificate of the process exe. I don't know any more security that @c0000fd mention, sound like very low level hacking. I am cool if there is a decent method to check the namedpipe message is not impersonated, anyone can point me direction? – Edward Chan JW May 20 '18 at 15:53

0 Answers0