18 ms·

> By December, all Google Cloud Platform (GCP) services had protections in place for all known variants of the vulnerability. Could other major cloud providers

• kardianos 9y ago
  I agree it is impressive. But if you are running your own hardware, you probably aren't sharing CPU time with strangers as GCP is.
  • tzar 9y ago
    That's a fair point, but somehow the nervous feeling isn't limited to sharing CPU time with strangers! The amount of platform complexity abstracted by the GCP services is staggering. This is the job of taking a (hopefully) understandable piece of computer code that represents some real-world logic and installing it into reality, in a sense. It's clear that it's a very messy world out there for a program.
  • boulos 9y ago
    Disclosure: I work on Google Cloud. Even if you aren't sharing with "strangers", applications may be vulnerable to these attacks. For example, the JavaScript attack clearly applies to people's individual computers. If you take untrusted code and execute it, you might be vulnerable to these intra-"instance" information leaks. It all comes down to your threat model though. Some people are rightly worried about insider risk. If a malicious employee can go run a binary on your shared computing infrastructure to get root credentials out of a machine, that's actually a real problem. Then again, there are lots of ways for a rogue employee to do bad things, so this is "just" another one. But don't take this as "only applicable to shared cloud environments", because it's not.
    • qaq 9y ago
      Sure but when you are worried about insider risk (and even if you are not) you most likely have strong access controls, extensive logging, endpoint security solution that can mitigate or at least alert on this activity.
      • toomuchtodo 9y ago
        To manage insider risk, we do everything you mention (as well as much more I can’t mention). We treat insider risk the same as external threats: ever present and requiring constant vigilance. The VM is not considered a security boundary any longer; tenancy controls are now in place, to prevent attacks similar to Meltdown and Spectre that are yet undiscovered.
    • cm2187 9y ago
      I am not too worried about javascript as it runs in a VM where the browser has full control on how code gets executed, and I trust browser vendors will come up with a mitigant. Otherwise on a personal computer, if malware gets to execute in user mode, being able to access some machine private key is the least of our worries. The sensitive information is the documents stored on the machine, whether it is for them to be leaked or encrypted, if the code can access them in read/write, the party is already over.
    • merb 9y ago
      well there are still people out there who do not have these problems, i.e. people who have just a "few" employees to manage infra. people who have VMs just to actually limit compute nodes. Actually we have our Test Infrastructure seperated from the rest, so basically only this runs untrusted code.
