Slashdot Mirror


Kubernetes' First Major Security Hole Discovered (zdnet.com)

Kubernetes has become the most popular cloud container orchestration system by far, so it was only a matter of time until its first major security hole was discovered. And the bug, CVE-2018-1002105, aka the Kubernetes privilege escalation flaw, is a doozy. It's a CVSS 9.8 critical security hole. From a report: With a specially crafted network request, any user can establish a connection through the Kubernetes application programming interface (API) server to a backend server. Once established, an attacker can send arbitrary requests over the network connection directly to that backend. Adding insult to injury, these requests are authenticated with the Kubernetes API server's Transport Layer Security (TLS) credentials. Can you say root? I knew you could. Worse still, "In default configurations, all users (authenticated and unauthenticated) are allowed to perform discovery API calls that allow this escalation." So, yes, anyone who knows about this hole can take command of your Kubernetes cluster.

9 of 90 comments (clear)

  1. I'll give it a try. by fahrbot-bot · · Score: 4, Funny

    Can you say root? I knew you could.

    "Groot" -- Damn it! So close...

    --
    It must have been something you assimilated. . . .
  2. Inside the firewall by phantomfive · · Score: 5, Informative

    So, yes, anyone who knows about this hole can take command of your Kubernetes cluster.

    My understanding is this is only exploitable by people who have access to Kubernetes anyway. Your firewall should not be routing any traffic from the general internet to the Kubernetes api. So this is a good opportunity to check to make sure your firewall is configured correctly, but if you are vulnerable to outside threats, the problems run deeper than a single vuln you'll want to look seriously at your processes and make sure they are security focused. (Or make them more security focused than they are now).

    --
    "First they came for the slanderers and i said nothing."
    1. Re:Inside the firewall by Shaitan · · Score: 5, Insightful

      You are vulnerable to inside threats. In a small org it may not be a factor but when you get to enterprise environments you have segregated permissions. I think Edward Snowden is a hero but that aside, he is a poster child of why you are supposed to have everyone locked down into just the access they need.

    2. Re:Inside the firewall by phantomfive · · Score: 3, Interesting

      Except snowden was a system administrator and he did not use his own access to exfiltrate the documents, he used 'borrowed' credentials from people whose computers he was fixing.

      This sort of thing is why you can't completely stop internal threats. There are too many avenues of attack, and you can't shut them all without really slowing down things inside the business and causing problems.

      This is one of the unsolved problems of security.

      --
      "First they came for the slanderers and i said nothing."
    3. Re:Inside the firewall by techno-vampire · · Score: 2

      I just experimented by opening a terminal and using su - to become root. Then, I used su $USERNAME to see if I could su back to myself and which password I needed. Lo and behold, once you're root, you can su to anybody else without being prompted for a password. Live and learn. I sit corrected.

      --
      Good, inexpensive web hosting
    4. Re:Inside the firewall by swillden · · Score: 2

      Re "This is one of the unsolved problems of security." Keep the next big idea as a spoken topic among 10 ~ 100 workers? A walk in vault with no electronic devices and notes on paper. Look deep into the political and friendship past of all trusted workers.

      You omitted the crucial part of the post you quoted (emphasis mine, obviously):

      There are too many avenues of attack, and you can't shut them all without really slowing down things inside the business and causing problems.

      Yes it's possible to reduce the threat of insider attacks by reducing the set of insiders with access and carefully vetting that small group, and also by adding other measures like technical and and procedural mechanisms to require multiple people to be involved in any access to sensitive data, but anything you do that way is going to "really slow things down inside the business and cause problems". Sometimes data is so sensitive it's worth the hassle and expense. Most of the time, it's not.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  3. Comment removed by account_deleted · · Score: 5, Informative

    Comment removed based on user account deletion

  4. Re:Huh? by Rob+Riggs · · Score: 2

    There are two scoring methods used by CVE, CVSS 2.0 and CVSS 3.0. You may find this link to the vulnerability enlightening: https://nvd.nist.gov/vuln/deta...
    Still, your point is well taken. This is not the first.

    --
    the growth in cynicism and rebellion has not been without cause
  5. Re: So what's next after Kubernetes? by reanjr · · Score: 4, Interesting

    I think it mostly stems from lazy/bad app developers who can't figure out how to install their own app on anything but the one machine it was written on. Their answer is to add the entire OS install as a dependency rather than figure out how security or configuration works. After the whole industry switched from just requiring install dependencies to requiring entire running system snapshots to get anything working, tools like kubernetes were created to address the problems of their own creations.