Mike Johnson wrote:
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.<>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?
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).
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.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
Aaron S. Joyner -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
