1692972 - (CVE-2021-29955) FPVI & SCSB Disclosure (Feb 12, ‘21)

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, task)

Description

[Frederik Braun [:freddy]]

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 [e-mail]:

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 [e-mail] 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.: [e-mail] is simply an alias for [e-mail], [e-mail],
[e-mail], [e-mail], 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

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: fpvi-scsb-mozilla-disclosure-02-12-2021.zip

Attached is the decrypted zip

Comment 2

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: FPVI & SCSB Disclosure.pdf

For convenience here is pdf 1 from the zip

Comment 3

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: machine_clear.pdf

For convenience here is pdf 2 from the zip

Comment 4

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

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.

Comment 5

[Cristiano Giuffrida]

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

Comment 6

[Jan de Mooij [:jandem]]

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

[Cristiano Giuffrida]

@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.

Comment 8

[Jan de Mooij [:jandem]]

(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.

Comment 9

[Jan de Mooij [:jandem]]

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

[Enrico Barberis]

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.

Comment 11

[Jan de Mooij [:jandem]]

(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

[Enrico Barberis]

(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 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.

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:

1. the divsd operands are under attacker controls
2. shortly after the divsd, a tag check is made. This is necessary to perform type-confusion. In the provided PoC, the engine considers 0xfffe0deadbeef000 as JSObject.
3. 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

[Enrico Barberis]

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).

Comment 14

[Jan de Mooij [:jandem]]

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

[Enrico Barberis]

(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.

Comment 16

[Jan de Mooij [:jandem]]

(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

[Cristiano Giuffrida]

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.

Comment 18

[Jan de Mooij [:jandem]]

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

[Cristiano Giuffrida]

Happy to help! Please keep us posted.

Enrico and Hany will also report on progress with the exploit.

Comment 20

[Iain Ireland [:iain]]

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 GuardToDoubles in that loop, though, so maybe a couple extra instructions won't be as noticeable.

Comment 21

[Enrico Barberis]

Attachment: fpvi-scsb-mozilla-disclosure-02-23-2021.zip

Comment 22

[Enrico Barberis]

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;
    }

Comment 23

[Jan de Mooij [:jandem]]

Attachment: Bug 1692972 - Add DoubleValue masking for LBox/LBoxFloatingPoint. r?iain!

Comment 24

[Jan de Mooij [:jandem]]

(In reply to Jan de Mooij [:jandem] from comment #18)

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.

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.

Comment 25

[Jan de Mooij [:jandem]]

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 26

[Enrico Barberis]

Is it possible to have a look at the current patch?
If I try to open Bug 1692972 I get the error "Access Denied: Restricted Differential Revision".

Comment 27

[Enrico Barberis]

My bad! I can now see the attached patch. Sorry for the spam

Comment 28

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Comment on attachment 9206591 [details]
Bug 1692972 - Add DoubleValue masking for LBox/LBoxFloatingPoint. r?iain!

sec-approved to land, please request uplift.

Comment 29

[Enrico Barberis]

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 :)

Comment 30

[Jan de Mooij [:jandem]]

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

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Add DoubleValue masking for LBox/LBoxFloatingPoint. r=iain
https://hg.mozilla.org/mozilla-central/rev/df86e60f3b62

Comment 32

[Julien Cristau [:jcristau]]

Comment on attachment 9206591 [details]
Bug 1692972 - Add DoubleValue masking for LBox/LBoxFloatingPoint. r?iain!

approved for 87.0b9

Comment 33

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/b129bba64358

Comment 34

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9206591 [details]
Bug 1692972 - Add DoubleValue masking for LBox/LBoxFloatingPoint. r?iain!

Approved for 78.9esr.

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/e11e53daf76d

Comment 36

[Ryan VanderMeulen [:RyanVM]]

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

Comment 37

[Jan de Mooij [:jandem]]

Attachment: Patch for ESR78

This backports cmpPtrMovePtr for x64 because ESR78 didn't have it. I verified this builds and passes jit-tests.

Comment 38

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/906e64cb23014c7108b8ad75c9289405e89c0406

Comment 39

[BugBot [:suhaib / :marco/ :calixte]]

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

[Enrico Barberis]

Hi everyone, we have a couple of questions from our side:

1. Is there a CVE assigned to this bug?
2. 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

Comment 41

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

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

[Enrico Barberis]

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.

Comment 43

[Frederik Braun [:freddy]]

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

[Enrico Barberis]

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

Comment 45

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Adding advisory. We'll attempt to publish this jointly (or shortly after) the disclosure at 9am PDT.