IP Restriction Bypass
Synopsis
An issue has been detected in Kallithea that would be a security issue for Kallithea instances that have configured a specific list of allowed IP addresses. In such case, a malicious user would be able to bypass such IP address restriction if they know at least one IP address that is in the list of allowed IP addresses.
In a similar way, a malicious user could fake the URL scheme (HTTP or
HTTPS) in case either https_fixup, force_https or use_htsts is enabled in
the Kallithea configuration file.
Description
When Kallithea is processing HTTP requests from a user, it will see and use some of the basic properties of the connection, both at the TCP/IP level and at the HTTP level. The WSGI server will provide this information to Kallithea in the "environment".
In some setups, a proxy server will take requests from users and forward them to the actual Kallithea server. The proxy server will thus be the immediate client of the Kallithea WSGI server, and Kallithea will basically see it as such. To make sure Kallithea sees the request as it arrived from the client to the proxy server, the proxy server must be configured to somehow pass the original information on to Kallithea, and Kallithea must be configured to pick that information up and trust it.
The exact way the original connection information (including the IP address) is passed depends on the proxy server. This means that Kallithea may need to read one of several WSGI environment variables (derived from HTTP headers) to get the necessary information.
The issue detected is that Kallithea releases prior to 0.7.0 would automatically trust all of the supported headers, rather than only trusting those specific headers known to be set by the trusted proxy server (if present).
As a result, a malicious user could pass incorrect connection information (like a fake IP address) in any of the headers resulting in a bypass of an IP address restriction (assuming that the fake IP address used is effectively allowed by the Kallithea instance).
A description of such an attack is given in [3], even though it focuses on just one of the possible headers.
In a similar manner, Kallithea was considering and trusting several headers that specify
the URL scheme (HTTP / HTTPS), while it should only trust the specific header
that the trusted proxy server was effectively using. This problem could happen if
any of following Kallithea configuration settings was enabled: https_fixup,
force_https, use_htsts.
Note that Paste Deploy Prefix Middleware (egg:PasteDeploy#prefix) has the same
issue. This middleware is not enabled by default, but it is "recommended" in a
comment in the Kallithea configuration file.
Resolution
In Kallithea 0.7.0, the connection information headers are now by default ignored. This will work fine for setups without proxy server.
When Kallithea is behind a proxy server, the Kallithea configuration file must
be updated to specify which headers to use and trust, depending on the proxy
server used. Specifically, variables remote_addr_variable and
url_scheme_variable have to be set correctly. Variable https_fixup has been
removed. Refer to the documentation [2] for details.
Also, if using Paste Deploy Prefix Middleware, make sure to set
translate_forwarded_server = False in the same section.
Affected versions
This vulnerability has been fixed in release 0.7.0 and is present in all
versions of Kallithea prior to 0.7.0. The issue is only applicable to setups
having configured IP address restrictions in Kallithea or having enabled any of
the following variables in the configuration file: https_fixup, force_https,
use_htsts.
This issue could not be fixed in a minor update due to the need of a configuration change in case Kallithea is behind a front-end server.
Users are advised to upgrade as soon as possible and update their configuration file to make it explicit which HTTP headers should be trusted.