Consider anything signed by "Microsoft Corporation" to not be an untrusted module
Categories
(Core :: DLL Services, defect, P3)
Tracking
()
People
(Reporter: gstoll, Assigned: gstoll)
References
Details
Attachments
(3 files, 4 obsolete files)
We attempt to do this already in ModuleEvaluator::GetTrust(), but on my system I see the following three DLLs on about:third-party -
- msvcp140.dll
- vcruntime140.dll
- vcruntime140_1.dll
All of these DLLs have two digital signatures: one by "Microsoft Windows Software Compatibility Publisher" and one by "Microsoft Corporation". On about:third-party, the "Microsoft Windows Software Compatibility Publisher" is the one that shows up.
Fixing this would mean less clutter for about:third-party (and less irrelevant telemetry as well)
Note that I'm assuming that this is two separate signatures; if there's some sort of chain here where "real" third-party DLLs can have a signature by "Microsoft Corporation" then we should reevaluate this.
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 1•2 years ago
|
||
After digging into this a bit, the data we're getting back from the Windows API CryptMsgGetParam() (in the SignedBinary constructor) doesn't match what Windows Explorer is showing. For msvcp140.dll, for example, the API only shows the "Microsoft Windows Software Compatibility Publisher" signer. I'm not sure if this is a limitation of the API or if I'm not querying it in the right way or something. Regardless, I'm going to shelve this work for now since it's a fairly minor issue.
| Assignee | ||
Comment 2•2 years ago
|
||
OK, I poked around some more. The "extra" signatures are coming from various catalog files.
Ideally, we would look in the catalog files to see if there are any signatures by Microsoft and, if so, treat the DLL as not third-party. We already have some code to do something like this, but for some reason it's not finding the catalog signatures that sigcheck from Sysinternals is finding.
I'm going to keep trying to make this work. A backup plan would be to add "Microsoft Windows Software Compatibility Publisher" to the list of signatures that count as MIcrosoft ones, but I think that would be a bit less reliable than the first plan.
| Assignee | ||
Comment 3•2 years ago
|
||
I've spent some more time on this and am stuck getting the catalog files. It's also weird that the way that we get the hash of the file (CryptCATAdminCalcHashFromFileHandle2) doesn't seem to match what I get when I actually hash the file contents with certutil.exe.
Anyway, after thinking about it some more I think extending the check to "Microsoft Windows Software Compatibility Publisher" is good enough for our purposes; it still indicates an ownership by Microsoft. So I'm going to do that.
| Assignee | ||
Comment 4•2 years ago
|
||
Updated•2 years ago
|
| Assignee | ||
Comment 5•2 years ago
|
||
After some discussion on Phabricator it seems like some third-party DLLs on some other systems have their first signature as "Microsoft Windows Hardware Compatibility Publisher". This makes me uneasy about my proposed solution. I think if we want to fix this we have to figure out how to get the signature from the catalog file and compare it with "Microsoft Corporation".
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 6•2 years ago
|
||
To answer some of my past questions:
- Looking at msvcp140.dll specifically, it has multiple signatures in the file; there is no signature for it in the catalog file, so that's not the problem. You can see this by running
sigcheck -i c:\windows\system32\msvcp140.dlland seeing that none of theCatalog:lines end with.cat- instead they all just list the path to the file. - Given that, this isn't really relevant anymore, but the hash algorithm that
CryptCATAdminCalcHashFromFileHandle2uses by default is PESHA1, whichcertutildoesn't support anyhow.
| Assignee | ||
Comment 7•2 years ago
|
||
| Assignee | ||
Comment 8•2 years ago
|
||
Depends on D179552
| Assignee | ||
Comment 9•2 years ago
|
||
Depends on D179553
| Assignee | ||
Comment 10•2 years ago
|
||
For the record, the "Microsoft Corporation" certificate was nested inside the first certificate - see part 2 of the patch for more details.
Updated•2 years ago
|
| Assignee | ||
Comment 11•2 years ago
|
||
| Assignee | ||
Comment 12•2 years ago
|
||
Depends on D180386
| Assignee | ||
Comment 13•2 years ago
|
||
Depends on D180387
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 14•2 years ago
|
||
Comment 15•2 years ago
|
||
Backed out for causing build bustages in toolkit/xre/dllservices/mozglue/Authenticode.cpp
Backout link: https://hg.mozilla.org/integration/autoland/rev/a07bfd2d12e37ba92fd66a563b49fd9feb7e0357
Comment 17•2 years ago
|
||
Comment 18•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/4c5de376b6dd
https://hg.mozilla.org/mozilla-central/rev/61c1cf6e1be4
https://hg.mozilla.org/mozilla-central/rev/eb926a42fef7
Updated•2 years ago
|
Description
•