Closed Bug 1634538 Opened 2 months ago Closed 2 months ago

DLL block request: BLEtokenCredentialProvider.dll

Categories

(Toolkit :: Blocklist Policy Requests, defect)

Unspecified
Windows
defect

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox77 --- fixed
firefox78 --- fixed

People

(Reporter: jaws, Assigned: jaws)

References

Details

Attachments

(2 files)

Assignee: nobody → jaws
Status: NEW → ASSIGNED

Do we have any confirmation that this patch fixes the issue?

Flags: needinfo?(jaws)

Gabriele, do you know how we can confirm this patch?

Flags: needinfo?(jaws) → needinfo?(gsvelto)

I'll move the ni? over to Toshi, who can look at the call stack in the third-party modules ping and confirm whether call stack is safe to block. If it is safe to block, he can r+.

(As a note to Toshi, it would be nice if blocklist requests that reference the third party modules ping were able to include a direct link to the call stack for the load. Can we set up a query or something that would make this easy for both the requester and the recipient to examine?)

Flags: needinfo?(gsvelto) → needinfo?(tkikuchi)

Gabriele, if you don't mind, could you share the dump? I'm sure you investigated it thoroughly, but I just want to double check :).

Looking at the third-party modules ping in the last 30 days, here's the callstack seen in Win10. All instances are from the browser process. Version is nothing but 2.1.63.0.

0 firefox!mozilla::freestanding::patched_LdrLoadDll(wchar_t*, unsigned long*, _UNICODE_STRING*, void**)+0x1df
1 kernelbase!LoadLibraryExW+0x170
2 combase!LoadLibraryWithLogging(LoadOrFreeWhy, wchar_t const*, unsigned long, HINSTANCE__**)+0x2c
3 combase!static CClassCache::CDllPathEntry::LoadDll(DLL_INSTANTIATION_PROPERTIES&, HRESULT (*&)(_GUID const&, _GUID const&, void**), HRESULT (*&)(HSTRING__*, IActivationFactory**), HRESULT (*&)(), HINSTANCE__*&)+0x56
...snip...
19 combase!static CComActivator::DoCreateInstance(_GUID const&, IUnknown*, unsigned long, _COSERVERINFO*, unsigned long, tagMULTI_QI*, ActivationPropertiesIn*)+0x169
20 combase!CoCreateInstance(_GUID const&, IUnknown*, unsigned long, _GUID const&, void**)+0x106
21 credprovhost!CCredentialProviderThread::_CreateCredentialProvidersFromRegKey(unsigned short const *,bool)+0x2e0
22 credprovhost!CCredentialProviderThread::_CreateCredentialProviders()+0x40
23 credprovhost!CCredentialProviderThread::_vThreadProc()+0x17d
24 credprovhost!CCredentialProviderThread::_sThreadProc(void *)+0x98
25 kernel32!BaseThreadInitThunk+0x14
26 ntdll!RtlUserThreadStart+0x21

(In reply to Aaron Klotz [:aklotz] from comment #4)

(As a note to Toshi, it would be nice if blocklist requests that reference the third party modules ping were able to include a direct link to the call stack for the load. Can we set up a query or something that would make this easy for both the requester and the recipient to examine?)

I totally agree. It could not happen anytime soon due to technical difficulty in our telemetry infrastructure, but in the long term, we should have a handy website or something.

Flags: needinfo?(tkikuchi) → needinfo?(gsvelto)

Sent the minidump.

Flags: needinfo?(gsvelto)

While the thread was shutting down, BLEtokenCredentialProvider.dll caused double free, resulting in the crash. This means the crash happened some time after the module was loaded. Anyway, without a local repro, we cannot investigate it further. Blocking it to stop the crash is reasonable.

Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ebfcd5bccbf1
Add BLEtokenCredentialProvider.dll to the DLL blocklist for causing crashes while opening the Windows Hello authentication prompt. r=tkikuchi
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78

Jared, do you want to uplift to beta?

Flags: needinfo?(jaws)

Comment on attachment 9144832 [details]
Bug 1634538 - Add BLEtokenCredentialProvider.dll to the DLL blocklist for causing crashes while opening the Windows Hello authentication prompt. r?aklotz

Beta/Release Uplift Approval Request

  • User impact if declined: Users may experience a Firefox crash when using the new OS authentication feature of Lockwise. This feature is disabled by default in 77 but we may run a Normandy study during 77 so it would be good to have this uplifted.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Adds an old unsupported DLL to the blocklist.
  • String changes made/needed: none
Flags: needinfo?(jaws)
Attachment #9144832 - Flags: approval-mozilla-beta?

Comment on attachment 9144832 [details]
Bug 1634538 - Add BLEtokenCredentialProvider.dll to the DLL blocklist for causing crashes while opening the Windows Hello authentication prompt. r?aklotz

Approved for our last beta, thanks.

Attachment #9144832 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.