#31022: Tor's windows "--service install" should warn if it installs on a global writeable path ------------------------------+------------------------------------------- Reporter: asn | Owner: (none) Type: defect | Status: new Priority: Medium | Milestone: Tor: 0.4.2.x-final Component: Core Tor/Tor | Version: Severity: Normal | Keywords: hackerone bug-bounty security Actual Points: | Parent ID: Points: 0.3 | Reviewer: Sponsor: | ------------------------------+------------------------------------------- Seems like there is a platform-specific (windows) configuration-specific (requires multi-user setup, and specific install proceedure) local root exploit on Windows, if "--service install" is used on the wrong directory level.
In the future we should warn if "--service install" is used insecurely, and we should provide installer wizards to do this right. IMO this is a very unlikely issue so I assigned it to 042, but feel free to move if you think so. Report inlined: {{{ Title: When tor.exe is running as a Windows service, it may be subject to privilege escalation Scope: None Weakness: Privilege Escalation Severity: Low Link: https://hackerone.com/reports/602533 Date: 2019-06-06 18:17:39 +0000 By: @xiaoyinl Details: According to https://2019.www.torproject.org/docs/faq#NTService, you can run Tor as a Windows service. To install Tor as a service, you run `tor --service install`. However, the installed Tor service uses the same tor.exe image path as the service path. The Tor service runs under `NT authority\local service` account, so if an admin unzips tor.exe into a folder that is writable by non-admin users (e.g. C:\tor), then a malicious standard user can gain LocalService privilege by planting a malicious DLL into the folder where tor.exe is located. To make things worse, it's common that admins unzip tor.exe into a nonadmin-writable directory, because if it's unzipped into one of the admins' user directories (like Downloads, Documents, etc.), then the service won't even run, because LocalService account has no access to admin's directories. Actually, the OP of https://trac.torproject.org/projects/tor/ticket/29345 "fixed" his problem by unzipping tor into C:\\: > In fact, if you extract tor files in a Tor folder located in C:\ you probably won't have this problem of permissions This unfortunately made him vulnerable to privilege escalation. **Reproduce**: 1. download Tor from https://www.torproject.org/dist/torbrowser/8.5.1/tor- win32-0.3.5.8.zip 2. unzip it into C:\\tor-win32-0.3.5.8. 3. Open an admin command prompt, run C:\\tor-win32-0.3.5.8\\Tor\\tor.exe --service install 4. Log in a standard Windows user, create a malicious iphlpapi.dll, and copy this file into C:\\tor-win32-0.3.5.8\\Tor\\ 5. Restart your system. The malicious iphlpapi.dll should run. **Fix**: To fix this bug, when installed as a service, copy Tor's executable folder into a protected directory, like C:\\Program Files, or C:\\Windows. Then use the protected tor.exe as the service path. ## Impact A malicious Windows local standard user can gain LocalService privilege. He can then deanonymize Tor traffic, and can interfere other Windows services running on LocalService account. 2019-06-07 10:04:29 +0000: @xiaoyinl (comment) This report is about local privilege escalation. There is no social engineering involved. The attacker is a **local** non-administrator user, so the attacker can copy the malicious dll file to `C:\tor- win32-0.3.5.8\Tor\` himself. Then the attacker can have access to LocalService data files and Registry hives. }}} -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31022> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs