back to article Google engineer urges web devs to step up and secure their code in this data-spilling Spectre-haunted world

After the disclosure of the 2018 Spectre family of vulnerabilities in modern microprocessor chips, hardware vendor and operating system makers scrambled to reduce the impact of data-leaking side-channel attacks designed to exploit the way chips try to predict future instructions. Intel and others rolled out firmware patches, …

  1. Throatwarbler Mangrove Silver badge


    A friend of mine just got back into development after years of teaching high school and is getting back up to speed on coding Web applications. I suspect his focus will be on getting his code to work at all. The application he's writing might net him a small paycheck, but his focus is going to be on nailing down future employment opportunities. I suspect that the odds of him ruthlessly sanitizing his inputs according to this model are slim. Not saying that he's not to be held accountable for secure coding, but what are the new programmers (or old, set-in-their-ways, programmers) to do? What's being described sounds like a lot of hard, painstaking work of the sort that management won't care about when it gets in the way of adding features or hitting release targets. I know that the readership of El Reg are literally the best programmers on Earth (in their own minds, at least), so what's the answer, guys?

    1. Martin Gregorie Silver badge

      Re: Doomed

      A new hardware and OS architecture bearing a strange resemblance to the hardware rings of protection used by operating systems like ICL's VME/B (and possibly also the Burroughs B-series and IBM/s progressively renamed Future Series->System/38->AS/400->I-Series hardware) could be as good as way as any of preventing this sort of cross-process data-stealing bug.

      I've designed systems and written code for VME/B systems and never heard even a rumour of process-process interference occurring. Same for the AS/400.

  2. b0llchit Silver badge

    CORS and other holes by design

    Actually, most of the CORS concept and the current "we'll get code, data and content anywhere we damn please" attitude are the main problem. Any sane development and deployment would reduce the attack surface by serving your own (vetted) code from your own server(s). But that does not fit into the current strategy, which calls for bloating a site with foreign references and more uncontrolled data and code imports with patches stacked layer upon layer.

    The whole idea of KISS has been lost on web-development and the complexity mountain has become so high and heavy that the base is sinking into the ground. What we require is more simplicity so it becomes easier to see through. It also would make most stuff much faster in the process and reduce traffic. A back to basics approach should be welcomed.

    1. TFL

      Re: CORS and other holes by design

      I can't say that I disagree, at least to the extent that this behaviour seems to have become the norm these days.

      To the extent that there may be benefits in using some of these other services, could devs not simply white-list only the things that are allowed? Defining these things should be a matter of doing it once (for a site, say), and serving up the expected headers on every damn page as part of whatever templates are used.

      While each specified hole adds some element of risk, the process of documenting that arrangement and those risks should suffice with minimal maintenance.

      There will be a certain set of marketing folk who will scream bloody murder of course, since they're likely responsible for having dozens of trackers and ads attached to a site, but TFB.

    2. Anonymous Coward
      Anonymous Coward

      Re: CORS and other holes by design

      OK, but how's that going to make Google any more money?

  3. sreynolds

    How do they get away with it?

    Hello, if Intel sold shite, and misrepresented its hardware, or even if it made an honest mistake, it should pay to fix this silicon. Why should the customers pay twice, once to be fucked over by Intel and yet again to fix things that were broken by Intel.

    Ok, so which one of you wrote this?

    1. Claptrap314 Silver badge

      Re: How do they get away with it?

      By manner of background, I worked for AMD & IBM for a decade doing microprocessor validation starting just before this stuff came online.

      Here's the crazy thing--they did precisely 0 of those things. And as a Former Loyal AMDer, it pains me to say it. ;)

      When speculative execution and especially speculative memory accesses were considered, very senior people in the industry tried and failed to realize attacks of this class. It took almost twenty years for an effective attack to be found.

      Moreover, they never represented their hardware as being secure against side-channel attacks. In the front of the manual for these processors, there is a full page warning to potential government users that the product is not certified for use with classified data.

      And yet, we live our entire lives through these devices.

      The problem is not that the processors are not fit for purpose. It is that we decided to use processors in a manner contrary to the manufacturer's warning.

      1. sreynolds

        Re: How do they get away with it?

        Are you apologizing for incompetence? Or just because someone else takes shortcuts derives profit you can justify that also? Or are you saying that if someone puts a slightly more powerful turbofan on a plane and then tries to fix it in the software that they should not be held to account?

        1. Claptrap314 Silver badge

          Re: How do they get away with it?

          I am saying that

          #1 The manufactures did due diligence at the time when implementing these features for consumer products.

          #2 The manufacturers warned in the product literature that the parts were not certified for CONFIDENTIAL use.

          There is nothing to apologize for. If you buy your three year old a plastic bat, and on the label it says, "Not for use with MLB", are you going to expect it to take a pitch from the Minors? I expect you will be wanting your money back...

  4. RyokuMas Silver badge


    So a Google engineer wants web devs to secure their code in order to data leaking out to parties that the user wouldn't want accessing it...

    Is anyone else laughing their backsides off at the irony of this?

    1. Ken Hagan Gold badge

      Re: Irony

      This is the same google that desperately wants to adds "APIs" to let browsers (that is, scripts from a fourth party added by a third-party ad-broker to a second-party web-page that you happen to visit) access the whole PC rather than just a sandbox.

      1. Robert Grant Silver badge

        Re: Irony

        Maybe Google isn't a straw man single entity, and is instead a corporation made up of many different types of people.

  5. Anonymous Coward
    Anonymous Coward

    its all a bit...

    well, SPECulative, really. The spectre bug has been around for 3 years now.

    It only really works in a very limited number of circumstances, and has never been found in the wild for real. Yes I understand that it could be an attack surface - but if machines aren't patched, then there are lower hanging fruit than a highly custom attack code.

    I know beeping computer posted an article last week about finding 2 exploits in cracked software - big deal. Had it been in a legit software like the Solar winds issue then I would be more concerned.

    Until there is a real and general purpose vulnerability, then I wont worry (much).

    1. Ben Tasker Silver badge

      Re: its all a bit...

      > Until there is a real and general purpose vulnerability, then I wont worry (much).

      The problem there is that you're relying on the idea that the "good guys" will find the vulnerability first.

      Otherwise, the vulnerability will be being exploited in the wild first, so you've got two periods of vulnerability:

      - The gap between first exploitation and someone identifying that it's being exploited

      - The gap between identification and someone figuring out how the hell to fix it

      If the answer to "how do we fix this" is "developers need to use more rigorous standards" (as in TFA) then you're screwed.

      It's far better to look at paths that can avoid future exploitation, because you've got the luxury of time to try and create trade-offs that reduce the burden on devs and/or the complexity of the mitigation code.

      > then there are lower hanging fruit than a highly custom attack code.

      It's only highly custom while it's a PoC, the first code you see in the wild might be novel but extremely generic.

      1. Anonymous Coward
        Anonymous Coward

        Re: its all a bit...

        yeah, I do understand what your saying --and the comments are fair enough- however its a balance of risk thing for this particular issue. I honestly think the industry cried wolf on this one (before understanding the implications fully)

        - the spectre issue is nearly 3 years known now. POC has been about since then.

        - The most vulnerable processors will be out of the ecosystem in another couple of years

        - The POCs have to run locally - and require insecure code.

        - The current O/Ses out there do mitigate the highest risk (at the expense of performance, true).

        since Spectre came out, some absolutely nasty bugs have come out which have more easily exploitable risks - Obsolete services (the fax server issue last month) are a much more 'clear and present' danger than Spectre.

        on the risk indicies in corporate IT - reducing attack services would be of more benefit and have a higher priority score than spectre.

        1. sreynolds

          Re: its all a bit...

          Sorry, I was too busy digging a hole in the sand in which I could place my head.

  6. Dan from Chicago

    There's only one way to do it

    Make everyone liable for their mistakes. If you're injured because the maker of the car failed to secure the connection between the fuel line and the engine, the car company will have to pay - so they're careful to try to not let that happen. They're willing to spend time and money to make sure that doesn't happen.

    Web sites do the equivalent of killing and injuring millions of their customers very day, but since all of the costs are born by the users, web site developers continue to send their "death traps" out into the the network.

    We've tried the "honor system." It didn't work. Time to let the lawyers get involved.

    It's a horrible solution, but it's better than every other solution.l

    1. Claverhouse Silver badge

      Re: There's only one way to do it

      Release the Lawyer !

    2. Claptrap314 Silver badge

      Re: There's only one way to do it

      See my replies.

    3. John Jennings Bronze badge

      Re: There's only one way to do it

      You have heard of the ford pinto?

      That was in production, with a known fatal flaw (for the driver!) for 6 years, with the flaw known about in design (so 8 years total).

      Cost to ford was ultimatelty aprox $5M in damages, recalls of 300K cars and a slap on the wrist.

      In that case, they had known that a $1-$4 fix per unit would have avoided the issue - which they decided was not cost effective.

      Do you really think liability will work for the fail fast culture? Fixes here cost a LOT more than 4 bucks.

  7. Mike 137 Silver badge

    Five step program

    The proposed five step program(me) is fine in theory, but it will be hard to adopt in a culture where practically nobody even bothers to sanitise user input, check that their buffers are big enough for incoming data or make sure that they're using the right kind of integer for the task. We'll have to get these real basics firmly in place before any of the five steps can be reliably implemented, but, given the persistence of such basic errors for so many decades, I'm damned if I know how that's going to be achieved.

  8. Claptrap314 Silver badge

    Or maybe...


    Once more, for the new kids: (I spent a decade doing microprocessor validation at IBM & AMD.)

    1) Spectre-class vulnerabilities are not bugs. The hardware specification makes no claims regarding side channels. Furthermore, one of the first pages in the manual is a warning that the processor is not certified for use with classified material.

    2) The consumer is king. Speculative memory accesses allow system speedups on the order of 10x.

    3) Spectre-class vulnerabilities cannot be mitigated by software (short of flushing all caches every time there is a context switch and only running on a single thread). They are endemic to the way that current caches behave in the presence of speculative memory access. Yes, there were BIOS fixes issued by Intel to fix a related issue. Arguably, that is WAS a violation of the spec.

    4) I am not tracking this issue closely, but I am yet to hear of any claims by any CPU manufacturers that current or new hardware will be immune to this class of bugs. I have spent some time thinking about solutions, and while I have something, it adds a lot of complexity to caches, and may affect timing on small caches.

    This press release smells like a lot of "we're not evil"--it's the people who use our "services"!

  9. CrackedNoggin

    I think it is hopeless to rely on "the browser" itself for security. Instead, work on isolating the browser, e.g., running it in a container, or even better on separate physical hardware (but sharing a screen, and enabling manual message passing to allow cut and paste of passwords). Loggin into a bank should be done on an isolated virgin just started-up browser, and the side-effects should be nuked when finished.

    That basic strategy is possible more or less now - but is hugely incovenient - it has been made so deliberately. Even in firefox, trying to get rid of all state between invocations (except for ublock, etc) is incredibly hard work.

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

Biting the hand that feeds IT © 1998–2021