Hi,
On Mon, Dec 16, 2019 at 5:18 PM Simon Rozman <si...@rozman.si> wrote:
>
> 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.
That's the point. It probably provides no extra security because we
are forced to take the blame for using hacks to cross security
boundaries. And, bypassing UAC is quite different from acquiring
rights you were not supposed to have. Does openvpn wants to be doing
that?
>
> 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.
In this particular case this has nothing to do with Windows -- its
just a stupid decision by wintun that requires the use of undocumented
hacks to elevate to SYSTEM.
>
> 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.
This is not the direction I want to see us moving towards. Instead I
want to see us daemonizing OpenVPN.exe as LOCAL SERVICE or a custom
service user and delegate privileged operations to a separate service
running as SYSTEM. And we already have the latter: interactive
service. So, not even admin rights is needed in openvpn.exe, let alone
SYSTEM.
IMO, the right approach on Windows is to run a bare minimal code as a
service to get SYSTEM rights and the rest with limited privileges.
Selva
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
