Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Wednesday December 05 2018, @10:37AM   Printer-friendly
from the just-make-containers-all-the-way-down dept.

First major security flaw in popular cloud container orchestrator Kubernetes discovered – and it may be impossible to tell if you have been compromised

As outlined on Redhat’s website, the security hole or “privilege escalation flaw” is a nasty piece of work. In a nutshell, it makes it possible for any user to gain full administrator privileges on any compute node being run in a Kubernetes cluster.

[...] The vulnerability itself is located in the Kubernetes API server. Using a specially crafted connection request, the hacker can connect through the Kubernetes API server direct to the backend. Once in the network, they can then send arbitrary requests over the same connection to the backend server.

Perhaps most alarmingly, the Kubernetes API server connections to the backend are all authenticated with Kubernetes Transport Layer Security (TLS) credentials – meaning all the nefarious connections appear above board and applications functioning as normal.

[...] “There is no simple way to detect whether this vulnerability has been used. Because the unauthorized requests are made over an established connection, they do not appear in the Kubernetes API server audit logs or server log. The requests do appear in the kubelet or aggregated API server logs, but are indistinguishable from correctly authorized and proxied requests via the Kubernetes API server,” reads the post.

It doesn’t take a whole lot of hacking-nous or access privileges to take advantage of the flaw, either: “In default configurations, all users (authenticated and unauthenticated) are allowed to perform discovery API calls that allow this escalation,” continues the post.

[...] It remains to be seen whether the security flaw has been used to attack any Kubernetes user.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by quietus on Wednesday December 05 2018, @09:55PM

    by quietus (6328) on Wednesday December 05 2018, @09:55PM (#770299) Journal

    I do appreciate the sentiment [acm.org], yet do not completely agree i.e. your remark that "there are encryption methods that are claimed by fairly reliable people to be more than just reasonably secure [baud.fr]".

    You probably know, but at least some unsuspecting readers -- typically programmers -- assuredly do not realize that if you send a large number of packets encrypted with AES without regularly changing the symmetric encryption key, you could just as well have sent your data in the clear. Encrypted data storage, while it will slow down a curious person a bit: he'll feel the need to fire up his mathematical cluster [sdsc.edu] -- is similar.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2