1685977 - DLL hijacking

Status: RESOLVED DUPLICATE of bug 1682101

(Thunderbird :: Security, enhancement)

Description

[ssantos]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36 OPR/73.0.3856.284

Steps to reproduce:

DLL hijacking is an "usual" problem. The program does not check for where the library is really loaded from and a malicious DLL could be placed by the attacker and used by the program.

Thunderbird searchs for:

mscms.dll
audioses.dll
umpdc.dll
cryptsp.dll
otr-5.dll
msasn1.dll
dbgcore.dll
kbdus.dll

Actual results:

A malicious DLL could be placed in the executable directory and it will be loaded.

Yes, the attacker may need writing access to the same directory where the program is. But, this trick may be used by malware to be loaded under Thunderbird context and bypass some security checks. For example VMware and others solved this problem because of actual malware using this way to be loaded in memory.

https://www.vmware.com/security/advisories/VMSA-2019-0007.html

Expected results:

The program should not check for unnecessary DLLs to load or check for signed DLLs.

Comment 1

[Kai Engert (:KaiE:)]

The issue regarding the OTR library had been earlier reported in bug 1682101, and has been fixed already, CVE-2021-29949.

The OTR library is one of the libraries that Thunderbird ships, so it makes sense to check that we load the one we distribute, not another one.

The other libraries you have listed above aren't Thunderbird libraries. They appear to be OS dependencies.

We obviously need to to load them from the system path. I don't see how Thunderbird could apply any protection mechanism for those?

Comment 2

[Magnus Melin [:mkmelin]]

(In reply to Kai Engert (:KaiE:) from comment #1)

We obviously need to to load them from the system path. I don't see how Thunderbird could apply any protection mechanism for those?

Agreed.
ssantos, what do you think?