Closed Bug 1499020 Opened 2 years ago Closed 2 years ago
Crash in js::Get
Array Buffer View Length And Data
This bug was filed from the Socorro interface and is report bp-6d215931-804b-4879-9919-821120181012. ============================================================= Top 10 frames of crashing thread: 0 xul.dll js::GetArrayBufferViewLengthAndData js/src/vm/ArrayBufferObject.cpp:2086 1 xul.dll mozilla::dom::TypedArray_base<unsigned char, &js::UnwrapArrayBufferView dom/bindings/TypedArray.h:142 2 xul.dll mozilla::dom::CryptoBuffer::Assign dom/crypto/CryptoBuffer.cpp:61 3 xul.dll mozilla::dom::AesTask::Init dom/crypto/WebCryptoTask.cpp:612 4 xul.dll mozilla::dom::AesTask::AesTask dom/crypto/WebCryptoTask.cpp:537 5 xul.dll mozilla::dom::WebCryptoTask::CreateEncryptDecryptTask dom/crypto/WebCryptoTask.cpp:3251 6 xul.dll mozilla::dom::SubtleCrypto::Decrypt dom/base/SubtleCrypto.cpp:69 7 xul.dll static bool mozilla::dom::SubtleCryptoBinding::decrypt dom/bindings/SubtleCryptoBinding.cpp:5575 8 xul.dll static bool mozilla::dom::SubtleCryptoBinding::decrypt_promiseWrapper dom/bindings/SubtleCryptoBinding.cpp:5589 9 xul.dll mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ConvertExceptionsToPromises> dom/bindings/BindingUtils.cpp:3260 ============================================================= crash reports with this signature started spiking up a few days ago on 2018-10-11 across firefox versions and platforms, so it'll likely be some server-side change that is triggering this crash now. stack traces for those crashes commonly show that some webcrypto code is involved. a number of comments in the crash reports are also referring to captchas on websites, so perhaps google's recaptcha service has added/changed some of its checks recently to weed out real-world machines from bots, and the webcrypto api is part of that. curiously there's a high number of reports purportedly coming from firefox 49.0.2 and even 49.0.2esr(???).
crash addresses from reports of older firefox versions indicate the issue might be sec-sensitive, so hiding the bug as a precaution...
All the recent crashes look safe. Not sure what the deal is with the 49.* ones, but I'm not sure this bug needs to be hidden anyway.
Group: core-security → dom-core-security
Crash Signature: [@ js::GetArrayBufferViewLengthAndData] → [@ js::GetArrayBufferViewLengthAndData] [@ js::Scalar::byteSize]
I have no idea how this is possible. The objects being operated on are either member-local or were specifically checked for being available. Maybe the problem is in JS somewhere?
JC, can you please take a look or delegate if needed?
The newer-version crashes are a lot of null derefs and then crashing at "0xffffffffffffffff" which on Windows often means it got a pointer that wasn't valid. In the raw dump I see "rax": "0xbad0bad1b8fa9310" which looks like someone's pattern for "bad stuff is happening". Not sure if that's ours, a library, or the OS (I don't see "bad0bad1" in our source tree).
All of these stack traces come down to the additional authenticated data being passed to AES-GCM, which is a BufferSource . Buffer Sources are guaranteed not to be thread-safe, but it looks like the data is copied into a CryptoBuffer (using ReplaceElementsAt) at the start of the AES task. So, like Dana in comment 3, I am at a loss. I think to make progress here, we might need to fuzz WebCrypto AES-GCM using AADs. Particularly changing and/or invalid arrays. I'll send an email to the Fuzzing team to ask.  https://www.w3.org/TR/WebCryptoAPI/#aes-gcm-params
We don't need to hide this bug on behalf of possible vulnerabilities in ancient unsupported versions of Firefox. We already _know_ those versions are unsafe.
Surely this is a dupe that will be fixed by bug 1500759
Assignee: nobody → jcoppeard
Depends on: 1500759
Priority: -- → P1
Crash Signature: [@ js::GetArrayBufferViewLengthAndData] [@ js::Scalar::byteSize] → [@ js::GetArrayBufferViewLengthAndData] [@ js::Scalar::byteSize] [@ mozilla::dom::CryptoBuffer::Assign]
This seems to be gone in 64, which is consistent with comment 9.
You need to log in before you can comment on or make changes to this bug.