back to article Second wave of Spectre-like CPU security flaws won't be fixed for a while

The new bunch of Spectre-like flaws revealed last week won't be patched for at least 12 days. German outlet Heise, which broke news of the eight Spectre-like vulnerabilities last week has now reported that Intel wants disclosure of the flaws delayed until at least May 21. “Intel is now planning a coordinated release on May 21 …

Anonymous Coward

Untrusted Code?

Just how long is it going to be before we finally decide running untrusted code (Javascript) downloaded from random Web pages is a really bad idea?

All of these problems with Spectre and Meltdown go away if you're confident that the code you're running is not out to attack your system. With the Web as it is today, we have no clue as to what the Javascript we run is intending to do. We just blindly run it no questions asked. Always did seem like a bad idea.

9
4

Re: Untrusted Code?

And your solution is? We're not running the javascript for shits'n'giggles, it's because it does something we need to do, how do then "trust" the code you need to do the thing you're after and "untrust" that which you don't (beyond current browser whitelisting of sites) which is trivial to setup when you disable javascript by default.

9
6
Silver badge

Re: Untrusted Code?

All of these problems with Spectre and Meltdown go away if you're confident that the code you're running is not out to attack your system.

And how do you do that reliably? For example, code signing just proves that someone wrote the code, not that the code is safe. Nor can you use static analysis to prove code is safe.

15
0
Coat

FLASH! Ahh-ahhhh!

Any fule kno that JS is just BS - time to return to the time-tested technology of Adobe Flash!

(my coat? it's the one with today's patch for adobe-flashplugin in the pocket)

12
1
Silver badge

Re: Untrusted Code?

@Sampler I would expect around 90% of the JavaScript code we run is not necessary to carry out the task at hand. It might make the task easier to accomplish or add some visual shits'n'giggles to the process, but it is not necessary.

I use NoScript and on a majority of the sites I visit, the site either works without scripts (i.e. I can read the text on the page) or works "well enough" after I turn on just the main site. Things like analytics, ad-duplex, double click and dozens of other tracking, and advertising scripts are NOT needed to use a page.

The other big problem is, many of the site devs have no idea what is running on their page! They just add a link to the "library de jour" and hope it is safe...

For example, I re-routed all Facebook domains to 0.0.0.0, it didn't break anything worthwhile on the sites I visit, even though they couldn't execute code or load images from those domains.

16
1
Silver badge

Re: Untrusted Code?

Absolutely.

I propose that we create a language which is subject to a strict security model and runs inside a user-space application. Such a language wouldn't facilitate any kind of arbitrary code execution, but instead be formed from a limited subset of a common language, and not allow interaction with, say, the filesystem, or direct networking, or hardware, etc.

We could base the language syntax on some popular language, to make it easy to learn, and have browsers implement their own scripting engine isolated from the OS to execute it, subject to the browser DOM model. We could even have it compile down to a nice virtual-machine like architecture in later years and some primitive form of assembly that gets interpreted by the browser while still subject to the same model, for performance reasons.

Oh, look, you just invented Javascript and WebAssembly.

Basically, if you want the computer to be useful, it has to perform actions. You CAN have a remote server perform actions on your behalf, but then you really have little need for a computer at all. That's what we used to call a thin client, and they often have bad reputations for a number of reasons. Unless you want an entirely thin client based on web services performing all calculations, you have to act on some kind of code in a limited fashion. That means isolating yourself as best as possible (see above).

3
6
Silver badge
Devil

Re: Untrusted Code?

it's because it does something we need to do

Is it really necessary to bling up your site to convey information or is it just ego and skewed priorities of form over function that has created the need for executable code being flung hither and yon and minimally acceptable bandwidth being 10mbps?

10
0
Bronze badge

Re: Untrusted Code?

JavaScript has a far from strict security model, and its a BS language anyway. Its Java ripped down to within an inch of its life and a mess of commands. the other problem is sanboxing this code inside the browser, when the OS is basically a patchball, even though it has been clean sheeted atleast twice!

