Opened 3 years ago

Last modified 12 months ago

#12736 new defect

DLL hijacking vulnerability in TBB

Reported by: underdoge Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-security, TorBrowserTeam201608
Cc: gk, tom@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The current version of TBB is vulnerable to DLL hijacking. Vanilla Firefox is NOT vulnerable.
Steps to reproduce:
1) Create a malicious dll (source code for example is added)
2) Rename the malicious dll to ".DLL" using the commandline tool ren.exe, because windows explorer prohibits such names
3) Place ".DLL" into a folder listed in the %PATH% environment variable
4) Start DbgView.exe (a tool from microsoft) to get text outputs from the dll
5) Start Tor Browser Bundle

You will now see something similiar to:
HIJACKDLL (C:\...\.DLL) Started from: C:\...\TorBrowser\Browser\firefox.exe as user Admin

This bug will probably be also triggered when TBB is registered as a default file handler and the malicious dll is in the same folder as the file opened by TBB. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx for more information about DLL load order. But I haven't confirmed it yet, because I don't know in which cases the TBB could be opened as a default file handler.Carpet Bombing might also be possible. http://www.dhanjani.com/blog/2008/05/safari-carpet-b.html

Possible attack scenario would be an attacker who shares an url link file in a folder along with a hidden ".DLL" and the victims opens the url link file with TBB. Native code execution can then be used to unmask the user.

".DLL" smells like sprintf(DLLToLoad, "%s.DLL", EmptyDLLString)

Tested on:
Win7x64
Tor Browser 3.6.3-Windows

Child Tickets

Attachments (1)

dlltest.c (807 bytes) - added by underdoge 3 years ago.
dlltest.c

Download all attachments as: .zip

Change History (15)

Changed 3 years ago by underdoge

Attachment: dlltest.c added

dlltest.c

comment:1 Changed 3 years ago by underdoge

Priority: normalmajor

comment:2 Changed 3 years ago by gk

Keywords: tbb-security added; DLL-Hijack vulnerability code execution removed
Version: Tor: unspecified

comment:3 Changed 3 years ago by gk

Cc: gk added

comment:4 Changed 3 years ago by tom

Cc: tom@… added

comment:5 Changed 3 years ago by mikeperry

Is it our use of the Portable-App style directory layout (where we reset env vars for PATH) that triggers this?

If not, what else does vanilla Firefox do that makes them not vulnerable to this attack?

comment:6 Changed 17 months ago by gk

Keywords: TorBrowserTeam201608 added
Severity: Normal

comment:7 Changed 16 months ago by cypherpunks

I tested TBB 6.0.3 on a clean Windows 7 system. Per procmon, TBB is looking for a .DLL, searching in the Browser dir, system dirs and Path:

firefox.exe 1920 CreateFile C:\Tor Browser\Browser\.DLL NAME NOT FOUND
firefox.exe 1920 CreateFile C:\Windows\SysWOW64\.DLL NAME NOT FOUND
firefox.exe 1920 CreateFile C:\Windows\system\.DLL NAME NOT FOUND
firefox.exe 1920 CreateFile C:\Windows\.DLL NAME NOT FOUND
firefox.exe 1920 CreateFile C:\Windows\SysWOW64\.DLL NAME NOT FOUND
firefox.exe 1920 CreateFile C:\Windows\.DLL NAME NOT FOUND
firefox.exe 1920 CreateFile C:\Windows\SysWOW64\wbem\.DLL NAME NOT FOUND
firefox.exe 1920 CreateFile C:\Windows\SysWOW64\WindowsPowerShell\v1.0\.DLL NAME NOT FOUND

If ".DLL" exists, it is loaded and executed (DllMain is called):
firefox.exe 2412 CreateFile C:\Tor Browser\Browser\.DLL SUCCESS
firefox.exe 2412 QueryBasicInformationFile C:\Tor Browser\Browser\.DLL SUCCESS
firefox.exe 2412 CloseFile C:\Tor Browser\Browser\.DLL SUCCESS
firefox.exe 2412 CreateFile C:\Tor Browser\Browser\.DLL SUCCESS
firefox.exe 2412 CreateFileMapping C:\Tor Browser\Browser\.DLL SUCCESS
firefox.exe 2412 Load Image C:\Tor Browser\Browser\.DLL SUCCESS
firefox.exe 2412 CloseFile C:\Tor Browser\Browser\.DLL SUCCESS

A "normal" Firefox doesn't look for a ".DLL". So TBB presumably somewhere constructs a DLL name with a blank base name.

At least with a current Windows version, the problem doesn't seem too bad. It doesn't look in the current directory for a ".DLL".

comment:8 Changed 16 months ago by cypherpunks

This is somehow triggered by HTTPS Everywhere. TBB doesn't look for the ".DLL", if HTTPS Everywhere is disabled.

comment:9 Changed 16 months ago by boklm

I didn't try to do some debugging yet, but after looking at the HTTPS Everywhere code, I am wondering if it could be caused by the NSS.initialize function:
https://gitweb.torproject.org/https-everywhere.git/tree/src/chrome/content/code/NSS.js?id=7035dde6b76eb8be458d410768188d9cd5d09f89#n28

  try {
    sharedLib = tcypes.open(nssPath);
  } catch (e) {

when nssPath is empty when called from:
https://gitweb.torproject.org/https-everywhere.git/tree/src/components/ssl-observatory.js?id=7035dde6b76eb8be458d410768188d9cd5d09f89#n126

  try {
    NSS.initialize("");
  } catch(e) {

comment:10 Changed 16 months ago by boklm

Vanilla firefox is also affected by this issue when HTTPS Everywhere is installed.

I opened #19976 with a patch to fix the issue in HTTPS Everywhere.

Whith this patch applied, firefox.exe is no longer trying to find a .DLL library.

comment:11 Changed 12 months ago by gk

The remaining things to do here are dealing with DLLs loaded from the directory Tor Browser got started from, see: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx.

comment:12 Changed 12 months ago by boklm

If there is some way to run Tor Browser with a current working directory containing a malicious DLL, I am not sure that this DLL could be loaded, as the current directory comes after the application directory and the system directories in the search order, according to https://msdn.microsoft.com/en-us/library/ms682586.aspx.

The only exceptions that I see that would allow loading a DLL from the current directory seems to be that:

  • the user disabled the SafeDllSearchMode option (which is enabled by default in current versions of Windows)
  • Tor Browser uses a DLL that is neither present in its application directory, or in the Windows and System directories, but present in a directory listed in the PATH environment variable.

comment:13 Changed 12 months ago by gk

Yes with "directory Tor Browser got started from" I meant the application directory not the current directory (sorry for not being more explicit).

comment:14 Changed 12 months ago by gk

It seems there is a way to override SafeDllSearchMode to make sure that system32 is always checked first. According to Mozilla folks this can even be done by using a registry switch:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\firefox.exe

+ setting a QWORD named MitigationOptions to (0x1000 0000 0000 0000).

Might be a thing our NSIS script could do if that's the way we want to go? I have not tested this at all nor am sure if that's available on all Windows versions (maybe this is just for Windows 10 available: https://blogs.msdn.microsoft.com/oldnewthing/20161013-00/?p=94505#comment-1268775 ? and https://blogs.msdn.microsoft.com/oldnewthing/20161013-00/?p=94505 in general for a discussion about the problem)

Note: See TracTickets for help on using tickets.