Meltdown & Spectre the last Opera 68.0.3618.104 vulnerability
-
A Former User last edited by A Former User
@andrew84 Please, try enabling the flag
opera://flags/#shared-array-bufferin the 58th Opera. It is interesting to look at the test result on your system. -
andrew84 last edited by andrew84
@johnd78 with the enabled flag I have the same random result in O58 too, depending oh how many 'caches' were processed.
-
A Former User last edited by
@andrew84 Ok, got it. Then try to disable the flag
opera://flags/#enable-webassembly-threadsin the 68th Opera. To pass the test, this should be enough. -
andrew84 last edited by andrew84
@johnd78 said in Meltdown & Spectre the last Opera 68.0.3618.104 vulnerability:
opera://flags/#enable-webassembly-threads
I disabled it, but in my case the result is still random (Portable 68.0.3618.104)
-
A Former User last edited by
@andrew84 For me with the
opera://flags/#enable-webassembly-threadsflag Disabled in the 68th it turns out like with theopera://flags/#shared-array-bufferflag Disabled in the 58th.
-
andrew84 last edited by andrew84
@johnd78 I can't comment here, I also tried it in 69 (which is not portable) and all is the same.
.Maybe the test itself is not stable. And my processors can't be called as 'modern' like it is said in the blog post's explanation.
-
donq last edited by donq
@andrew84 said in Meltdown & Spectre the last Opera 68.0.3618.104 vulnerability:
Maybe the test itself is not stable. And my processors can't be called as 'modern' like it is said in the blog post's explanation.
The vulnerability itself is not 'stable'
Code in test script is a bit over my understanding, but it could be unstable either.To read protected memory areas CPU cache is cleared, code is tricked to execute speculative read from protected area (which is discarded and thus not giving error - but data is already loaded into cache) and then some other memory addresses are read - read timing depends on cache containig specific data. Some information can be leaked even using somewhat random timing - I think this is exactly what you experience.
-
-
-
A Former User last edited by
@andrew84 Sorry, my mistake, I forgot something. Try to disable the flag
opera://flags/#enable-webassembly-threadsand start the browser with the key--disable-features=SharedArrayBuffer. Then it should work. Checked in the 68th and 69th Opera. -
anastasia-mx last edited by@johnd78 I used the "WebAssembly threads support" = "disabled" flag and started the program opera with the key --disable-features=SharedArrayBuffer as a result, the problem is resolved and the browser is no longer vulnerable.
can you explain what these parameters are and why they were enabled if this leads to a vulnerability?
-
donq last edited by donq
@anastasia-mx said in Meltdown & Spectre the last Opera 68.0.3618.104 vulnerability:
can you explain what these parameters are
Read here: https://developers.google.com/web/updates/2018/10/wasm-threads
and why they were enabled if this leads to a vulnerability?
Most likely unintended coincidence - performance versus security, as it often is.
If Chrome is not affected, then you should report a bug to Opera. If Chrome (Chromium) is affected too, then better report to Chrome (Chromium).Well, before reporting check latest developer build - it is possible that this problem is already fixed. In my just updated dev version (70.0.3693.0) two checks (2 of 2) did report "not vulnerable"
-
A Former User last edited by A Former User
@donq I think this Chinese test is old and may not take into account the current changes in the Chromium engine. Now it makes no sense to turn off flags and use keys only to pass this test. I also have not heard about the real use of this vulnerability in browsers, only in special tests.
