full-disclosure - Re: Blocking WMF Files via Squid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Wed Jan  4 05:31:54 2006
From: fmargeli at sgp.gov.ar (fmargeli@....gov.ar)
Subject: Re: Blocking WMF Files via Squid

> Gaddis, Jeremy L. wrote:
>> In response to the new 0-day WMF exploit, the educational institution
>> for which I work recently took two steps to mitigate a possible
>> infection.
>
> [snip text about filtering via squid]
>
> Thanks for the comments, everyone.  While I understand that blocking
> .wmf via squid isn't exactly 100% effective, it has already stopped at
> least one box from getting hit.  Filtering .wmf seemed better than
> nothing.  It seems, also, that my ACLs are 100% effective, mainly
> because their based on:  1) file extension (.wmf), and 2) MIME types.
>
> In the description of what I did to implement this (detailed at
> http://www.jeremygaddis.com/2005/12/29/blocking-wmf-at-the-perimeter/),
> one step describes adding the following two lines in an ACL:
>
> acl blockedtyperep rep_mime_type -i ^application/x-msmetafile$
> acl blockedtyperep rep_mime_type -i application/x-msmetafile
>
> As "Sven" pointed out in a comment, it works to stop absolute URLs which
> end in .wmf, but will not stop others.  For example, it does not stop
>
> http://www.heise.de/security/dienste/browsercheck/demos/ie/wmfexp2.php.
>   Sven recommended adding the following:
>
> http_reply_access deny blockedtyperep
> http_reply_access allow all
>
> However, even this did not work because...
>
> ---
> GET /security/dienste/browsercheck/demos/ie/wmfexp2.php HTTP/1.1
> Host: www.heise.de
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8)
> Gecko/20051111 Firefox/1.5
> Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
>
> HTTP/1.1 200 OK
> Date: Tue, 03 Jan 2006 23:18:27 GMT
> Server: Apache/1.3.34
> Vary: Accept-Encoding
> Content-Disposition: inline; filename=?browsercheck.wmf?
> Content-Length: 15734
> Connection: close
> Content-Type: binary/octet-stream
> ---
>
> ...the content type returned is binary/octet-stream, which isn't
> something I can apply an ACL to in order to stop.  Is anyone aware of
> modifications that I could make to help mitigate the risk (see note
> above about the far from 100% effectiveness of this solution).  <Insert
> obligatory statement about having up-to-date AV on the desktops here>.
>
> Thanks,
> -j
>
> --
> Jeremy L. Gaddis, GCWN, Linux+, Network+
> http://www.jeremygaddis.com/
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

acl blocked_contdisp rep_header Content-Disposition -i \.wmf
http_reply_access deny blocked_contdisp
http_reply_access allow all