There is a path traversal vulnerability in Ring that affects applications that serve resources from the filesystem. It does not affect Ring sites deployed as uberjars.
Versions affected: Every version prior to 1.5.1; 1.6.0-beta1 to 1.6.0-beta6
Fixed versions: 1.5.1, 1.6.0-beta7
This vulnerability is caused by a bug in the ring.util.response/resource-response function. An attacker can use this vulnerability to access files that are in a directory on the classpath, but they cannot access resources contained in a jar.
This also affects the ring.middleware.resource/wrap-resource middleware, and the compojure.route/resources function.
Consider a minimal Compojure application:
(:require [compojure.core :refer :all]
[compojure.route :as route]))
(GET "/"  "Hello World")
(route/not-found "Not Found"))
Assume that this isn't packaged as an jar when deployed, but is deployed as a directory of source files. An attacker can craft a URL to read any file on the classpath that is not in a jar:
Unlike the file-response function, the resource-response function did not properly santize the path from the client.
The resource-response function now checks for path segments containing "..", and also ensures that for file-based resources, the canonical filepath of the resource must be contained within the canonical filepath of the :root option.
This fix means that Ring will not follow symlinks on the classpath if they lead to files or directories outside the path specified in the :root option. If you happen to need this for any reason, then you need to set the :allow-symlinks? option to true.
Upgrade to 1.5.1 as soon as possible.
Thanks go Tim McCormack for discovering this vulnerability, and his responsible disclosure of it. Thanks also go to Dmitri Sotnikov for reviewing the fix.