Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kubernetes ingress-nginx controller vulnerability

armosec.io

Post reply on HN
Print view View original

11–20 of 52 posts

Re: Kubernetes ingress-nginx controller vulnerability

#11

Post by asguy »

tbrownaw wrote: post #5
jeffbee wrote: post #2

Are they for real with that curl? Normalize better security practices!

I think it's contrary to currently-recommended ops practice (clearly imperative rather than nominally declarative), but how is it bad security practice? If you don't trust the origin, it's not like saving to a temporary file first is going to help you. Unless you're suggesting that everyone should always do their own code review and then compile from source...

At minimum you could download software that is at least signed by someone you trust. Rather than streaming arbitrary commands from a source that the extent of the authentication is that their CDN's TLS certs matches their domain.

Re: Kubernetes ingress-nginx controller vulnerability

#12

Post by junon »

tbrownaw wrote: post #5
jeffbee wrote: post #2

Are they for real with that curl? Normalize better security practices!

I think it's contrary to currently-recommended ops practice (clearly imperative rather than nominally declarative), but how is it bad security practice? If you don't trust the origin, it's not like saving to a temporary file first is going to help you. Unless you're suggesting that everyone should always do their own code review and then compile from source...

> but how is it bad security practice?

Companies / organizations / team members go rogue sometimes. We've seen this even recently with e.g. kicad, freenode, the timezone database, etc.

Just because you trust the source doesn't mean you should trust all of the scripts they tell you to run. Even if it's a good-faith script, you have no idea if it's making assumptions about your system that are not true and opening you up to sidechannel attacks and the like.

Curl to a file first, inspect the script, consider it within the context of your own system, then run it if you deem it's safe.

Re: Kubernetes ingress-nginx controller vulnerability

#13

Post by tbrownaw »

jeffbee wrote: post #8
doesnotexist wrote: post #7

Earlier quoted context omitted.

Yeah I think everyone feels icky about 'curl https:// .. | sh' but to what degree is doing so any more insecure than other "normalized" software distribution practices? See also: https://twitter.com/moyix/status/1451318133021675520

You can check for this vulnerability using the existing tooling any k8s admin already has on their systems by necessity. It's always foolish to install unknown software and security professionals should never advise that.

> unknown software

Looking at the blog URL and header bar, and the script URL, this is pretty clearly a company blog recommending to use the company's own product. I hardly think that context counts as "unknown".

Re: Kubernetes ingress-nginx controller vulnerability

#14

Post by cassianoleal »

cassianoleal wrote: post #4
blakesterz wrote: post #3

