Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Cloud Security

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

Posted by msmash from the security-woes dept.
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.
This discussion has been archived. No new comments can be posted.

Kubernetes' First Major Security Hole Discovered More

Kubernetes' First Major Security Hole Discovered

Comments Filter:

  • I'll give it a try. (Score:5, Funny)

    by fahrbot-bot ( 874524 ) on Tuesday December 04, 2018 @03:17PM (#57749194)

    Can you say root? I knew you could.

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

  • Inside the firewall (Score:5, Informative)

    by phantomfive ( 622387 ) on Tuesday December 04, 2018 @03:19PM (#57749204) Journal

    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).

    • Re:Inside the firewall (Score:5, Insightful)

      by Shaitan ( 22585 ) on Tuesday December 04, 2018 @03:28PM (#57749256)

      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.

      • Re: (Score:1)

        by Anonymous Coward

        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.

        • Re:Inside the firewall (Score:4, Interesting)

          by phantomfive ( 622387 ) on Tuesday December 04, 2018 @04:29PM (#57749602) Journal

          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.

          • Re: (Score:2)

            by AHuxley ( 892839 )
            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.

            • Program cards. In a box.

            • 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

              • Re: (Score:2)

                by AHuxley ( 892839 )
                The other neat trick is to create a fake project idea just for each person who could be trusted.
                Do they run to protest to their boss? Run to look up who to talk to in media/gov? Talk about aspects of the work online using extra social media accounts?
                Talk to academics and media in hidden ways later that day?
                The workers who read the task and say its not going to work/needs more work/could be done but stay 100% loyal are then to be trusted for another few tests and then a "real" project.

        • Re: (Score:2)

          by Shaitan ( 22585 )

          He used su to assume other users logins, he didn't need borrowed credentials.

          • Actually, he still needed the other user's password. When you use su to become another user, you still have to supply that user's password.

            • Re: (Score:1)

              by Anonymous Coward

              Snowden was a sysadmin so he had admin/root/sudo/wheel group access. With sudo su you are good to go.

              • 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.
                • The reasoning behind that is, even if su required the password, someone as root could write a program to allow them to become another user anyway, so it's not going to make a difference. Sysadmins who care about this use sudo to limit and log interactions.

                  • The reasoning behind that is, even if su required the password, someone as root could write a program to allow them to become another user anyway, so it's not going to make a difference.

                    More than that, it would be actively bad for su to require the password. It would make less-thoughtful sysadmins believe that root can't act as any user. This can still happen, witness techno-vampire's misunderstanding, but it would be much worse if he couldn't do a simple test and discover his error in a few seconds.

            • Comment removed based on user account deletion
      • >> when you get to enterprise environments you have segregated permissions

        Sometimes. YMMV.
    • Comment removed based on user account deletion

      • Because no one has ever had employees who were internal threats or had attackers gain access to a company's internal network from the outside?

        You can't stop that.

  • Comment removed (Score:5, Informative)

    by account_deleted ( 4530225 ) on Tuesday December 04, 2018 @03:25PM (#57749232)
    Comment removed based on user account deletion

  • Containerization (Score:2, Interesting)

    by sexconker ( 1179573 )

    I'd rather have 12 isolated VMs than 1 VM with 12 containers, or any amalgamation adding up to 12 containers.
    Storage is cheap. Memory isn't, but a minimal Linux install to support your software stack isn't exactly a big overhead in that regard.
    The only real benefit it brings is having fewer servers (physical or virtual) to manage/update, but you'll still have at least one, so either deal with it or script it.

    • It pains me to use Kubernetes on AWS because you are essentially using a VM in a VM, and if you want you can set up your own images on AWS, too. If you can't write a decent install script, using Kubernetes is not going to help you.

      The only benefit I see to using Kubernetes is that it makes it easier to port from one cloud server to another, if you need to. Because it's becoming the standard that everyone supports.
    • That is not the point. There is a loose coupling between the VM and the application. Which means you are never 100% sure your application runs in the environment it was intended for. With containerisation the application always runs in the environment it was intended for regardless of the infrastructure/vm's. Kubernetes is about devops, not about infrastructure.
  • We'll just code this in, no one will notice.

Slashdot Top Deals

Some people manage by the book, even though they don't know who wrote the book or even what book.

Close