Jeff Trawick <trawick <at> gmail.com> writes: > >> Tomas Hoger tracked this down to a change to apr_uri_parse(), see here: > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=756483#c8 > >> > >> The referenced change is in APR-util version 1.2.13, so httpd is not > >> vulnerable if using APR-util 1.2.12 or older versions. > > > > Can we determine this to be errant behavior in apr_uri_parse? > > I think we can for at least a couple of these. In fact I assumed > based on the httpd 2.0 assessment pointed to earlier that the two URIs > already were rejected, and so I expected these two URIs to fail to > parse with apr-util 0.9.
These URIs do not fail to parse in older apr-util, but they are parsed in a different way. In recent versions, you get: scheme: @localhost, path: :8880 scheme: qualys, path: @qqq.qq.qualys.com This does have path not starting with / (required for the attack) and also non-NULL scheme (required to bypass "does uri start with /?" check added in r1179239). In older versions, you get: scheme: (null), path: @localhost::8880 scheme: (null), path: qualys:@qqq.qq.qualys.com With NULL scheme, there's no bypass of r1179239. AFAICS, when older apr_uri_parse() returns non-NULL scheme, path is either NULL or it starts with a /. HTH -- Tomas Hoger
