Date: Thu, 10 Apr 2014 15:12:48 -0400 (EDT) From: cve-assign@...re.org To: felix@...but.de Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: Session IP check bypass in Roundcube 1.0 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Roundcube 1.0-beta added support for the the X-Forwarded-For and > X-Real-IP HTTP headers when the check_ip configuration option is set. > This effectively allows the attacker to bypass the session IP check > completely by setting one of these headers to the victim's IP address. > > The problem is still present in the latest version (1.0). > > http://trac.roundcube.net/ticket/1489729 > http://trac.roundcube.net/ticket/1486776 This can potentially have a CVE ID, but we are not sure about the threat models in which this is or isn't a vulnerability. Obviously a header such as X-Forwarded-For often can be easily spoofed, and the actual source IP address visible to the server usually cannot be easily spoofed. In either case, apparently the entire goal of checking an address value is to provide an additional defense in a case where the attacker has already exploited another problem and knows the session secret. A product is, more or less, entitled to have that goal, even though the goal may seem unimportant. Checking only the source IP address is useful in this threat model: the attacker knows (or can guess) the IP address of the victim's machine, and the attacker has no easy way to establish a TCP session from the victim's external IP address. (For example: the victim and attacker aren't located on the same intranet.) Also, for functionality reasons, the expectation is that the external IP address of a legitimate user does not change during a session. Checking X-Forwarded-For is useful in this threat model: the attacker doesn't know (and can't guess) the IP address of the victim's machine, but the attacker does have an easy way to establish a TCP session from the same external IP address as the victim, and an X-Forwarded-For header is inserted by a legitimate proxy server. For other products, there's sometimes a solution strategy in which X-Forwarded-For is checked only in cases where an external IP address is known to correspond to a proxy server that supplies correct X-Forwarded-For headers. However, the question here is not whether the product should have adopted that strategy or any other code change. The only immediate question is whether the http://trac.roundcube.net/changeset/4d480b36/github patch, by itself, is unambiguously introducing a vulnerability. Our initial thought is that that patch is not unambiguously introducing a vulnerability, and thus no CVE ID should be assigned. The patch seems to be a design tradeoff that is worse in many cases but better in other cases. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJTRuy8AAoJEKllVAevmvmsA7oH/j17js5nN60bjLeuK5r/hN+y o/tlWbTEGKNSS2ny0VJTEuXItRMVcUBr9sNXg7zhPo2pn2tg/90qFnd8C1NG8bVY CaLimS/tzfU559I4Xm500RPtYyaUskEr26gUoxBVfBnhG0V+7n82TOaJrojmF3ej /PAZVus6lV4qmyrsAYTJkLsB0RgMNa2znM847ncqEPpwhH9T1qP/PorFLCZ7orJ0 w8uj6chkLO083mwlSnlSK6OwZ9G1iLO/xjMwdS2SBdYpE8wEaihWXjdRqVpMSv/L rNYs2c52CKl0VF/rO97B4dgwz9ZtJIrqSFQePofRJzzdT1pblnW8Y9EDs1kSIFs= =U8Uc -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.