If you dont need to game or run data analytics etc, a thin client is all you need, which is why for most people I have been recommending the Chromebook for a while.

Oh and Thin Clients are everywhere and a great thing for desktop security: you get a new machine every morning, thats patched and up to date, and if your VD server is man enough, you dont notice the limitations.

5
1
Silver badge
Thumb Down

@Sampler

Well, truth be said, you are running JavaScript for shits and giggles.

Because if you were in any way serious about your code, you'd not trust some effing download site and you'd vet your code and have it stored locally to be sure about what what it actually does.

Trusting a 3rd party with essential code is exactly like asking the same drug dealer to deliver a perfect product every time for nothing.

Kids these days . . .

6
0
Bronze badge

Re: FLASH! Ahh-ahhhh!

That stain appears to be from a leaking plugincontainer.exe

0
0
Silver badge
Devil

If brutally murdering Javascript will do no other good beyond getting rid of those "fifteen seconds after the page loads auto-darken the whole page and throw up a roadblock aggressively demanding something", it will still have been worth it.

25
0
Anonymous Coward

What I wish is that they'd publish all the fixes they've allegedly created - I got an N2815 netbook, Intel said there's a microcode update for it, but it's not on their website :/

2
0
Silver badge
Go

In the same breath...

...they'll turn around and whinge that desktop sales are declining. At this point, it's very hard to think of a compelling reason to upgrade anything, given that Intel's entire CPU portfolio is full of holes. Look no further for the reason the desktop seems to be "dying." It wouldn't surprise me if the MBA types decided to incorporate a death timer into some of these designs in a vain attempt to stir up a bit of long-term revenue - it wouldn't be the first time foot-shooting has happened in the tech sector.

"We can blame it on RoHS. Tin whiskers!" Sure, in an encapsulated package. That'll fly.

Meltdown, Spectre, IME, PSP, is there any wonder people are keeping adequate, anti-feature immune kit running for as long as they possibly can?

4
0
Silver badge

Basically, client side code execution is always a risk, because it provides a mechanism to run code from a server that you have no control of, on your system.

The problem is that without it, a lot of our interactions on the web would look like they did back in HTML2 and earlier, where all that could be done had to be done as tables, and any complicated tasks had to be rendered into a pixmap on the server side, and sent to the browser to display.

My view is that Javascript provides too much control. AFAICT, as originally specified, it was supposed to be interpreted. This should have made it quite difficult to issue a stream of machine code instructions which has not been generated by the interpreter or JIT compiler. And if you can make it generate specific vulnerable code, fixing the interpreter or JIT compiler to prevent this is much easier than fixing the processor (it is interesting that the IP protocol compiler in the Linux kernel could be manipulated to generate code to demonstrate meltdown!)

Of course, injecting executable machine code directly into a machine via buffer-overruns or in images or other binary blobs through poorly written client side processes would still be a vector for executing malicious code, and if you have direct control to import and execute code through a direct user session on a system, then there is nothing much you can do to protect yourself from processor flaws. Running a non-x86 architecture would provide some mitigation, but only from vulnerabilities that affected x86 processors.

It is at this point that having trusted executables, preventing you from running imported code, could be a help, but that would not work with anything that used self-modifying, or JIT compiled code or on a system that is used for development (if you can compile code on a system, it is extremely difficult to negate processor flaws).

4
0

Presumably the intel engineers are hard at work on logos first.

5
0
Gold badge

Delayed disclosure.

Or, in other words :

"As a best practice, we continue to encourage everyone to keep their systems up-to-date, as long as we get to define what 'up-to-date' means."

2
0
Anonymous Coward

I still haven't patched the first lot...

1
0
Bronze badge

When...

When will it be safe to buy another CPU? {insert-rant-here}

4
0
Silver badge

Re: When...

When will it be safe to buy another CPU? {insert-rant-here}

I could do you a good deal on some old 486 chips I've got lying around..

(No warranty implied or offered!)

1
0

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2018