[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
