FPVI & SCSB Disclosure (Feb 12, ‘21)
Categories
(Core :: JavaScript Engine: JIT, task)
Tracking
()
People
(Reporter: freddy, Assigned: jandem)
Details
(Keywords: csectype-priv-escalation, reporter-external, sec-high, Whiteboard: [Disclosure date ≈2021-05-12][reporter-external] [client-bounty-form] [verif?][adv-main87-][adv-esr78.9-][sec-survey])
Attachments
(7 files)
1.42 MB,
application/zip
|
Details | |
508.97 KB,
application/pdf
|
Details | |
1.03 MB,
application/pdf
|
Details | |
1.43 MB,
application/octet-stream
|
Details | |
48 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
RyanVM
:
approval-mozilla-esr78+
tjr
:
sec-approval+
|
Details | Review |
7.45 KB,
patch
|
Details | Diff | Splinter Review | |
419 bytes,
text/plain
|
Details |
I am filing this on behalf of Hany Ragab, Enrico Barberis, Herbert Bos, and Cristiano Giuffrida from the VUSec group at VU Amsterdam, who sent an email to security@mozilla.org:
Hi,
This is to inform you we at VUSec just disclosed two new transient execution vulnerabilities to Intel and AMD. We term such vulnerabilities Floating Point Value Injection (or FPVI) and Speculative Code Store Bypass (or SCSB)---due to the similarities with LVI and Spectre-SSB. We don’t yet know if these have already been disclosed by others, but we wanted to give you all the information as early as possible (due to a long history of communication issues with Intel). We’re currently aiming for a 90-day embargo period.
PFA the same archive disclosed to Intel & AMD, containing: (i) the paper documenting the vulnerabilities and our analysis just submitted to USENIX Security (Winter); (ii) a disclosure overview document briefly introducing FPVI & SCSB, our proposed mitigations, and Proof-of-Concept exploits (PoCs); (iii) two PoCs inspired by real-world applications (browsers) to reproduce FPVI & SCSB.
Note that while our exploits use SpiderMonkey as a point of reference, they’re both native PoCs that cannot directly run in a SpiderMonkey sandbox. We believe producing end-to-end exploits in JavaScript just requires additional engineering effort especially for FPVI, since we have verified the JIT engine is affected. We’re working on end-to-end exploits in ongoing work and we’ll update you as soon as we have results. Luckily, the mitigations are relatively simple. Both issues can be mitigated with Fission. Without Fission, SCSB’s mitigation is straightforward (i.e., use a serializing instruction like lfence on x86 in FlushICache), while FPVI imposes some performance/precision tradeoffs (see disclosure overview and paper for details). We’re concurrently disclosing these issues to Chromium. We’d like to know if you are able to inform other browser vendors besides Chromium.
Please let us know if you have questions/comments, we’re happy to discuss these issues in more detail. Please CC mc@vusec.net in all future communication on this issue. This is to reach the “MC team” disclosing the vulnerabilities, that is “Hany Ragab, Enrico Barberis, Herbert Bos, and Cristiano Giuffrida from the VUSec group at VU Amsterdam”.
Please let us also know if you’d also like this report filed on Bugzilla, as suggested at https://www.mozilla.org/en-US/about/governance/policies/security-group/bugs.
Best,
Cristiano (on behalf of the MC @VUSec team)
PS.: mc@vusec.net is simply an alias for hany.ragab@vu.nl, e.barberis@vu.nl,
herbertb@cs.vu.nl, giuffrida@cs.vu.nl, you can find the corresponding PGP keys here:
https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x409784444f2ac8f2643eb39d0515f11a30c299fa (Hany)
https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x4f6517e19584e1c454d4c36ee2ef4734fc503bda (Enrico)
https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xb9d27a126befc1ba3cdd6866f3e2f9f5fa47c706 (Herbert)
https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x038bd8776dd243469da4df1c7a0c07dcc87edb69 (Cristiano)
Comment 1•4 years ago
|
||
Attached is the decrypted zip
Comment 2•4 years ago
|
||
For convenience here is pdf 1 from the zip
Comment 3•4 years ago
|
||
For convenience here is pdf 2 from the zip
Updated•4 years ago
|
Comment 4•4 years ago
|
||
Hi jandem, could you take a look at these?
My intuition is that SCSB would be a simple mitigation that wouldn't be a big performance impact.
I'm curious how practical we think FPVI is to exploit in practice in the browser; if it requires a Flush+Reload timing attack for each... byte? of the target value, with our timer mitigations this seems like a very slow channel. The mitigation sounds like it would have some measurable performance impact.
Curious to know your thoughts.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Hi Tom,
thanks for opening the issue on our behalf. Quick comments from our end:
SCSB
I'd be surprised if the SCSB mitigation wasn't indeed trivial (code- and performance-wise) given that pretty much the same (serializing) code is already needed for non-x86 architectures for instruction cache flushing.
FPVI
Indeed one needs to implement a Flush+Reload-style covert channel (Evict+Reload) or similar in the browser to leak information. One problem with relying on timer mitigations to break practical exploitation of such channel is that one can bypass them by simply repeating the leak (i.e., with multiple Reload buffers) and amplify the signal. We used a similar technique in the ret2ret2spec (Spectre-RSB) exploit we disclosed in a separate issue (https://bugzilla.mozilla.org/show_bug.cgi?id=1644174). Of course, this will still slow down exploitation by a factor of N (where N is the number of Reload buffers needed to get a signal with the jittery timer), but it's not quite clear where the bar is in terms of leakage rate for practical exploitation.
Also compared to Spectre exploitation based on RSB or BHT mistraining in the browser, FPVI's leakage rate is higher. Since there is no predictor involved, one can repeat one leakage iteration after another without any intermediate steps to (re)train the branch predictor a la Spectre-RSB/BHT. This significantly improves the leakage rate and might be able to compensate for the extra iterations needed to amplify the signal and bypass the timer mitigations. See, for instance, Figure 5 in the paper, where the experiments from Hany & Enrico show the (native) leakage rate of FPVI is almost as fast as the raw Flush+Reload covert channel bandwidth, an improvement of over 5x wrt to classic Spectre-BHT.
Cristiano
Assignee | ||
Comment 6•4 years ago
|
||
Thanks for the great bug report.
Still reading through this, but for SCSB I wonder if this is actually a problem in SpiderMonkey because all of our JIT/Wasm code is W^X, which means we do a relatively expensive mprotect
between writing the code and making it executable. I'd be a bit surprised if this doesn't end up doing a similar cache flush? The PoC uses RWX, it would be interesting to see if it can be made to trigger with similar mprotects
around the memcpy
.
Comment 7•4 years ago
|
||
@Jan
Thanks for the comment!
Re mprotect & SCSB: there are multiple aspects at play here:
-
Having a complex syscall between the "W" and the "X" indeed requires a fairly large transient execution window for exploitation, which might be hard to come by and ultimately stop practical exploits. However, I would worry this "mitigation" is fragile and it'd be better to opt for "security-by-design" mitigations (e.g., Hany & Enrico found surprisingly large windows on some AMD architectures).
-
In theory, syscalls like mprotect() should flush the instruction cache, since the OS faces the same W+X issues as a JIT engine. However, just like common JIT engines, common operating system implementations do not do any flushing on x86 since it's (architecturally) unnecessary. See the implementation of flush_icache_page() in the Linux kernel as an example (no-op on x86).
-
The remaining way syscalls like mprotect() can kill the signal is to use a serializing instruction somewhere. In the case of mprotect(), the mandatory "invlpg" instruction does the trick (as Hany & Enrico confirmed experimentally---this behavior is also explicitly documented in Intel/AMD manuals). But the same might not apply to other syscalls (the "syscall" instruction itself is not documented to be a serializing one, at least).
In short, to implement a future-proof mitigation strategy, IMO a good option is to simply place a cheap lfence instruction (or similar) in the FlushICache() function. Or alternatively, if all the code paths will always go through a mprotect() syscall by design, explicitly document that such paths rely on the mprotect() code itself (e.g., invlpg) to serialize the execution and kill the signal.
Assignee | ||
Comment 8•4 years ago
•
|
||
(In reply to Cristiano Giuffrida from comment #7)
The remaining way syscalls like mprotect() can kill the signal is to use a serializing instruction somewhere. In the case of mprotect(), the mandatory "invlpg" instruction does the trick (as Hany & Enrico confirmed experimentally---this behavior is also explicitly documented in Intel/AMD manuals).
Thanks, that's good to know because this applies to us.
In short, to implement a future-proof mitigation strategy, IMO a good option is to simply place a cheap lfence instruction (or similar) in the FlushICache() function. Or alternatively, if all the code paths will always go through a mprotect() syscall by design, explicitly document that such paths rely on the mprotect() code itself (e.g., invlpg) to serialize the execution and kill the signal.
We have just one caller of FlushICache
, right before we do the VirtualProtect/mprotect
. This was by design: if we flush when we make code executable, we can never forget or miss an ICache flush.
Furthermore, looking at ReprotectRegion
, we already do this right before the mprotect
:
std::atomic_thread_fence(std::memory_order_seq_cst);
I verified this ends up compiling to an mfence
on x64. So I think we're good here for two separate reasons.
Assignee | ||
Comment 9•4 years ago
|
||
For FPVI, when looking at the jit.txt output in the attached zip file, you can see that we generate the following shape guard for the return z[0]
in the JS code:
0000019A 33 d2 xor %edx, %edx
0000019C 49 bb a8 b8 f9 3d bc 3f 00 00
mov $0x3FBC3DF9B8A8, %r11
000001A6 4c 39 59 08 cmpq %r11, 0x08(%rcx)
000001AA 0f 85 c6 02 00 00 jnz 0x0000000000000476
000001B0 48 0f 45 ca cmovnz %rdx, %rcx
000001B4 48 ba 40 d0 f7 3d bc 3f 00 00
... perform the element load ...
The xor
and cmovnz
here are Spectre mitigations: we zero the object register with a cmov
if the object's shape doesn't match what we expect. Isn't this cmovnz
going to thwart the transient execution path here as well? (Unless you manage to get a memory address that has the same shape value stored at offset 8 on the transient path.)
Comment 10•4 years ago
|
||
Dear jandem,
the 000001B0 48 0f 45 ca cmovnz %rdx, %rcx
is never executed during the transient path.
This is what is executed during the transient execution window generated by the FP division:
0000005F f2 0f 5e ca divsd %xmm2, %xmm1
00000063 f2 0f 5e c1 divsd %xmm1, %xmm0
00000067 66 48 0f 7e c0 movq %xmm0, %rax //rax = 0xfffe0deadbeef000 for transient path only (-Infinity for arch path)
0000006C e9 05 00 00 00 jmp 0x0000000000000076
...
00000076 48 8b c8 mov %rax, %rcx
00000079 48 c1 e9 2f shr $0x2F, %rcx
0000007D 81 f9 fc ff 01 00 cmp $0x1FFFC, %ecx
00000083 0f 84 f7 01 00 00 jz 0x0000000000000280 //branch taken: 0xfffe0deadbeef000>>0x2f==0x1fffc
...
00000280 48 ba 00 00 00 00 00 00 fe ff
mov $0xFFFE000000000000, %rdx
0000028A 48 33 d0 xor %rax, %rdx //rdx = 0xdeadbeef000
0000028D 48 8b 0a movq (%rdx), %rcx
00000290 48 8b 09 movq (%rcx), %rcx
(The code above is exactly what you can find in fpvi.S)
As you can see no cmov
is present in this path.
Additionally, cmov
stops the speculation only for the corresponding branch, not the entire FP transient window.
Assignee | ||
Comment 11•4 years ago
|
||
(In reply to Enrico Barberis from comment #10)
(The code above is exactly what you can find in fpvi.S)
As you can see no
cmov
is present in this path.
If I understand correctly, fpvi.S
is based on code generated by SpiderMonkey, especially the first part, but the transient_path:
part is not what SpiderMonkey generates because the JIT would emit extra (shape or similar) guards before loading from the object, as you can see in jit.txt. Is that right?
I'm just making sure I understand what is required to exploit this in our engine.
Comment 12•4 years ago
|
||
(In reply to Jan de Mooij [:jandem] from comment #11)
(In reply to Enrico Barberis from comment #10)
(The code above is exactly what you can find in fpvi.S)
As you can see no
cmov
is present in this path.If I understand correctly,
fpvi.S
is based on code generated by SpiderMonkey, especially the first part, but thetransient_path:
part is not what SpiderMonkey generates because the JIT would emit extra (shape or similar) guards before loading from the object, as you can see in jit.txt. Is that right?I'm just making sure I understand what is required to exploit this in our engine.
fpvi.S
contains only code generated by Spidermonkey. We have just removed the non-executed code for readability.
The code trace that I listed above was verified using gdb by setting a breakpoint to js-shell on 00000067 66 48 0f 7e c0 movq %xmm0, %rax
and then by replacing rax
with 0xfffe0deadbeef000
using set $rax = 0xfffe0deadbeef000
. In this way, we were able to simulate what happens in the transient path.
Unfortunately, our knowledge of Spidermonkey's inner details is very limited. I believe that the transient read 0000028D 48 8b 0a movq (%rdx), %rcx
is made without any shape-guard since the engine is still verifying that 0xdeadbeef000
is an array.
In order for the attack to be successful, the following requirements are needed:
- the
divsd
operands are under attacker controls - shortly after the
divsd
, a tag check is made. This is necessary to perform type-confusion. In the provided PoC, the engine considers0xfffe0deadbeef000
as JSObject. - The type-confusion leads to a Flush+Reload gadget
read reload_buf[ (*((uint32_t *)0xfffe0deadbeef000) & 0xff) << 10 ]
.
Another example that can show how a (partial) desired gadget looks like is:
//always pass s as string to speculative optimize for string arguments
function length(s) {
return (s.length & 0xff)*1024
}
That is jit'ed as follow:
00000005 48 8b 44 24 28 movq 0x28(%rsp), %rax //rax = 0xfffb0deadbeef000 speculatively
0000000A 49 bb 00 00 00 00 00 00 fb ff
mov $0xFFFB000000000000, %r11
00000014 4c 33 d8 xor %rax, %r11
00000017 49 8b c3 mov %r11, %rax
0000001A 49 c1 eb 2f shr $0x2F, %r11
0000001E 0f 85 32 00 00 00 jnz 0x0000000000000056
00000024 8b 40 04 movl 0x04(%rax), %eax //Access length attribute
00000027 25 ff 00 00 00 and $0xFF, %eax
0000002C c1 e0 0a shl $0x0A, %eax
0000002F 48 b9 00 00 00 00 00 80 f8 ff
mov $0xFFF8800000000000, %rcx
00000039 48 0b c8 or %rax, %rcx
0000003C c3 ret
By calling length()
with the transient division result 0xfffb0deadbeef000
, it is possible to perform a transient read to deadbeef004
.
The (... & 0xff)*1024
is just there to provide a first step towards the full desired gadget reload_buf[(s.length&0xff)<<10]
.
Currently, we are trying to build a new PoC using this string length "trick", however, we are having some troubles in making the division and the tag check close enough.
Comment 13•4 years ago
|
||
One additional comment: I guess the real issue here is that NaN-boxing is based on the idea that is not possible to generate FP results in the form 0xfffXXXXXXXXXXXXX
while using FPVI it is possible (in a transient path).
Assignee | ||
Comment 14•4 years ago
|
||
Thanks for your comments. string.length
is indeed an interesting one that doesn't require additional guards.
For FPVI, I can't think of a good JIT mitigation. The option to treat denormals as zero is a nuclear one that's pretty risky because it will affect how (a lot of) code behaves. JS/Wasm code, but also C++ code if we don't restrict it to JS (which is fairly difficult because we often call into the DOM). For example, this post explains how disabling denormals can result in division-by-zero to show up.
Given our timer mitigations and the absence of end-to-end exploits at this point, it's possible we can wait for Fission, which is expected to start rolling out to release in Q3. Unfortunately that does leave a window of a few months.
If we wanted to mitigate this in the JIT, the double-to-Value boxing step is a potential place to do it, maybe a CMP + CMOV on that path to zero the register if it's not a double. The performance overhead of that wouldn't be great though.
Do you have any insight on which floating-point operations are vulnerable to this? For example, is addsd
also affected?
Comment 15•4 years ago
|
||
(In reply to Jan de Mooij [:jandem] from comment #14)
Thanks for your comments.
string.length
is indeed an interesting one that doesn't require additional guards.For FPVI, I can't think of a good JIT mitigation. The option to treat denormals as zero is a nuclear one that's pretty risky because it will affect how (a lot of) code behaves. JS/Wasm code, but also C++ code if we don't restrict it to JS (which is fairly difficult because we often call into the DOM). For example, this post explains how disabling denormals can result in division-by-zero to show up.
I agree DAZ and FTZ is not a viable solution. Very likely many current implementations rely on denormal results.
If we wanted to mitigate this in the JIT, the double-to-Value boxing step is a potential place to do it, maybe a CMP + CMOV on that path to zero the register if it's not a double. The performance overhead of that wouldn't be great though.
Currently, we also believe that conditional masking is a possible solution while Fission is not yet deployed.
Do you have any insight on which floating-point operations are vulnerable to this? For example, is
addsd
also affected?
We have verified that transient results are generated for all the add,sub,mul and div of x87, SSE or AVX instructions on FP numbers.
Assignee | ||
Comment 16•4 years ago
|
||
(In reply to Enrico Barberis from comment #15)
If we wanted to mitigate this in the JIT, the double-to-Value boxing step is a potential place to do it, maybe a CMP + CMOV on that path to zero the register if it's not a double. The performance overhead of that wouldn't be great though.
Currently, we also believe that conditional masking is a possible solution while Fission is not yet deployed.
Do you have any insight on which floating-point operations are vulnerable to this? For example, is
addsd
also affected?We have verified that transient results are generated for all the add,sub,mul and div of x87, SSE or AVX instructions on FP numbers.
Thanks, that's good to know.
Another option is to add a fence before string.length
(and maybe string[n]
). The reasoning being that the interesting Value types here are:
- String:
string.length
is the easiest vector as you found out. - Object: harder to abuse because this generally requires extra guards and loads, especially with Warp.
- Symbol: opaque to the JITs
- BigInt: we have some fast paths, but also comes with bounds checks, overhead to create a new BigInt etc.
So if strings are the easy vector, and they're already giving you difficulties, maybe it would be sufficient to fence those in functions that do double arithmetic, at least until Fission ships later this year.
I'm curious to hear your opinion on this.
Comment 17•4 years ago
|
||
Hi Jan,
re SCSB:
Great, indeed looks like you already have plenty of serialization on that path.
re FPVI:
For the general mitigation, you suggested using CMOV-based masking in the double-to-Value boxing step. I assume the double-to-Value boxing step happens when the floating-point value escapes and the JIT engine gives up on tracking its type at compile time? If so, this is exactly the mitigation we also discussed internally (e.g., lfence or better conditional masking at escape points). Since after the value escapes every use needs to go through non-trivial NaN-unboxing logic, we figured the extra CMP+CMOV wouldn't have a significant performance impact. Is that not the case?
For the exploit-driven mitigation, I don't think we have studied all the relevant code paths to be able to comment on general effectiveness. Hany and Enrico did look at string and Object, and both seem viable for exploitation, with different challenges. In particular, "string.length" makes it trivial to leak information through classic Flush+Reload, but requires a large(r) transient execution window for exploitation (to fit the corresponding checks). Despite the challenges, I think Enrico is already making good progress on a full exploit. Object dereferences (e.g., z[0]), on the other hand, seem to easily fit in a transient execution window, but yield a non-conventional covert channel using the secret data as the target address of a memory access. One can still leak the secret by using translation side channels (e.g., see our ASLR^Cache or AnC paper), but this only works for secrets that look like canonical addresses. So straightforward leaks are, in principle, limited to pointers stored in memory. And I don't know how high on your priority list an ASLR bypass is at this point. Nonetheless, note that, with some massaging and sliding, I would expect an attacker to be able to leak secrets beyond stored pointers, but high-entropy secrets like tokens, passwords, etc. are probably out of reach.
Assignee | ||
Comment 18•4 years ago
|
||
Thanks for your comments, they have been really helpful.
We will experiment with using CMP/CMOV for LBox
(or LBoxFloatingPoint
on x86) and see how that affects perf. It's hard to mitigate these issues completely, but that plugs the most obvious hole and combined with the embargo period and timer mitigations it will hopefully be sufficient until Fission arrives.
Comment 19•4 years ago
|
||
Happy to help! Please keep us posted.
Enrico and Hany will also report on progress with the exploit.
Comment 20•4 years ago
|
||
The regressions we saw with object-biased nan-boxing (bug 1559072) might be a rough order-of-magnitude estimate of the slowdown from CMP/CMOV when storing doubles. IIRC, the worst regression came in code like for (...) a[i] = b[i] * c[i]
, where additional overhead on loads and stores was a significant fraction of the entire loop body. Warp already bit the bullet and added GuardToDouble
s in that loop, though, so maybe a couple extra instructions won't be as noticeable.
Comment 21•4 years ago
|
||
Comment 22•4 years ago
|
||
Finally, we have an update regarding the exploit: we are able to leak arbitrary memory addresses exploiting transient type confusion. Compared to the previous PoC we have changed the type-confusion from object to string and enlarged the transient window using FPU pressure.
For the time being, the covert-channel is obtained by making clflush
and precise timers accessible from JS. Eventually, the exploit can be implemented "patchless" (See paper for more details).
All the details and the source code are present in the attached zip fpvi-scsb-mozilla-disclosure-02-23-2021.zip
.
We have also updated the paper together with the disclosure document to reflect these changes.
All the added/modified files are specified by the CHANGELOG.
To help the discussion, I will share here the core part of the exploit:
//the *two/two is a trick to enlarge the transient window due to higher FPU pressure
z = x/(y*two/two*two/two*two/two*two/two*two/two*two/two*two/two*two/two*two/two*two/two*two/two*two/two*two/two)
//At this point z has two possible values:
//architectural_z = JSDouble value -inf
//transient_z = JSString pointer to 0xdeadbeef000
if (typeof z == "string") {
return reload_buf8[(z.length&0xff)<<STRIDE_LOG]
} else {
return hot;
}
Updated•4 years ago
|
Assignee | ||
Comment 23•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 24•4 years ago
|
||
(In reply to Jan de Mooij [:jandem] from comment #18)
We will experiment with using CMP/CMOV for
LBox
(orLBoxFloatingPoint
on x86) and see how that affects perf. It's hard to mitigate these issues completely, but that plugs the most obvious hole and combined with the embargo period and timer mitigations it will hopefully be sufficient until Fission arrives.
I posted a patch for this. I didn't see a measurable slowdown on some JS shell benchmarks I tried so that's good news.
This is not a complete fix, but it's a stopgap for the most easily exploited case that's used by the paper/PoCs here.
Assignee | ||
Comment 25•4 years ago
|
||
Comment on attachment 9206591 [details]
Bug 1692972 - Add DoubleValue masking for LBox/LBoxFloatingPoint. r?iain!
Security Approval Request
- How easily could an exploit be constructed based on the patch?: Pretty difficult, but it might draw some attention to this variant. Not sure if it makes sense to hold off a bit on landing this or to just go ahead.
- Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
- Which older supported branches are affected by this flaw?: All
- If not all supported branches, which bug introduced the flaw?: N/A
- Do you have backports for the affected branches?: Yes
- If not, how different, hard to create, and risky will they be?: Should apply.
- How likely is this patch to cause regressions; how much testing does it need?: Unlikely.
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment 28•4 years ago
|
||
Comment on attachment 9206591 [details]
Bug 1692972 - Add DoubleValue masking for LBox/LBoxFloatingPoint. r?iain!
sec-approved to land, please request uplift.
Updated•4 years ago
|
Comment 29•4 years ago
|
||
We have verified that the proposed patch kills the signal in our test environment.
Indeed, we observed the JIT'ed code changing from
divsd %xmm1, %xmm0
movq %xmm0, %rbp
jmp 0x00000000000001D1
to
divsd %xmm1, %xmm0
movq %xmm0, %rbp
mov $0xFFF80000FFFFFFFF, %r11
cmp %rbp, %r11
cmovb %r11, %rbp
jmp 0x0000000000000190
where the cmov
is correctly stopping the transient value.
To the best of our knowledge, cmov
is the most desirable countermeasure due to its low overhead.
Kudos for the patch in such a short amount of time :)
Assignee | ||
Comment 30•4 years ago
|
||
https://hg.mozilla.org/integration/autoland/rev/df86e60f3b6281090d37e13250523baede97bf5a
(In reply to Enrico Barberis from comment #29)
We have verified that the proposed patch kills the signal in our test environment.
Thanks a lot for checking that!
![]() |
||
Comment 31•4 years ago
|
||
Add DoubleValue masking for LBox/LBoxFloatingPoint. r=iain
https://hg.mozilla.org/mozilla-central/rev/df86e60f3b62
Comment 32•4 years ago
|
||
Comment on attachment 9206591 [details]
Bug 1692972 - Add DoubleValue masking for LBox/LBoxFloatingPoint. r?iain!
approved for 87.0b9
Comment 33•4 years ago
|
||
uplift |
Comment 34•4 years ago
|
||
Comment on attachment 9206591 [details]
Bug 1692972 - Add DoubleValue masking for LBox/LBoxFloatingPoint. r?iain!
Approved for 78.9esr.
Comment 35•4 years ago
|
||
uplift |
Comment 36•4 years ago
|
||
Backed out from ESR78 for build bustage.
https://hg.mozilla.org/releases/mozilla-esr78/rev/92e6877143422e4f768fb202cd26f216e1500c1a
https://treeherder.mozilla.org/logviewer?job_id=332876342&repo=mozilla-esr78&lineNumber=2083
Assignee | ||
Comment 37•4 years ago
|
||
This backports cmpPtrMovePtr for x64 because ESR78 didn't have it. I verified this builds and passes jit-tests.
Comment 38•4 years ago
|
||
uplift |
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 39•4 years ago
|
||
As part of a security bug pattern analysis, we are requesting your help with a high level analysis of this bug. It is our hope to develop static analysis (or potentially runtime/dynamic analysis) in the future to identify classes of bugs.
Please visit this google form to reply.
Comment 40•4 years ago
|
||
Hi everyone, we have a couple of questions from our side:
- Is there a CVE assigned to this bug?
- We cannot find this vulnerability anywhere on this page https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox/ . Can you confirm from which version the mitigation is included?
We would like to report this information in our paper.
Thank you
Updated•4 years ago
|
Comment 41•4 years ago
|
||
We have not assigned a CVE or published an advisory to respect the disclosure date. We have intended to update our published advsiory for Firefox 87 and 78.9 when it is safe to do so. Please let us know when we can do that. I reserved CVE-2021-29955 for FPVI in Spidermonkey though.
Comment 42•4 years ago
|
||
Thank you for the update, the agreed public disclosure date is June 8th.
Have you already reserved a link for the security advisory?
We are asking for this information in advance due to our paper deadlines.
Reporter | ||
Comment 43•4 years ago
|
||
We will update our existing security advisories.
You can already find them for Firefox 87 at https://www.mozilla.org/en-US/security/advisories/mfsa2021-10/ and Firefox ESR 78.9 at https://www.mozilla.org/en-US/security/advisories/mfsa2021-11/ - we expect these URLs to be stable.
Comment 44•4 years ago
|
||
One last update from our side: the coordinated disclosure is on June 8 at 10 am PDT.
When public, you will find all information here:
project page: https://www.vusec.net/projects/fpvi-scsb
paper: http://download.vusec.net/papers/fpvi-scsb_sec21.pdf
repo: https://github.com/vusec/fpvi-scsb
Reporter | ||
Comment 45•4 years ago
|
||
Adding advisory. We'll attempt to publish this jointly (or shortly after) the disclosure at 9am PDT.
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Updated•8 months ago
|
Description
•