"... a user who can create or update ingress objects, can use the custom snippets feature to obtain all secrets in the cluster." I'm not a Kubernetes guy, so I'm curious, how often is there a user with only those permissions? Is it common to have a user that can create/update and then doesn't already have some kind of other access to everything else? I don't know much about Kubernetes permissions. (I also just learne…

A user can have many permissions in his/her own namespace without compromising the other tenants. This sounds like it would allow any user with Ingress create/update access in any namespace to compromise secrets across all namespaces.

It is unclear whether this is a problem if you're running namespaced ingress-controllers though. This comment [0] in the bug report says:

    there's definitely an attack path that gets the ingress-nginx service account token, which has list rights on secrets at a cluster level (so allowing for all secret values to be retrieved).
I can't see how list permissions would allow retrieval of the secret value though. You'd need get permissions for that.

[0] https://github.com/kubernetes/ingress-nginx/issues/7837#issu...

Re: Kubernetes ingress-nginx controller vulnerability

#15

Post by 015a »

jeffbee wrote: post #2

Are they for real with that curl? Normalize better security practices!

I will argue until the day I die: curl | bash is actually more secure than most traditional software delivery mechanisms. Slightly, but meaningfully.

With curl | bash, the URL of the bash script is right there. I can copy it, plug it into my browser, and inspect with ease the shell script that will run. If its on Github or a similar site, I can see in plain language the exact organization who published it (I wouldn't implicitly trust whoever "armosec" is, but I would trust, for example, "kubernetes", "microsoft", or "google" e.g.).

Alternatives?

- For something like this, to generate a report on whether you're affected? Maybe just a copy-paste bit of code? Isn't that the same thing, but less convenient?

- apt-get install something. Who published it? Does apt have security scanning (no lol)? Where's the source code for that package (scattered to the wind no doubt)? Does it have reproducible builds so I can be certain the code I eventually find is what I install (lol no. but bash scripts do!)

- Let's talk about `snap` for a second; Did you know that there's a `snap install aws-cli` package available [1], published by "Amazon Web Services", with a verified checkmark. Sounds great. Except, for years, no one on the actual aws-cli team had any idea where it came from [2]. They didn't authorize it, and they don't maintain it. It turns out, it was probably the result of a hackathon project by one AWS engineer. "Better security practices" for sure!

The only legitimate risk I've heard about 'curl | bash' is that web servers can detect whether the site is being accessed by a browser versus curl, and serve different content. Legit risky, good to educate about; don't curl | bash from sites you don't recognize. But this is a GitHub link!

I would agree that package managers are superior from a security angle, if most package managers had strong security review processes, on both the package content and the publisher. The problem is: they don't. They're all lacking in this regard, from apt to flatpak to the Apple App Store. The most sophisticated is probably the Play Store, but binary command line distribution channels are nowhere close to having reproducible builds, verified Real ID developers, static analysis on distributed binaries, etc. Package managers are literally just "curl | bash" with some steps added. By and large, anyone can publish anything under any name; educating people that they're "safe" is actually a massive disservice.

[1] https://snapcraft.io/aws-cli

[2] https://github.com/aws/aws-cli/issues/5142

Re: Kubernetes ingress-nginx controller vulnerability

#16

Post by justinclift »

asguy wrote: post #10

> Hey Everyone, here's a high severity vulnerability report, to check for it, run the folliowing: curl -s https://raw.githubusercontent.com/noideawhatyourerunning/ins... |/bin/bash .... oh man

Don't forget to add a "sudo" in there for extra goodness. :D

Re: Kubernetes ingress-nginx controller vulnerability

#18

Post by justinclift »

tbrownaw wrote: post #5
jeffbee wrote: post #2

Are they for real with that curl? Normalize better security practices!

I think it's contrary to currently-recommended ops practice (clearly imperative rather than nominally declarative), but how is it bad security practice? If you don't trust the origin, it's not like saving to a temporary file first is going to help you. Unless you're suggesting that everyone should always do their own code review and then compile from source...

> If you don't trust the origin, it's not like saving to a temporary file first is going to help you.

Huh? The whole point is to review the the code before you run it.

If it seems like many people _don't_, well frankly, that's their problem.

Encouraging bad practise is not the right direction.

Re: Kubernetes ingress-nginx controller vulnerability

#19

Post by justinclift »

tbrownaw wrote: post #13
jeffbee wrote: post #8

Earlier quoted context omitted.

You can check for this vulnerability using the existing tooling any k8s admin already has on their systems by necessity. It's always foolish to install unknown software and security professionals should never advise that.

> unknown software Looking at the blog URL and header bar, and the script URL, this is pretty clearly a company blog recommending to use the company's own product. I hardly think that context counts as "unknown".

Lets say (for example) that was published on a wordpress site, and the admins for whatever reason didn't secure it properly.

The article in question which _today_ looks all legit and points to a nice working script, might tomorrow be pointing to someone else's script that's a lot less legit.

And yes, in this imaginary scenario that wordpress install leads to a host of other problems for the company.

No need to make them your problems too though. ;)

Re: Kubernetes ingress-nginx controller vulnerability

#20

Post by k8sToGo »

junon wrote: post #12
tbrownaw wrote: post #5

Earlier quoted context omitted.

I think it's contrary to currently-recommended ops practice (clearly imperative rather than nominally declarative), but how is it bad security practice? If you don't trust the origin, it's not like saving to a temporary file first is going to help you. Unless you're suggesting that everyone should always do their own code review and then compile from source...

> but how is it bad security practice? Companies / organizations / team members go rogue sometimes. We've seen this even recently with e.g. kicad, freenode, the timezone database, etc. Just because you trust the source doesn't mean you should trust all of the scripts they tell you to run. Even if it's a good-faith script, you have no idea if it's making assumptions about your system that are not true and opening you…

> Curl to a file first, inspect the script, consider it within the context of your own system, then run it if you deem it's safe.

But you can still do that if you want? It is not like this is a hidden executable or something.

Post reply on HN