[Snort-sigs] Apache mod_rewrite off-by-one sig
jhart at ...288...
Tue Aug 1 12:33:58 EDT 2006
On Mon, Jul 31, 2006 at 07:53:02PM -0700, Jon Hart wrote:
> I can't. The way I understand the prerequisites of the vulnerability is
> that you have to have a rewrite rule similar to:
> RewriteRule ^/blah(.*) $1/some/stuff/that/doesntmatter/
> I actually can't think of any good reason to give a user control over
> the very first part of the rewrite target, but alas, there may be a good
> reason and there are plenty of bad rewrite rules out there.
> That said, the exploit for this particular vulnerability depends
> entirely on the RewriteRule being attacked, so the best we can hope for
> is looking for ldap:// in the uri. Actually, I suppose it is possible
> that the exploit could come not in the form of a URI, but really
> anywhere in the request as mod_rewrite can base its actions on damn near
The background here is that the vulnerability occurs in
escape_absolute_uri() of mod_rewrite. It is only triggered if the uri
begins with 'ldap' (translation: is an ldap uri). The two cases where
this is possible are:
1) The rewrite target as written in the apache config begins with
'ldap'. Possible, but very rare IMO.
2) The beginning of the rewrite target is controlled by the attacker,
such as the example I gave in my previous email. In that case, if
I went to http://example.com/blahldap://foobar/dn?uid=adfadf, the
rewrite target would be ldap://foobar/dn?uid=adfadf.
As I understand it, the off-by-one occurs in the portion of the code
that attempts to strip out the attribute tokens from the fully-qualified
ldap uri. Normally, this would take the first four chunks of
"?attribute=value" pairs, but in this case it takes 5. I think the
following lwp request is a start down the right path:
GET -sSued 'localhost/ldap://blah/dn'`perl -e 'print
So, in terms of the rule, an attack will definitely include "ldap://",
four "?attribute=value" pairs, followed by the fifth malicious one.
I could be completely misreading the code or misunderstanding the
vulnerability here. But I haven't seen any other information as of yet.
More information about the Snort-sigs