Hi, >>> TLDR: >>> (i) stealing SYSTEM access from winlogon.exe is not a good thing to do >> >> >> This doesn't happen for the majority of use cases - only when iservice is >> not used. We also >> elevate only for the single DeviceIOControl call. > > I understand. But stealing access token from winlogon.exe is a hack and not > something I would expect to see in a trustworthy executable. Diagnostic > and forensic tools may be justified in doing such things.
Wintun has a hardcoded check to allow ring registration from the SYSTEM user
only.
To be honest: I am using a Windows 10 VPC in test mode with a modified Wintun
driver installed that also allows ring registration for the members of
Administrators group. This allows me to quickly test ideas while
reviewing/upgrading Lev's work. I can run Visual Studio to compile openvpn.exe
on my computer as an unprivileged user. Then have an elevated Remote Debugger
running on the VPC and Visual Studio to remotely run openvpn.exe with debugger
attached with a single F5 click.
Having to use OpenVPN GUI and iservice, or running openvpn.exe as service would
require a lot more clicks to replace the binary, attach debugger etc.
As far as I am concerned, this elevation hack may be removed from the OpenVPN
source code in the final release. However, mind that this would prevent people
from running openvpn.exe+Wintun from the command line.
>>> +bool
>>>
>>>> +impersonate_as_system()
>>>> +{
>>>
>>> This is implemented by stealing the access token from
>>> winlogon.exe. I don't think such tricks belong to OpenVPN.
>>> It may also trip some anti-virus software.
>>>
>>> That said, probably there are no "legitimate" ways of getting
>>> LOCAL SYSTEM rights on Windows without running a service.
>>>
>>> Why does wintun require SYSTEM for using it? If there is a
>>> good reason for that, we should not let every admin
>>> user bypass it.
>>
>>
>> I'll defer it to Simon.
Unfortunately, I don't do security decisions in Wintun.
Wintun was originally designed for WireGuard. WireGuard is architectured to run
all its tunnels as Windows services running as the SYSTEM user. Wintun's
security is as tight as possible so the WireGuard can barely use it. I know a
guy who is tempted to introduce a userspace binary code signature check to the
Wintun. :)
Given the relative ease to get SYSTEM token just by being an elevated process —
mind there's also a hack to get from non-elevated to elevated completely
bypassing the UAC prompt as long as you are a member of Administrators — this
SYSTEM restriction really doesn't provide considerable additional security
compared to being a member of Administrators group.
>>> Those who really need to test OpenVPN with wintun from
>>> command prompt can use diagnostic tools available to get
>>> a cmd prompt as system (e.g., psexec). That also makes
>>> it explicit that SYSTEM privilege is required.
>>>
>>> In the longer run, we could provide a script to launch
>>> openvpn.exe using the interactive service. Modifying the
>>> automatic service to use interactive service for launching
>>> looks easy to do as well. Then, all privileged operations could
>>> be removed from openvpn core.
>>
>>
>> I think it is good not to break user experience and allow run openvpn as
>> an administrator without iservice using wintun at the expense on elevation
>> to system for single API call.
>
> I have already said what I think of it. As an admin I wouldn't like to see
> users running processes that elevate to SYSTEM like this.
Selva, Windows is full of such hacks internally. :( This is no excuse for us
doing the same of course. Just saying Windows is far from ideal world.
I am running OpenVPN on Windows using NSSM wrapper for years. I had a brief
discussion on the Hackathon with Samuli about integrating SCM support directly
into openvpn.exe (imagine --daemon for Windows):
sc create OpenVPN$MyTunnel binpath= "C:\Program Files\OpenVPN\bin\openvpn"
--daemon --config "C:\Program Files\OpenVPN\config\MyTunnel.ovpn" --log
"C:\Program Files\OpenVPN\log\MyTunnel.log" start= auto depend= dhcp
sc start OpenVPN$MyTunnel
This would install openvpn.exe as a Windows service and run it as the SYSTEM
user — no need for iservice, no need for SYSTEM token hack. Other than me,
perhaps it could cover at least some of the users now running openvpn.exe
directly.
Regards,
Simon
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
