1708986 - RFP: large_arraybuffers reveals OS bitness

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, enhancement, P5)

Description

[Thorin [:thorin]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Bug 1703505 flipped javascript.options.large_arraybuffers on. The pref will eventually be removed (one assumes)

trying var sab = new ArrayBuffer(Math.pow(2,32)) reveals if the OS is 64bit (if success)

Note: we can already detect the Firefox version via feature detection, but regardless, until the pref is deprecated, the test can only confirm 64bitness. Once the pref is gone, then it can confirm either 32 or 64bit

Tested by flipping the pref in FF88, Dev, Nightly

• 64bit builds on 64bit Windows

Not tested

• a 32bit build on 64bit windows
• a 32bit Windows

Is this something that RFP is interested in?

Comment 1

[Thorin [:thorin]]

OS architecture

• 32bit: 20.994
• 64bit: 79.006

Browser architecture

• 32bit: 20.744
• 64bit: 79.006
• other: 0.250 <- what makes up this %?

So pretty much binary with a 4 to 1 ratio. Not the world's worst entropy, but something that RFP does try to hide (e.g. userAgent)

[1] https://data.firefox.com/dashboard/hardware

Comment 2

[Matthew Finkel [:sysrqb]]

https://bugzilla.mozilla.org/show_bug.cgi?id=1703505#c5 says this is intentional. I am leaning toward yes, we want this covered by RFP (thanks for flagging this), unless there is a strong argument that we don't already hide the word size and this is yet another doomed effort. The easy hack looks like simply checking RFP at https://searchfox.org/mozilla-central/source/js/xpconnect/src/XPCJSContext.cpp#902

On the other hand, I could see a similar behavior on a 64-bit installation as the canvas prompt, except we default to the 32-bit max unless the user accepts the risk - but that canvas UX requires more work, so I don't suggest we replicate that right now.

Comment 3

[Lars T Hansen [:lth]]

Even if the max buffer size is pinned to 2GB on 64-bit systems, it should already be easily detectable that it is possible to allocate many of them on 64-bit systems but only very few of them on 32-bit systems. Unless we've really blown the implementation, subsequent allocation attempts on 32-bit should OOM reliably without taking down the process.

var xs = []
for ( var i=0; i < 10; i++ ) {
    print("Again #" + i);
    try {
        xs.push(new ArrayBuffer(1024*1024*1024));
        print("Succeeded #" + i);
    } catch (e) {
        print("Failed #" + i);
        print(e);
        break;
    }
}
print("Done");

(An obscure related point: If it's possible to detect the OS (specifically Android), either directly or through sniffing eg screen geometry, then starting with FF90 it will be possible to tell 32-bit Android apart from 64-bit ditto because 64-bit will have Wasm SIMD support and 32-bit will not.)

Comment 4

[Thorin [:thorin]]

(In reply to Lars T Hansen [:lth] from comment #3)

If it's possible to detect the OS (specifically Android)

just some notes

• RFP doesn't try to hide the OS: ultimately it's impossible: e.g. you can check a widget's font-family. Android will always be Roboto, windows MS Shell Dlg , mac -apple-system and anything else (with more entropy) is Linux
  • side note: IDK if this would actually be a good restriction to add to RFP: return undefined for property values from "system" widgets
• math floating point entropy can also detect browser architecture and thus 64bit builds indicate 64bit OS
  • windows has two distinct results each for win-sdk and mingw
  • android has at least seven distinct results
• FYI: Tor Browser disables wasm in web context

The question is do we make this harder to detect [1] or just give up. I'm inclined with the former. It's a game of incremental steps, not a net sum one

[1] architecture: we already do so with http headers, navigator.platform/userAgent/oscpu, timing mitigations. Math entropy should be solvable too: e.g. with libraries see [2] and so far tests indicate chrome has no math entropy
[2] https://gitlab.torproject.org/legacy/trac/-/issues/13017#note_2171288 - testing a change in library removed the audio entropy

Comment 5

[Lars T Hansen [:lth]]

Noted.

Ignoring Tor issues, some of the wasm instructions coming in with the Relaxed SIMD proposal (https://github.com/WebAssembly/relaxed-simd/) may in principle make it possible to distinguish eg Intel from ARM64 (due to observable differences in NaN behavior or differences in precision for eg fused multiply-add) or to distinguish different CPU implementations within the Intel family because reciprocal approximation instructions in the instruction set supposedly use lookup tables that differ among implementations; the architecture only gives an error bound. (These latter instructions are only available with AVX512 and it'll be some years before they are relevant.)

Comment 6

[Tom Ritter [:tjr]]

IMO the side channels that are likely possible between 32 and 64 bit are likely to be numerous and difficult or impossible to prevent so I would not spin on this personally.

Comment 7

[Thorin [:thorin]]

The pref was removed in FF110 in Bug 1703508, and if Tor Browser wants to do anything they are tracking it at https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41675

+1 for closing as WONTFIX

Comment 8

[Jan de Mooij [:jandem]]

Closing makes sense because this would be very hard or impossible to fix.

As pointed out in comment 5, on 64-bit platforms you can allocate many smaller array buffers or typed arrays but on 32-bit platforms this will fail due to OOM. We can't really limit the total size of these allocations on 64-bit without breaking websites. So this was already an issue with smaller array buffers, it just became a little easier with large ones.