cover safe elevated usage (disallow trivial escalation in that case) about cbwin HOT 4 CLOSED

Although the problem seems not easy to fix in WSL (see the linked BashOnWindows issue for a discussion about that), I'm still thinking about implementing the approach described above on my side. Given the implication on the underlying layers, and the fact I can do nothing about that, I'm likely to add a flag to explicitly allow elevated execution and conveying the fact that this still imply a security risk in regard to UAC effectiveness. (I will probably even add that flag first.)

from cbwin.

Win PID of processes doing a TCP connection are not updated after the connect in the lists returned by iphlpapi, but it seems that they are also never recycled (scenario I try to cover: the original process that did the connect does not exist anymore). I asked for confirmation on microsoft/WSL#652, because I have no proof that this is reliable, only I never got any recycling for Win PID listed by iphlpapi while leveraging the birthday paradox with a few thousands of processes in my tests.
The highest PID was around 70000, with 500 died-after-connect processes and 2000 "attacking" ones, and with the simplifying hypothesis of random allocations, the proba of no collision by "chance" is negligible -- and I did similar tests several times -- so the question that remains is: does this happen to be like that right now because of implementation details, or is this an actual architectural guarantee of Windows. If this is, this actually simplifies the code I need to write (compared to what I thought at first), because we can simply try to open the process by its Win PID (while we keep our end of the connection open): if it is still there (and we have enough perms) we will be able to open it AND know that it is actually the process that did the connection, otherwise we can drop it.

Note: I also found that blog entry from an MS employee: https://blogs.msdn.microsoft.com/michael_howard/2005/10/23/acls-on-sockets/
At first I thought this would secure loopback TCP connections with an ACL (obviously, this would be impossible for non-loopback TCP connections), but I tested it and this is not the case. So I don't really understand when this ACL is applied and against what kind of threat this is useful.

I also took a look at the Windows Firewall which seems impossible to use for this application for at least three reasons: configuration must be done by an admin (whereas I need dynamic conf by non-admins), it is not guaranteed to be activated, and it is bypassed for localhost connections.

So I think, for a first level of security, GetExtendedTcpTable(... TCP_TABLE_OWNER_PID_CONNECTIONS ...)+OpenProcess+OpenProcessToken+AccessCheck is the way to go. This let me avoid to read even a single byte from unauthorized clients. In a second time I will be able to try to unelevate when needed. Unfortunately, a call of GetExtendedTcpTable(... TCP_TABLE_OWNER_PID_CONNECTIONS ...) for each process launch will technically yield a total of O(n**2) entries read for n processes launches -- but I suspect this will not be too much of an actual issue with n < a few thousands.

from cbwin.

Commit c4748ff implements access control using the method described in the previous comment. For now only the user is checked, so UAC bypass using an elevated outbash.exe is not prevented yet. This will be implemented in a future commit.

from cbwin.

Commit 6e77697 adds integrity level to the access control check.

from cbwin.