Nytro Posted April 7, 2019 Report Share Posted April 7, 2019 CVE-2019-9901 - Istio/Envoy Path traversal TLDR; I found a path traversal bug in Istio's authorization policy enforcement. Discovery About a year ago, as a part of a customer project, I started looking at Istio, and I really liked what I saw. In fact I liked it so much that I decided to submit a talk for it for JavaZone in 2018. My favorite thing about Istio was, and still is, the mutualTLS authentication and authorization with workload bound certificates with SPIFFE identities. Istio has evolved a lot from the first version 0.5.0, which I initially looked at, to the 1.1 release. The 0.5.0 authorization policies came in the form of deniers, which sounded a lot like blacklists. The later versions have moved to a positive security model (whitelist), where you can specify which workloads (and/or end-users based on JWT) should be allowed to access certain services. Further restrictions can be specified using a set of protocol based authorization rules. I really like the coarse-grained workload authorization, but I'm not too fond of the protocol based rules. We have seen different parsers interpreting the same thing in different ways way too many times. Some perfect examples of this, are in Orange Tsai brilliant research presented in A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!. I mentioned my concerns about this in some later versions of my Istio talk, but never actually tested it... untill now... The bug I set up a simple project with a web server and deployed it on Kubernetes. The web application had two endpoints /public/ and /secret/. I added an authorization policy which tried to grant access to anything below /public/: rules: - services: ["backend.fishy.svc.cluster.local"] methods: ["GET"] paths: ["/public/*"] I then used standard path traversal from curl: curl -vvvv --path-as-is "http://backend.fishy.svc.cluster.local:8081/public/../secret/" And was able to reach /secret/. Timeline The istio team was very friendly and responsive and kept me up to date on the progress. 2019-02-18: I send the intial bug report sent to the istio-security-vulnerabilities mailbox 2019-02-18: Istio Team acknowledges receiving the report 2019-02-20: Istio Team reports the bug has been triaged and work started 2019-02-27: I ask some follow up questions to the mail received on the 20th 2019-02-27: Istio Team replies to questions 2019-03-28: Istio Team updates me about working with the Envoy team to fix this and plan to release this on April 2nd. The envoy issue was created on the 20th of February: https://github.com/envoyproxy/envoy/issues/6008 2019-04-01: Istio Team sends an new update setting April 5th as a new target date 2019-04-05: The security fix is published in Istio version 1.1.2/1.0.7 and Envoy version 1.9.1. The Envoy bug is assigned CVE-2019-9901 Sursa: https://github.com/eoftedal/writings/blob/master/published/CVE-2019-9901-path-traversal.md Quote Link to comment Share on other sites More sharing options...