Great, thank you for answers Mark. Much appreciated!
On Thursday, October 5, 2017, 3:29:04 PM CDT, Mark Thomas
<ma...@apache.org> wrote:
On 05/10/17 20:35, Justin wrote:
> Hi all,
> I'm curious about the severity of CVE-2016-6816 fixed last November.
> http://svn.apache.org/viewvc?view=revision&revision=1767653
>
> I see that vendors backported this fix (over time).
> http://www.securitytracker.com/id/1037332
> Severity is described as Important, Moderate, CVSS v2 Medium, and CVSS v3
> High.
> "A remote user can exploit this to spoof content on the target server,
> attempt to poison any intermediate web caches, or conduct cross-site
> scripting attacks."
> This sounds pretty serious. If my server is running a vulnerable version of
> Tomcat, how easy is it to exploit?
I'm not going to go into the details of exactly how to exploit this
issue but the answer to your question is pretty difficult.
1. You need to be running Tomcat behind a reverse proxy of some form.
2. That reverse proxy needs to accept the same invalid requests as
Tomcat (it should reject them with a 400 response).
3. The attacker needs to be able to either upload arbitrary static
content which they can then request or formulate a request in such a
way that arbitrary content is injected into the response.
1 is very common. 2 is possible but I haven't seen any evidence of it
for these particular invalid requests. 3 is (very) unlikely.
Overall, I'd judge the chances of all of these lining up on any given
system as low to very low. It is one of those where the chances of it
happening are low but the impact if it does happen is high. You could
argue rating of Low, Moderate or High for this on Tomcat's scale. It is
very much a judgement call. Where there is uncertainty over the
likelihood then we tend to err on the side of caution.
> Must webapps use cookies as some example exploits have shown?
No.
> "By manipulating the HTTP response the attacker could... obtain sensitive
> information from requests other then their own." So if trusted users are
> logging in, untrusted users could obtain passwords? Path or query parameters?
Untrusted users could obtain anything from the response intended for a
trusted user. Passwords are therefore unlikely, as is anything on the
request side unless the application is echoing that data back to the
client. Session cookies are probably the most likely target.
HTH,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
