[TriLUG] I want to build an HTTP Proxy for Home

Aaron S. Joyner aaron at joyner.ws
Mon Aug 2 15:31:10 EDT 2004


Mike Johnson wrote:

> <>Yes. The null byte has to occur in the path on the server, not in the
> name itself. The specific instance I was looking into was bypassing
> wildcard blocks. For instance, a filter denying access to a URL with
> the word 'nude' in the path:
> http://www.example.com/nude.jpg
> That was blocked by the wildcard in place. However:
> http://www.example.com/%00nude.jpg
> would allow me access to the naughty jpg.
>
>Do y'all use wildcard filters, such as the example I gave above?  If so,
>is the example I gave above blocked?
>  
>
First off: We don't use many 'expression' based filters (regex filters), 
as squidGuard likes to call them - because we've found they can cause a 
lot of false positives if not very carefully written.  And if tightly 
controlled, they don't match very much that the domain and url based 
filters do not.

So I had to craft a bit of a synthetic example, but yes squidGuard is 
still vulnerable to this type of attack.  Observe that 
http://example.com/ourregexfilter is blocked, but 
http://example.com/%00ourregexfilter is not blocked and returns a 404 
(because obviously no such file exists at example.com).

>Please understand that I was not trying to say 'squidguard is useless
>because it can't protect against X'.  I was truely asking if there was a
>solution for the problem.  I am not implementing this for myself, but
>helping someone else.  And yes, I'm being deliberatly vague about the
>environment I'm dealing with.
>
>Mike
>  
>
Since squidGuard uses the ASCII null internally to determine the end of 
it's strings (it's written in C), a work around would be tricky, at 
best.  I'm looking it over and pondering it w/ a friend who does more C 
than I do, and I'll post something to the list if I come up w/ a silver 
bullet.

Aaron S. Joyner



More information about the TriLUG mailing list