• notatoad 9y ago
  I feel like even without this, there's a fair argument to be made that Google is better at running hardware than most little guys are.
  • andrewstuart2 9y ago
    And it's not necessarily a bad thing, either. Economies of scale means that everybody can win by putting all your chips in one basket. The obvious caveats apply when said basket stands to gain from serving its own interests once all the chips are there. One example of that might include patching your own hardware while waiting to offer the same capabilities to others.
  • Spooky23 9y ago
    Absolutely. My wife is an amazing and talented baker. But... any number of bakeries are better at rolling out a quality consistent product at scale. Ditto with datacenters.
  • kriro 9y ago
    It's a very interesting trade off one faces. On the one hand I'm very concerned with hosting anything in the cloud, especially with U.S. based companies because +3-letter agency here+ (especially for ERP software). But on the other hand the realistic view has to be that my self hosted stack is likely way more insecure than any cloud stack even if I made a conscious afford to keep everything secure (and that's probably also true for companies with a decent number of dedicated IT security experts) so 3-letter agancy would have an easier time getting to the data if they wanted.
• jacksmith21006 9y ago
  Think they deserve to. But not just just vulnerabilities but they also discovered Broadpwn, Cloudbleed, Heartbleed and a bunch of other ones. Sometimes do not think they get the credit they deserve.
  • zengid 9y ago
    Whether they get credit or not, they certainly have the advantage of knowing about the vulnerabilities before they're published.
    • andrewstuart2 9y ago
      I'm kind of okay with that as long as they're not holding out to give themselves an advantage. If somebody is going to discover these, why not a cloud provider who can protect huge numbers of clients early? If it was a little guy who discovered it, then everyone except maybe a fraction of a percent of the world (or nobody if the discoverer runs no servers) gets the same late start.
      • boulos 9y ago
        Disclosure: I work on Google Cloud. Project Zero disclosed this to Intel, AMD and ARM on June 1 as stated in the blogpost [1]. I believe an independent researcher working somewhere else (or even at home) would have done the same, as indeed the parallel independent discoveries ultimately did. [1] https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi...
        • andrewstuart2 9y ago
          Yeah, I'm not saying anything was withheld. I'm just pointing out that Google probably had a fix in mind, tested, and deployed much sooner than most. Not a bad thing, rather a good thing that's just a benefit of having been the ones to discover it. You can patch your own machines with a lot lower global risk than sharing outside the company.
• matwood 9y ago
  > Could other major cloud providers boast this? Not sure. AWS sent out alerts in early December than many instances needed a reboot, and would be force rebooted on 1/8 iirc. I'm guessing it was to handle patches that were put in place for these issues.
  • boulos 9y ago
    Disclosure: I work for Google Cloud. We were naturally first because we took action internally, but also because we didn't need to reboot guests to ship new kernels to hosts. We update kernels on our hosts frequently, and so nobody would have particularly noticed that their VMs underwent migrations (we do it all the time!).
    • cthalupa 9y ago
      AWS rebooted PV instances to implement the Vixen shim ( https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg00436.html https://lists.xenproject.org/archives/html/xen-devel/2018-01... ) from my understanding. I do not believe that HVM instances (which would be closer to your KVM infrastructure) needed to be rebooted.
      • mr_toad 9y ago
        I had an HVM instance that had forced downtime.
        • soccerdave 9y ago
          I had 35 HVM instances that didn’t have forced downtime. There are other reasons a machine could need to be brought out of service.
          • Torgo 9y ago
            Seconded, I have about 320 HVM instances and have received only a handful of reboot requests.
• qaq 9y ago
  Why? If you run on your own hardware how would this impact you?
  • collinmanderson 9y ago
    It basically means that all of your programs and users have root access. If a buffer overflow happens on an exposed non-root service, it now has a way to get root access. It takes away a layer of security.
    • qaq 9y ago
      Well for a traditional web service your only exposed service is something like NGINX. So yes it makes the vuln. in say NGINX more severe but the attack surface is pretty small. Also the only users that have access are SRE or equivalent who have root access anyway. (I am not arguing that there is no downside just that it's fairly limited in a traditional scenario)
• partiallypro 9y ago
  The problem is sometimes they have dumped some exploits onto the public without giving their competitors enough time to fix the problem...they've done this multiple times to Microsoft. It's good in so long as they don't abuse it and it's treated as a public good rather than a corporate middle finger to its competitors.
  • cbcoutinho 9y ago
    What do you consider enough time? Google maintains a strict 90 day grace period so that the other party can figure out how to address the issue. If not 90 days, what should it be? In a world of complicated software, we need to have a discussion of what vulnerabilities users are subjected to by using a product, and whether/when users should be notified that those vulnerabilities exist
    • zaroth 9y ago
      Not so strict in this case!
      • euyyn 9y ago
        I think your parent meant strict as in "it gets disclosed after 90 days, no extensions".
        • deleted 9y ago
          [deleted]
        • fiddlerwoaroof 9y ago
          The article said it made a special exception in this case. That being said, unusual circumstances call for unusual procedures.
          • euyyn 9y ago
            My impression is it's always "90 days or whenever it's made public by other means, whatever happens first".
• oh-kumudo 9y ago
  That is why Cloud companies are similar to insurance companies. Little guys won't stand a chance against them.
  • adventured 9y ago
    I don't think they're like insurance companies at all. Cloud companies don't generate a big investable float based on a very low initial cost of the service provisioning. Quite the opposite, cloud companies have substantial pre-existing costs related to being able to provide the cloud services to each customer (including being able to do it at immense scale as necessary). That cost remains considerable and on-going at all times during the service providing period generally speaking. For insurance companies, the cost for a given policy is extremely low until a claim arrives. To be like insurance companies, this is how their cloud business would have to work: you pay them $20,000 over ten years while receiving absolutely nothing tangible in return, until one day, ten years in, you need to utilize $25,000 in cloud services in a short burst. Then afterward, your bill goes up significantly, while as an industry they reduce what you get for that. Beside that, there are exceptionally few things the little guy stands a chance at when competing head-on with a giant. The giant benefits from bargaining power at scale that is usually rather dramatic on most everything. Eg Diapers.com was a well funded, well run ecommerce start-up. Amazon was going to destroy their business through scale leverage - applying plausibly anti-competitive below-cost tactics on core products like diapers - to put them under if they didn't agree to be acquired (Amazon had already begun applying that tactic in the lead-up to the acquisition, scaring the hell out of Diapers.com).
• taneq 9y ago
  > It seems like Google's brand is benefiting tremendously from Project Zero in all of this. Is that not how it's meant to work? They're paying to run a top notch security team which is actively discovering vulnerabilities and creating fixes for them. Should they not benefit from this?
  • improv32 9y ago
    surely, tzar meant that in a positive way