Basilisk and "Meltdown" + "Spectre" Topic is solved

[fipsy]

Are there currently any efforts to secure Basilisk against the new Meltdown and Spectre vulnerabilities? Mozilla and Google (Chrome) are currently working flat out to release a few fixes in real time. I'm afraid this won't be possible with Basilisk because it requires processes to run in their own threads. If that's the case, it's hard to advise against using Basilisk on the web because it would be a huge security risk.

[Moonchild]

No, none of this is a problem for basilisk because, tada, we don't use multiple processes. I will, however, release an update to Basilisk to make all accurate-timing-based attacks pretty much impossible; Pale Moon already had that mitigated, but was not prioritized to implement into Basilisk yet.

[fipsy]

@Moonchild: Thanks a lot for the fast answer!

I read that the JavaScript method performance.now() may only return the time exactly to 20 µs and SharedArrayBuffer must be deactivated.

Did I understand correctly that the vulnerability lies in the fact that single threads can read the data of other threads in the CPU? And that this is not possible with Basilisk / PaleMoon because all tabs run in one thread? Is this also the case if I open several instances of Basilisk in parallel?

[Moonchild]

Accurate timing based attacks were already mitigated to some extent by clamping the performance timers; this was enough for e.g. not being able to getting accurate measurements of the CPU speed any longer (used for fingerprinting, etc.) but not enough to mitigate all instances of these vulnerabilities on all hardware.
Mozilla now clamps to 20 µs (meaning it will not measure anything with greater accuracy than 20 µs granularity); Basilisk does not, yet and still uses 5 µs -- we'll be playing it safe and bumping that to 50 µs which will effectively thwart all these types of timing attacks because it's too course to reliably manipulate buffers to exploit this kind of thing. 50 µs is still plenty accurate for any timer in a browser you would ever need (and then some).

We won't have to deal with additional issues that could be caused by multi-process timing attacks or attacks against IPC, that Mozilla and Google will have to look at, which is what I hinted at in my first reply. It will have no bearing on having multiple copies of the browser running because they do not exchange data between them like a multi-process application would.

[fipsy]

Thank you very much for the quick response to the new threats and for the new release!

[nord1]

No, none of this is a problem for basilisk because, tada, we don't use multiple processes. I will, however, release an update to Basilisk to make all accurate-timing-based attacks pretty much impossible; Pale Moon already had that mitigated, but was not prioritized to implement into Basilisk yet.

Moonchild,

One of the reasons why I use Basilisk. Second choice behind SeaMonkey, aka Allizom, Mozilla Suite, Netscape. <g>

N

[fudoki]

In reply to Moonchild's comment about the 50uSec timing [and apologies to non-programmers] -

It appears to me, even w/o knowing the execution time of the "housekeeping" routine, that a switch from 20uS to 50uS is a good move and will provide an overall boost to Basilisk speed, no doubt part of your decision, from the reduced headroom needed for 200 spS (samples per Second) as opposed to 500 in Mozilla. Yeah, at today's processor speeds, this might seem trivial, but with overall CPU speeds in "average" computers, now mainly laptops, DROPPING (in the interest of more profits) headroom is beginning to re-surface as an issue. On my 13 y/o AMD Phenom 4-core 9950 "Black" at the standard 2.6GHz I am benchmarking about 30 times more actual processing power than my new, inexpensive, handy little HP 15-ba w/AMD A6-7310 4-core @ 1.0-2.33GHz! Now that's progress??? And yes, this huge difference between my "production" machine and my "toy" are primarily architectural and not just the approx 50% difference in clock speed. I DO have a point here.

Your challenge is to weigh the ability of an attacker to compose a scheme that will hit a MOVING target in most machines, as the clock speed is constantly going up and down based on load, load management algorithm, etc., etc. and then decide whether to use a predictive approach or an elevated priority approach. The former, sloppy but near undetectable, the latter, a huge red flag to invite scruitiny from security routines. But the former approach could be attempted several hundered times PER SECOND until success was acheived - then the hard part, programmatically, would begin...

My point is, the Spectre and Meltdown attacks are very difficult (I would say not worth doing, considering the yield of junk only on most computers) on modern machines. ONLY FIXED SPEED MACHINES ARE REAL, VIABLE TARGETS. Big servers, in today's usage, and "production boxes" of gamers and programmers, and older machines like most folks over 50 use at home. These folks should know how to stay safe, generally, by simply not going into the "slums" of the Net and only connecting to trusted partners. As bad as these attacks can be, the odds of exposure are incredibly small for regular users. If you have an old machine, like my Celeron 1.2MHz running Presice Puppy Linux (cut down Ubuntu 12.04LTS) you are basically hosed because the machine is not only a sitting duck, it's too slow to stop the attack - but what's likely to be on such a machine? Better make sure it's NOT backups of your financial records, passwords, personal info, etc. I use my Puppy box for Twitter, period. No data is on the box. I don't want FB or Twitter, etc. anywhere near my production box.

You beat these virii and worms by behaviour, not product design. The 20uS > 50uS adjustment was a very good call, IMHO. Optimise for speed. My Basilisk 2018.01.05 benchmarks "nekked", faster than anything but FF 57.x on the "Beast" 9950. GREAT job! Please get rid of the Mozilla control of Extension installation and use! Thanks so much and forgive my prolix post - hopefully it will be worth the read in your continuing product development.

[Moonchild]

a switch from 20uS to 50uS is a good move and will provide an overall boost to Basilisk speed

Actually, the granularity of these timers has nothing to do with execution speed of the browser. It's not a timer that fires constantly and it does not control an execution loop, but instead is a measuring tool that fires only when called.

[Moonraker]

Are there currently any efforts to secure Basilisk against the new Meltdown and Spectre vulnerabilities? Mozilla and Google (Chrome) are currently working flat out to release a few fixes in real time. I'm afraid this won't be possible with Basilisk because it requires processes to run in their own threads. If that's the case, it's hard to advise against using Basilisk on the web because it would be a huge security risk.

Thats a very peculiar thing to say actually as those vulnerabilities are in fact on the doorstep of intel themselves and have been present in your computer from the day of purchase to the divine revelation that firmware had suddenly out of the blue contained bugs and yet we as happy go lucky browser users have been totally unaware of the fact for probably years and yet never experienced issues so why worry about it right now.?
This is blatant scare mongering and everyone suddenly became petrified of turning on their computer.I personally have used an intel powered computer for years with no noticeable issues .what happened did my processor suddenly turn evil overnight lol...