and On 14/09/2016 00:52, Greg Wilkins wrote:
>
> On 13 September 2016 at 19:09, Mark Thomas <markt_at_apache.org
> <mailto:markt_at_apache.org>> wrote:
>
> The most notable problem we had in Tomcat when we started providing the
> original, undecoded, unnormalized value for
> HttpServletRequest#getContextPath() was with applications that were
> using this to make security decisions. Those applications were assuming
> that a decoded, normalized value would be returned and they broke badly
> (i.e the security constraints were bypassed) when Tomcat started
> following the spec.
I've been back through my inbox and I was getting my security related
encoding issues mixed up. The ones I was thinking of were a) path
related and b) for some other open source products I'm involved in.
There were rather more issues related to
HttpServletRequest#getContextPath() than I first recalled, but they were
all breakages of the "stuff stopped working" form rather than any
constraints being bypassed.
> You'd hope that with this spec being the age it is, this kind of
> security issue will be less and less a problem, but it is still a
> non-zero possibility of future spec induced security issues.
>
> I'm wondering if we should have a private forum for the servlet-spec
> where we can raise such problems that may be cross container and jointly
> come up with a response.
>
> Or perhaps the current CVE/CERT style mechanisms should be enough... but
> obviously they did not trigger in this instance? Or perhaps they did
> but Jetty was not notified because we didn't comply with the spec?
> Was a CVE raised for this vulnerability? Should it have been as
> potentially all spec compliant containers were vulnerable?
They didn't trigger for Tomcat because the issues I was thinking of were
for other open source products (where they did trigger and were not
container related).
That said, it is useful to consider what might have happened had we had
a serious security issue reported to Tomcat. The sequence probably would
have gone line this:
Actual sequence:
a) Bug reported to Tomcat that HttpServletRequest#getContextPath() is
decoded
b) Bug fixed
c) Additional bug reported that /../ sequences etc cause
HttpServletRequest#getContextPath() to return an incorrect value
d) Additional bug fixed
e) Users report breakage (404s) due to
HttpServletRequest#getContextPath() now being encoded
f) Users informed their apps aren't spec compliant and that they need
to fix their apps
Hypothetical from here onwards:
g) User reports security issue due to
HttpServletRequest#getContextPath() now being encoded
h) User informed their app is not spec complaint and therefore the
vulnerability is in their application
i) CVE issued for user's application
When the Tomcat community receives a spec compliance bug and the spec
violation is clear, as it was in this case, the working assumption is
that this is a mistake made by the Tomcat community. Checking the
behaviour of other implementations isn't on the radar in this case.
If the spec is unclear, that is when we start looking at the EG
archives, other containers etc.
If the user tries the "But it works on XXX" defence, the response
probably would have been "Then XXX is not spec compliant, you should
raise a bug".
I think the lesson here is whenever one of us has a spec compliance bug
that could have security implications then it would be useful to have a
venue to notify the other EG members so that they can check their
compliance with the spec. The hard part will be assessing the "could
have security implications" bit.
Mark