[Info-vax] 'Kill tool' released for unpatched Apache server vulnerability

[Rich Jordan]

On Aug 25, 3:54 pm, Rich Jordan <jor... at ccs4vms.com> wrote:
> On Aug 25, 11:45 am, John Nebel <john.ne... at csdco.com> wrote:
>
>
>
> > As <http://labs.hoffmanlabs.com/node/1767> indicates, even with
> > mod_deflate shut off, the exploit will affect OpenVMS.
>
> > [root at arethusa ~]# ./kill_apache.plwww.whatever.com
> > host seems vuln
> > ATTACKING whatever [using 500 forks]
>
> > If one adds these to httpd.conf
>
> > LoadModule headers_module       modules/mod_headers.exe
> > RequestHeader unset Range
>
> > [root at arethusa ~]# ./kill_apache.plwww.whatever.com
> > Host does not seem vulnerable
>
> > SWS 2.2 update 1 and 2.1-1 update 2
>
> > John
>
> The links referenced by Hoff's entry on this point out that just
> removing the Range header can block legitimate clients and requests.
> They provide a variant that llows up to 5 ranges but it doesn't work
> on my test system, and according to the Apache docs, it can't actually
> work:
>
> Test box: OpenVMS Alpha V8.3, TCPIP V5.6 ECO 5, CSWS V2.1-1 Update 1.0
>
> # drop Range header when more than 5 ranges.
> # CVE-2011-3192
> SetEnvIf Range (,.*?){5,} bad-range=1
> RequestHeader unset Range env=bad-range
>
> With this in my virtual container definition I get the error:
>
> "header unset takes two arguments"
>
> however the docs at Apache seem to imply that with 'unset' you can
> only use one argument (the name of the header to be unset; I don't see
> a way to make the 'unset' conditional on a test or environment
> value.
>
> For the test box it doesn't matter, but for at least one customer (VMS
> I64 V8.3-1H1, same CSWS) I know I can't just drop all range request
> headers because we tested it and it broke some of their functionality.
>
> Any thoughts appreciated.
>
> In the Apache docs, the RequestHeader arguments look like this:
>
> ===========
> V2.0
> RequestHeader set|append|add|unset header [value [env=[!]variable]]
>
> If unset is used then [value] must be left out
>
> When the RequestHeader directive is used with the add, append, or set
> argument, a fourth argument may be used to specify conditions under
> which the action will be taken.   (so no mention of being able to do a
> conditional UNSET)
>
> ===========
> V2.2
> RequestHeader set|append|merge|add|unset|edit header [value]
> [replacement] [early|env=[!]variable]
>
> For unset, no value should be given.
>
> (Note there is no specific mention of the conditional being limited to
> only certain commands in this version).

I see I was looking at drafts of the response document; the final only
has the unconditional UNSET option, which isn't an option for us.
Sorry for the big post.  Curious why the Apache folks didn't make the
UNSET option conditional like they did most of the others though.