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.

Comments

I'll give it a try.

[fahrbot-bot]

Can you say root? I knew you could.

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

Re:I'll give it a try.

[Aighearach]

as long as it isn't Lroot

Inside the firewall

[phantomfive]

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

[Shaitan]

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:Inside the firewall

[phantomfive]

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.

Re:Inside the firewall

[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

[phantomfive]

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: Inside the firewall

[phantomfive]

Well, I do not totally agree with that.

I would be happy to hear why you don't agree, please explain.

Re:Inside the firewall

[xxxJonBoyxxx]

>> when you get to enterprise environments you have segregated permissions

Sometimes. YMMV.

Re:Inside the firewall

[AHuxley]

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.

Re:Inside the firewall

[Shaitan]

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

Re:Inside the firewall

[Shaitan]

Is there a sad but real moderation?

Re:Inside the firewall

[techno-vampire]

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:Inside the firewall

[Anonymous Coward]

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

Re:Inside the firewall

[techno-vampire]

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.

Re:Inside the firewall

[jpaine619]

WTF? No you don't... If you su to root first, you can then su to any account with no password required.. Same with sudo su.

Re:Inside the firewall

[Aighearach]

Program cards. In a box.

Re:Inside the firewall

[phantomfive]

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.

Re:Inside the firewall

[phantomfive]

BeyondCorp uses the paradigm "deploy everything on the public internet." You can only use that approach if you can trust all the software you deploy. If you need to use libraries created elsewhere (like Kubernetes at Google), and there is a good chance it is insecure, then having a firewall will give you an extra layer of security. It's not perfect but better.

Re:Inside the firewall

[phantomfive]

1. Firewalls don't route anything. Firewalls block or allow.

Even if they only forward packets to the next hop, they are still routing.

Re:Inside the firewall

[techno-vampire]

Yeah; I found that out by experiment later. Open mouth, exchange feet.

Re:Inside the firewall

[swillden]

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.

Re:Inside the firewall

[swillden]

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.

Re:Inside the firewall

[AHuxley]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:So what's next after Kubernetes?

[Anonymous Coward]

wtf is kubernetes

The love child of Google's NIH obsession.

and why are people using it??

The industry is full of mindless followers. Those who are able to think rationally about what they are doing are overridden by management who read something in a trade rag one day after a hard days work of golf and banging the secretary and is now an "expert".

Comment removed

[account_deleted]

Comment removed based on user account deletion

Containerization

[sexconker]

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.

Re:Containerization

[phantomfive]

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.

Re:Containerization

[DutchDopey]

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.

Re:So what's next after Kubernetes?

[ArchieBunker]

Was this whole scheme dreamed up because of dependency hell? Like your current distro has no package for a particular binary you're interested in. So you need to compile it and it needs a dozen obscure libraries. One of those libraries news a few more to compile and is currently broken. Or is it a rip off from OSX?

Re:So what's next after Kubernetes?

[Crash Dummy Redux]

Sounds like something Chris would do. Whoever the fuck he is.

Re:Huh?

[Rob Riggs]

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.

Re: So what's next after Kubernetes?

[reanjr]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Back doors

[Dunbal]

We'll just code this in, no one will notice.

Re: So what's next after Kubernetes?

[ArchieBunker]

Shit I had no idea it was that bad. Yeah how could a foreign system snapshot ever cause an issue...

Re:Huh?

[Himmy32]

You realize that since version 3, OpenShift is a distribution of Kubernetes under the hood, right? Here is the CVE for OpenShift for the k8s vulnerability from today

Re:So what's next after Kubernetes?

[phantomfive]

Was this whole scheme dreamed up because of dependency hell?

It's because people don't know how to write install scripts anymore. We've been doing it for decades now, and it's easier than ever, but people think they can solve their problems by using a VM in a VM. They can't: if their installation process is garbage and complex, adding another layer of complexity will not help things.