Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security

Changes in WebAssembly Could Render Meltdown and Spectre Browser Patches Useless (bleepingcomputer.com) 181

Catalin Cimpanu, reporting for BleepingComputer: Upcoming additions to the WebAssembly standard may render useless some of the mitigations put up at the browser level against Meltdown and Spectre attacks, according to John Bergbom, a security researcher at Forcepoint. WebAssembly (WA or Wasm) is a new technology that shipped last year and is currently supported within all major browsers, such as Chrome, Edge, Firefox, and Safari.

The technology is a compact binary language that a browser will convert into machine code and run it directly on the CPU. Browser makers created WebAssembly to improve the speed of delivery and performance of JavaScript code, but as a side effect, they also created a way for developers to port code from other high-level languages (such as C, C++, and others) into Wasm, and then run it inside a browser. All in all, the WebAssembly standard is viewed as a success in the web dev community, and there've been praises for it all around.

This discussion has been archived. No new comments can be posted.

Changes in WebAssembly Could Render Meltdown and Spectre Browser Patches Useless

Comments Filter:
  • by Anonymous Coward

    Discuss.

    • by gweihir ( 88907 )

      Not here, not before it runs fvwm on X on Linux.

    • The idea of the Browser as the Desktop is a good one. While there's the obvious inefficiency of an added layer, it seems to be better than other ways of remote application serving. In theory.

      The problem is that for peak efficeincy all of the past solutions have pierced the veil of the browser and drilled down close to the OS metal.

      ActiveX, Flash, Java all are pretty much dead because they have proven that security can't be achieved ever. It's just a momentary state before someone discovers the next secur

    • Well, now you execute random code from random third parties and will start wondering why you're getting so much malware all of a sudden. Why is noscript become popular, not because javascript is too slow, but because that's where so many malware, spying, tracking, and advertising attacks are coming from.

  • by Anonymous Coward on Sunday June 24, 2018 @08:51PM (#56839832)

    The fact so many webdevs see active x, but harder to control as a success just proves the entire node.js loving lot of them have no fucking clue what they are doing and shouldn't be allowed near a computer.

    "Lets download and run executable automatically from the net! What could go wrong?"

    Idiots.

    • Re: (Score:3, Insightful)

      by vtcodger ( 957785 )

      Quit shilly shallying and let us know what you really think.

      However, I completely agree with you. If we're going to let anybody on the planet download code to our computers then execute it, what's the point in worrying about Spectre and Meltdown? or passwords, or any other security measures for that matter?

      It's been clear to me for decades -- ever since HTML email -- that the internet decision makers are more or less completely bonkers.

      I do not expect the situation to end well.

      • by Anonymous Coward

        Now that net neutrality has ended only trusted websites will be allowed!

      • by Kaenneth ( 82978 )

        The key problem with ActiveX on old Windows, is that once it was breached, there was no more security. These days, the user account doesn't have administrative access by default on Windows for a long time.

        Anyway Meltdown/Specter are more problems on the server side, noone should ever run a web browser on a real server (download patches to removable media, then install them)

        • All of an user's valuable and sensitive information are accessible by its user account. Putting files into system32 is no longer the goal of hackers. And it is also less important now that the browsers have such a huge attack surface and are used as frequently as they are today; who needs persistence for malware when they can freely download machine code into a computer every time its owner opens a web page.
        • It was also a stupid idea from the start. It was Windows only and invented primarily to try and enforce more customer lockdown. Like so many Microsoft ideas, the priority was to push features out first and worry about security issues never.

      • by LubosD ( 909058 ) on Monday June 25, 2018 @03:10AM (#56840696)

        You have no clue what wasm can and cannot do, right?

        All wasm can do is to have a linear memory buffer for its memory allocations (kindly provided by JavaScript) and make some calls between wasm and JS. Wasm has absolutely no access to your system and any interaction with the outer world needs to be done via JS.

        So quit whining.

      • Re: (Score:3, Informative)

        by AmiMoJo ( 196126 )

        WebAssembly makes sense when you think of the browser as the new OS. An OS that provides heavy sandboxing and a permission system.

        Compiling to machine code may be a bit scary, but it's what all major browsers have been doing for a while now. JIT for Javascript was new a decade ago.

        Running unverified code sounds crazy until you realize that that's what most people do most of the time. Even in the open source world few people bother to check the source or binaries they are getting from repos, and bad stuff ha

        • by Anonymous Coward

          WebAssembly makes sense when you think of the browser as the new OS. An OS that provides heavy sandboxing and a permission system.

          Compiling to machine code may be a bit scary, but it's what all major browsers have been doing for a while now. JIT for Javascript was new a decade ago.

          So because everyone's doing it, it's fine and we should be quiet huh? We shouldn't question whether or not this is an ideal method of doing what we need to, or if there are safer ways?

          Running unverified code sounds crazy until you

        • No, I don't normally run unverified code from third parties that I have never heard of. I used to have to manually download and install programs. Now programs run by themselves from sites I don't know about, just because some loser website uses third party advertisement and analytic sites to try and monetize a blog.

      • by mlyle ( 148697 )

        It's reasonable to expect that naughty code can be contained-- we have process containment and virtual machines and OS privileges for the purpose. But side channels, like Spectre etc, make that more difficult.

      • They just have different goals than the users is all. Internet decision makers want money from advertisers so they will do everything in their power to shove more of it at us, and more and more targeted ads. The users just want to see kitten videos and what their friends are up to.

    • by AHuxley ( 892839 )
      Going to have to buy a Gigabyte BRIX just to do the internet on? Keep the internet away from the computers?
    • by phantomfive ( 622387 ) on Monday June 25, 2018 @05:09AM (#56840986) Journal

      "Lets download and run executable automatically from the net! What could go wrong?"

      This is not any different than Javascript.

      • Why is why I use noscript.

        (except for work, where the new parent company is so in bed with Microsoft and the Cloud that you literally can't change your password if you have noscript, even if you've whitelisted all the scripts, so I have a second browser profile just for official work related activities)

    • by HiThere ( 15173 )

      Unfortunately, several modern computer languages do just that. Rust even does that and claims to be secure. (True, it's the tool chain, not the base language. I'm not sure that makes things better.)

    • "Lets download and run executable automatically from the net! What could go wrong?"

      What do you prefer?

      A walled garden app store?
      A system requiring signed executables approved by he who can't break into the phone business?
      A complete lockdown with only the software your computer came with able to run?

      What could go wrong? We could own our computers and have the freedom and power to make them do what WE tell them to. How horrible.

  • by jittles ( 1613415 ) on Sunday June 24, 2018 @08:51PM (#56839834)
    Why would anyone want this? If a website isn't going to trust javascript content enough to host it on it's own site, I don't even want to let it execute. I definitely don't need faster javascript. I need less of it. Probably 90% of the javascript websites try to push on me are from 3rd party ad firms. I'd like to see some legislation that makes a website responsible for any 3rd party ad, script, or anything else it loads during normal execution. That would likely result in fewer ad networks pushing viruses around the internet since there would actually be someone to hold responsible for it.
    • Re: (Score:3, Insightful)

      by Anonymous Coward

      That would likely result in fewer of everything, everywhere. On the other hand, maybe making it 1994 on the Internet again wouldn't be such a bad thing with all the shit that's out there now.

      • Y'know what -- Compuserve and Fidonet via a 1200 baud modem in 1994 was in many ways a better user experience than the modern internet. There are some useful things on the Internet -- Wikipedia, Stack Overflow, etc. And it's sort of still possible to get news content despite the best efforts of advertisers to make that as unpleasant an experience as possible. But overall, I think the Internet perhaps even more than US commercial TV has become part of FCC commissioner Newton Minnow's Vast Wasteland.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      when sites pollute their code with dozens of ad and tracking scripts, it slows the site down, potentially losing impatient eyeballs.

      which is precisely why google (who is an advertiser and data harvester first and foremost), et. al. pushed this abomination on us... so the bullshit scripts no end user wants doesn't kill browser performance... and maybe won't be noticed by the 95%+ of users without the knowledge or understanding to know what's really going on.

    • by phantomfive ( 622387 ) on Sunday June 24, 2018 @09:43PM (#56839992) Journal
      WebAssembly is a much safer interface than Javascript. The summary makes it sound like it's some kind of x86 code, but it's not. The fact that it is well thought out, and carefully designed to have a small attack surface means there is a smaller chance of finding exploits there.

      So ideally, eventually all Javascript will be compiled to WebAssembly in the browser, and there will be no Javascript running on your machine at all.
      • The fact that it is well thought out, and carefully designed to have a small attack surface means there is a smaller chance of finding exploits there.

        I'm sure the systemd developers had those thoughts too when they started out. :-)

      • Clearly safe, as the article posits.
      • So we go from shit I can reformat and read, to shit I can't read? That's a hard no.

        It's not about the attack surface. It's about knowing what runs.

        I'll allow jQuery with a known hash, for example. But that means fewer websites work for me. I have money to spend, but I don't even click on certain websites that give me a blank page.

        I'm guessing there are a lots of nerds who remember ActiveX and aren't willing to make that mistake. And also have excess cash inflow. But the decision makers don't remember a time

        • It's not about the attack surface. It's about knowing what runs.

          ...snipsnip...

          I respectfully disagree. Attack surface is the result of a set of fundamental design decisions based on knowledge, or lack thereof, of the operating environment (OS and browser), toolset (compiler), and communication protocols. "Knowing what runs" seems to be more of a personal requirement to inspect the webpage source code. Even if you could reverse compile WASM code (which will obviously happen if it hasn't already) and inspect it, that doesn't help if the underlying pcode interpreter has security vuln

          • Knowing what runs means that if I go to xyz.com then ONLY scripts and code from xyz.com should be allowed to run. In reality when I thought I was looking at someone's blog I actually end up being tracked for advertising purpose by third party sites I've never heard of. Javascript is a popular for malware precisely because customers don't know where all these scripts are coming from, and the original web site owner probably doesn't know either.

            What this means is that because I use noscript, I can only view

            • ... because I use noscript, I can only view about 10% of the web, and that's shrinking every day. But there is no viable alternative to this.

              Clay tablets, pointed sticks and swallows (using Unladen swallow Delivery Protocol)

              • I have a clay tablet. It says "Enoch's slightly used sheep, get two for the price of one!"

                • I have a clay tablet. It says "Enoch's slightly used sheep, get two for the price of one!"

                  Go with the sheep. The chickens died. And before I could get my merit badge dammit.

      • Well thought out does not matter, well implemented without flaw DOES matter, and unless webassembly has some kind of mathematical proof , I don't want it enabled on my PC. All I want is : can Is witch it off... ?

      • by tlhIngan ( 30335 ) <slashdot.worf@net> on Monday June 25, 2018 @04:33AM (#56840894)

        WebAssembly is a much safer interface than Javascript. The summary makes it sound like it's some kind of x86 code, but it's not. The fact that it is well thought out, and carefully designed to have a small attack surface means there is a smaller chance of finding exploits there.

        WebAssembly is an evolution of asm.js from Mozilla.It's actually JavaScript, but a small subset of it.

        Asm.js came about as some Javascript engine writers for Mozilla were playing around (and ended up with a C to Javascript compiler) and discovered there were operations that the engine ran really fast. So asm.js was created to provide a turing-complete subset of Javascript that ran really fast in Mozilla.

        I think the challenge was to run a game engine like Unity or Unreal in the browser without a plugin, which was why the C to Javascript compiler was created.

        It became WebAssembly when Mozilla and other browser manufacturers got together to standardize the interface. It's not another language, but a controlled restricted subset of Javascript that ends up executing extremely quickly because they were simple and by restricting what Javascript you could use, the optimizers could make optimizations they could not in regular Javascript. End result is the Javascript JIT in the browser made fast and efficient code.

        This also lead to the standardization of the C to WebAssembly compiler, which is why you now have even large projects like DOSBox compiled into WebAssembly, so you have the ability to run retro programs right in the browser (see the Internet Archive)..

        It's likely what happened is the optimizations to WebAssembly bypass the mitigations - the restricted Javascript subset exists to be really fast and what happened is browser manufacturers may have forgot about the fast path.

        • Webassembly is binary bytecode. It's something different.

          What you describe is indeed asm.js, but that's not Webassembly.
          • by flink ( 18449 )

            Webassembly is binary bytecode. It's something different.

            What you describe is indeed asm.js, but that's not Webassembly.

            But doesn't Javascript just get JIT'd down to binary bytecode these days anyway? And if that's the case, why not deliver the bytecode directly instead of having to perform the JIT step locally? As long as they are running in the same sandbox and the inputs get validated, there shouldn't be any difference between bytecode that your browser produces locally from source code and bytecode you load directly from an external source.

            • The difference between Javascript and Webassembly, is that the some of the features of the Javascript language make it slow, even if it's JIT'd down to bytecode.
          • Different, but also very much the same.
            It was designed to run on an engine that had asm.js optimizations in place, and was itself merely a binary (and descriptive assembly) format for applications that were designed to run on an asm.js optimized VM.
            The initial versions of WebAssembly were in fact demoed using asm.js shims, and currently, WebAssembly appliations can be converted to asm.js on the fly for browsers that don't support the binary format. WebAssembly introduces even more restrictions to the oper
    • Mod him up. Websites should be responsible for sending me where I didn't ask to go. I would call them 3rd Party Ad Farms.

    • by bobby ( 109046 )

      You're sounding like my very first posts here on /. 20 years ago. Yep, I'm gonna say it: "nobody every listens to me".

      I understand art and tricky artistic and "interactive" "content". In other words, I see some value in javascript. I could argue that most of the functionality should be in html / css, but sometimes a programming language like javascript is the best and maybe only way to get some things done.

      My main gripe is with browsers and what they're allowing javascript and WebAssembly to do in and to

      • You're sounding like my very first posts here on /. 20 years ago. Yep, I'm gonna say it: "nobody every listens to me".

        I understand art and tricky artistic and "interactive" "content". In other words, I see some value in javascript. I could argue that most of the functionality should be in html / css, but sometimes a programming language like javascript is the best and maybe only way to get some things done.

        My main gripe is with browsers and what they're allowing javascript and WebAssembly to do in and to our computers.

        And of course OSes which allow evil to happen.

        And now we can't trust hardware.

        Web browsers need to be run in small, disposable containers.

        Preferably on dedicated computers that can be re-imaged frequently.

        I'm not advocating that we nuke javascript from orbit. But right now it's like the wild wild west. Push some new framework from some 3rd party website that you have no control over because it "does cool things". Who cares, right? It's not your machine that is running the code. It is running on someone else's machine. At least, that is the attitude that these developers seem to have. I pretty much block all javascript content and the internet does more or less what I need it to do.

    • That’s not unreasonable. Legislators (especially here in Europe) are increasingly leaning on online platforms to apply filtering of 3rd party content. Mostly to address copyright violations, but also against undesirable opinions (“hate speech”). And those platforms will be held responsible for anything that gets through.

      I am opposed to such a priori censorship, but if we’re going to apply it, I don’t see why it shouldn’t extend to ads and code. In fact since the case
    • > That would likely result in fewer ad networks pushing viruses around the internet since there would actually be someone to hold responsible for it.

      It would also be mostly a moot point unless the site is owned by a major corporation, since an average blogger -- even one who earns enough from it to live on -- is effectively judgment-proof by virtue of not having enough assets to sustain more than one or two losses (and that's if they lose by virtue of not hiring a lawyer to fight... if they DO get a lawy

      • It would also be mostly a moot point unless the site is owned by a major corporation, since an average blogger -- even one who earns enough from it to live on -- is effectively judgment-proof by virtue of not having enough assets to sustain more than one or two losses (and that's if they lose by virtue of not hiring a lawyer to fight... if they DO get a lawyer, they won't have anything left to sue for anyway by the time their legal fees are paid).

        I'm perfectly okay with that as long as some small timer isn't hosting content on behalf of a major corporation. I don't typically visit Joe The Plumber's blog, but when I do, he likely does not have the main page content hidden unless I enable javascript. Yet a large number news organizations and many other large companies do exactly that. I'm happy to run their script content, I trust them enough for that. But I do not trust every single 3rd party script repo or CDN they choose to use on their website.

    • I wouldn't mind ads on the web if they were actually curated by the web site owners. Instead these web site owners have handed over their responsibilities to third party sites.

  • All in all, the WebAssembly standard is viewed as a success in the web dev community, and there've been praises for it all around.

    And how about in the Web *user* community where the soon-to-be-compromised browsers will be running? As someone else said here, I want less Javascript not more - and certainly none with direct access to my hardware. So... anyway to disable WebAssembly in FF? (Asking for a friend)

    • "And how about in the Web *user* community where the soon-to-be-compromised browsers will be running?"

      Users? Who cares about users? (As long as they don't use ad-blockers)

      • "And how about in the Web *user* community where the soon-to-be-compromised browsers will be running?"

        Users? Who cares about users? (As long as they don't use ad-blockers)

        Heard a great quote; can't remember where. It's probably a mimi or fifi or meme or whatever by now:

        If you're not paying for the product, you are the product.

        And as it turns out, even if you're paying for the product, you are product.

    • Re:Hmm ... (Score:5, Informative)

      by fahrbot-bot ( 874524 ) on Sunday June 24, 2018 @09:31PM (#56839966)

      So... anyway to disable WebAssembly in FF? (Asking for a friend)

      Answering my own question -- with, perhaps, some overkill ... (feel free to correct me)

      // Disable WebAssembly
      user_pref("devtools.debugger.features.wasm", false);
      user_pref("javascript.options.wasm", false);
      user_pref("javascript.options.wasm_baselinejit", false);
      user_pref("javascript.options.wasm_ionjit", false);

    • My understanding is that NoScript blocks it
    • by Anonymous Coward

      https://github.com/stevespringett/disable-webassembly

  • Since this detail was missing from the summary; Browsers have limited access to precise timers as a meltdown / spectre mitigation. Web assembly threads might give attackers a way to precisely measure time intervals by executing tight loops in another thread.
    • by gweihir ( 88907 )

      If your security is dependent on preventing precise time measurements, it is broken anyways. You can always measure time precisely in some fashion, may just take a little longer. But thanks for the info. I suspected as much, but now I can do without reading the article.

      • If your security is dependent on preventing precise time measurements, it is broken anyways.

        I want to flip that on it's head: If your exploit is dependent on precise time measurements on a system you haven't characterized, running processes and memory which is not in your control looking for something that may or may not be there, your exploit is broken.

        I will wager short of an actual state targeted attack by an inside person, or a hacker breaking out of his virtual machine on someone else's iron which is he currently using, Spectre and Meltdown won't have any practical implications outside of a l

  • Not a big problem (Score:5, Informative)

    by jonwil ( 467024 ) on Sunday June 24, 2018 @09:04PM (#56839882)

    The WebAssembly guys are aware of this issue
    https://github.com/WebAssembly... [github.com]
    and dont plan to actually support the new features until they have a solution.

  • Sigh... (Score:5, Informative)

    by EmeraldBot ( 3513925 ) on Sunday June 24, 2018 @09:10PM (#56839894)
    1. WebAssembly is a compressed and simplified version of JavaScript. Anything you can do in WebAssembly, you can do in JavaScript. Seeing as Meltdown / Spectre take a lot of effort to exploit, if this attack is being deployed against you, it's reasonable to assume the attacker is perfectly willing to translate their code into JavaScript, which is already supported in your browser.
    2. The devs [github.com] are well aware of the issue and have said they're not going to reenable the feature that makes them vulnerable to timing attacks without making sure that the mitigations to Spectre / Meltdown are not going to be nullified by WebAssembly.
    • WebAssembly is a compressed and simplified version of JavaScript.
      Anything you can do in WebAssembly, you can do in JavaScript.

      I'm not familiar with the implementation details of WebAssembly, but the above doesn't mean the reverse is (or always will be) true. Just like one can embed assembly in C (using the "asm" keyword), I wouldn't be surprised to see something like that in WebAssembly at some point -- and macros, like "ifdef/define" to allow conditional compilation.

      (Developers may be clever, but are often not the most clever among us.)

    • by gweihir ( 88907 )

      1. WebAssembly is a compressed and simplified version of JavaScript. Anything you can do in WebAssembly, you can do in JavaScript.

      While theoretically true, it may not be in practice. For example, if taking the time precisely enough takes a few seconds in Web Assembly, but a few months in JavaScript, then one attack is valid and a threat, while the other is not in most circumstances. Efficiency does matter to security.

    • Anything you can do in WebAssembly, you can do in JavaScript

      And roughly everything you can do in assembly you can do in C. But C does some extra work, checks or registry backups you might not need, and thus asm will be faster. Webasm is of course not as “free” as asm, but Javascript does even more checks and other side work compared to C, making it slower.

      • Webasm is of course not as “free” as asm, but Javascript does even more checks and other side work compared to C, making it slower.

        The slowest thing in Javascript isn't about safety (arguably the opposite), it's that each variable access is actually a hash lookup. You can't really optimize that out (although you can make it faster to some degree).

    • WebAssembly is not a compressed form of JavaScript. In fact, it has no relationship to JavaScript whatsoever. It allows site owners to run bytecode with the same memory semantics of C on their visitor's machine. As such, there is a lot of things that WebAssembly can do and were left out of the JavaScript design, such as smashing strings and overflowing buffers without the runtime noticing (because to it all the memory used by the script is just a giant array of bytes anyway).
    • WebAssembly is not the same as Asm.js (which is subset of JavaScript)
      WebAssembly is a bytecode similar to C#/.Net bytecode or Java bytecode.

      However it runs in a sandbox like JavaScript and has an API to the JavaScript engine.

  • patch the patch already!
  • the real culprit here is the CPU. Let's not stop all progress (and webasm is progress) due to other components bugs. Of course mitigation has to be implemented (by the browser), but please let webasm follow its improvement path.
    • Webasm isn't progress, it's regress. It's a new way to run untrusted code from an unknown outside source directly on your CPU, which'll end up in the same place every other method for doing this has: being a source for an unending series of remote attacks until browser makers disable it. I'd've thought we'd've learned from previous iterations, but apparently some people are incapable of learning from other people's mistakes.

  • To access my bank account? My email? Social media?

    Obviously not, given that I access them today without it. Wasm is a micro-optimization that becomes irrelevant with faster CPUs, more RAM, and better optimization of JavaScript. The gains are really linear in an area that has produced exponential improvement in the past.

    I guess if you don't want everyone seeing your source code to the client side half of your website you might be interested in Wasm. I'm less than impressed by security-through-obscurity and c

    • To access my bank account? My email? Social media?

      I still believe one of these things does not belong on the internet.

  • The whole idea behind WebAssembly was to make surfing the web insecure by downloading and executing code which is only shielded from the rest of the system by some magical concept called the sandbox.

    Now since Rowhammer, Spectre, Meltdown and possible future problems, we should know that sandboxes don't work. Any form of turing complete code can be used as an attack vector. Even with a hypothetical perfect sandbox you can still abuse it for crypto-mining.

    • by Anonymous Coward

      Sandboxes do work. They're just not the 'magical concept' of your delusion.

  • Access to very accurate timers improves the efficiency of attacks but they are not the core of the attack and the attack still works with far less accurate timers. This has already been explained with proof of concept examples, see https://weblll.org/index.php/s... [weblll.org] Attempts were made to have WebAssembly support mitigation techniques efficiently, but those in control appear to have had different plans and appear to be working towards using 32-bit indexing wasm in a large block of 64-bit address space to cons
  • by LostMyBeaver ( 1226054 ) on Monday June 25, 2018 @07:02AM (#56841236)
    The JIT takes intermediate code and compiled it to native code. By making it that the JIT can&#226;&#8364;(TM)t generate the harmful code, the problem goes away. This is and always was the flaw with JavaScript. Exploits found in any engine that can allow code to be transmitted and executed on a foreign system has always been a security problem. The expertise in compiler development doesn&#226;&#8364;(TM)t always mirror the knowledge required to consider the exploit paths. Therefore, it&#226;&#8364;(TM)s unlikely all possible means of blocking these attacks will be found until they are first exploited. Even today, many of the best compiler developers can tell you absolutely everything a SPARC or a MIPS would do, but only a small number of engineers could explain the pipeline prior to speculative bytecode recompilation on x64 CPUs.

    The engineers developing compiler optimizations for a JIT very likely does not always have the knowledge required to identify paths maliciPIs hackers might exploit the compiled code.

    Code signing is a means of mitigating native code exploits. Of course, we all know people are not quite ready for things like Windows S. Though the Mac world embraces this environment.

    Microsoft&#226;&#8364;(TM)s efforts to move almost entirely to managed code is a great step in the right direction. As RyuJIT gets even better, it will become the default for everything.

    Finally, virtual machines. To handle these issues in that environment may sound impossible, but if you absolutely must run VMs which in theory would allow almost random strangers to provision their own insecure VMs to hack other users VMs, then realize that VMware and everyone else has implemented dynamic recompilers (JITs) for processing hardware emulation for a long time. VMware for example intercepts code targeting I/O operations that are based on legacy x86 I/O by recompiling the code as trapping I/O calls has never been supported. This is how legacy VMs are able to identify virtual hard drive parameters through sequential calls to inb against a virtualized CMOS chip.

    By extending the JIT to support binary oriented regular expressions to identify malicious strings of code during dynamic recompilation, an anti malware system could be built. The downside of course is that performance will take a beating. This is simply to be expected, virtualization was always a stupid idea for anyone using it as anything more than a transitioning platform.
    • Re: (Score:2, Funny)

      by Anonymous Coward

      Holy shit dude, what translation script or code page are you running where an apostrophe maps to &#226 ;&#8364 ;(TM) ? That must have taken some work to make it three separate characters each with its own translated code.

  • We've had this discussion before but it takes a lot to exploit a speculative execution bug. These are unlikely to ever be used on a mass attack but rather only in targeted activities. If you're machines are high-value targets, you should (a) have the kernel mitigations enabled even if they have a performance degradation, (b) not be browsing random sites at all. Delivering a SPECTRE attack via JS and extracting something sound like a *fun* project, but it's unlikely to yield any valuable bounty against th

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...