Open-source Kubernetes tool Argo CD has a high-severity path traversal flaw: Patch now A zero-day vulnerability in open-source Kubernetes development tool Argo lets malicious people steal passwords from git-crypt and other sensitive information by simply uploading a crafted Helm chart. Charts are the actual packaging format of ubiquitous tool-for-managing-Kubernetes applications Helm. The vuln, tracked as CVE- …
While they come up with a solution, best update your installations to one of the fixed versions, as there is "no workaround for this issue."
That suggests the solution is not a permanent correct answer but just a temporary bodge of a leaky patch giving scant relief whilst also coincidentally effectively delivering nothing guaranteed but more time in the 0day space for that particular problem to be further developed for greater exploits via another vein/other veins of stealthy attack ‽ .
Would that be an accurate appraisal of such a supported solution and be more likely than not the probable resultant outcome of the ACT* action/ACTivIT?
ACT* = Advanced Cyber Threat/Treat
I can't speak to the quality of the patch, but "there is no workaround" means that you can't disable the vulnerability in your copy of the software, but you can update the software to the new, safer version.
Since the bug is described as a missing existing safety check of a filename when it is in URI format, I presume that the patched software merely runs the check in that case, instead of not running it.
Having said that, white and black hat hackers probably will be interested now in whether there's another way to break this thing. So users should patch now, and should be prepared either to patch it again soon or to do without it, and should improve security around this product, such as only allowing approved client IP addresses to connect to it, that sort of thing - if it doesn't have that already.
In other words, there actually is a "good" chance of further exploitation of this software. But that is always the case after a bug is patched, regardless of what the software publisher says about it.
If you mount secrets external to helm and dont need it to decrypt any secrets or provide the secrets .... Wouldnt banning any "unknown" helmchart that does not pass first inspection of this vulnerability and banning them and their source also be good practice ... Just like how disabling jog4j jndi functions did not default sanely to disable???
Perhaps someone more knowledgeable could help me out here as the documentation suggests I take a 14 week introduction to Kubernetes course before I even start looking at Argo CD.
However, it looks to me like this has nothing to do with Kubernetes and much to do with Argo CD having its own authorisation system which is attempting to police different levels of access to files stored under a single set of credentials in a git repository. And the remainder of the problem being people blithely storing secrets in widely-accessible git repositories and relying on automatic encryption and decryption to ensure those secrets reach only the right people.
Neither of those sound like particularly good choices if you want to reduce your attack surface. I suppose it's inevitable when so many packages of random origin find their way into the source code or the deployment apparatus of modern software that the collective effects are poorly understood. But it does seem that Ci/CD brings with it Continuous Fragility.
> One of the biggest issues here is that Kubernetes is essential for cloud-native companies. As with Log4j, whenever a ubiquitous piece of code is attacked it makes huge swathes of the internet vulnerable to attack
Let me count the ways:
- Kubernetes is not essential for cloud-native
- Kubernetes is not ubiquitous
- Best of all, Kubernetes was not what was attacked
ArgoCD is a separate tool that some people use to help manage Kubernetes by monitoring a Git repo for changes to config. Thus the person being quoted seems unqualified to comment.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
