Fwd: CVE-2014-3671: DNS Reverse Lookup as a vector for the Bash vulnerability (CVE-2014-6271 et.al.)

[Dirk-Willem van Gulik <di...@webweaving.org>]

Folks,

You may have spotted below going out.

Hits us tangentially as ap_get_remote_host() gets thus populated; and it can then potentially hit a bash shell through variables set in places like ssl, setenvif, rewrote, the logger and ajp.

Though by then it is more about input sanitising. I guess one could make a case for APR to be a bit more careful with ‘wild’ reverse lookup returns. 

But then again - one should long term gravitate towards UTF8 safeness; so that would suggest that dealing with it later in the chain is better.

Dw.


find_allowdeny

> Begin forwarded message:
> 
> Date: 13 Oct 2014 12:03:26 CEST
> From: Dirk-Willem van Gulik <di...@webweaving.org>
> To: dirkx@webweaving.org
> Subject: CVE-2014-3671: DNS Reverse Lookup as a vector for the Bash vulnerability (CVE-2014-6271 et.al.)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
>                     Security Advisory 
> 
>   DNS Reverse Lookup as a vector for the Bash vulnerability (CVE-2014-6271 et.al.)
> 
>                       CVE-2014-3671
> 
> references:
>     CVE-2014-6271, CVE-2014-7169, CVE-2014-6277, CVE-2014-6278 
>     CVE-2014-7186 and, CVE-2014-7187
> 
> * Summary:
> 
> Above CVEs detail a number of flaws in bash prior related to the parsing 
> of environment variables  (aka BashBug, Shellshock). Several networked
> vectors for triggering this bug have been discovered; such as through
> dhcp options and CGI environment variables in webservers [1].
> 
> This document is to advise you of an additional vector; through a 
> reverse lookup in DNS; and where the results of this lookup are
> passed, unsanitized, to an environment variable (e.g. as part of
> a batch process). 
> 
> This vector is subtly different from a normal attack vector, as the
> attacker can 'sit back' and let a (legitimate) user trigger the
> issue; hence keeping the footprint for a IDS or WAAS to act on small.
> 
> * Resolvers/systems affected:
> 
> At this point of time the stock resolvers (in combination with the libc
> library) of OSX 10.9 (all versions) and 10.10/R2 are the only known
> standard installations that pass the bash exploit string back and
> up to getnameinfo(). 
> 
> That means that UNpatched systems are vulnerable through this vector
> PRIOR to the bash update documented in http://support.apple.com/kb/DL1769.
> 
> Most other OS-es (e.g. RHEL6, Centos, FreeBSD 7 and up, seem 
> unaffected in their stock install as libc/libresolver and DNS use 
> different escaping mechanisms (octal v.s. decimal).
> 
> We're currently following investing a number of async DNS resolvers
> that are commonly used in DB cache/speed optimising products and
> application level/embedded firewall systems.
> 
> Versions affected: 
> 
> See above CVEs as your primary source.
> 
> * Resolution and Mitigation:
> 
> In addition to the mitigations listed in above CVEs - IDSes and similar 
> systems may be configured to parse DNS traffic in order to spot the 
> offending strings.
> 
> Also note that Apple DL1769 addresses the Bash issue; NOT the vector
> through the resolver. 
> 
> * Reproducing the flaw:
> 
> A simple zone file; such as:
> 
>     $TTL 10;
>     $ORIGIN in-addr.arpa.
>     @     IN SOA     ns.boem.wleiden.net dirkx.webweaving.org (
>                    666        ; serial
>                    360 180 3600 1800 ; very short lifespan.
>                    )
>     IN          NS     127.0.0.1
>     *           PTR      "() { :;}; echo CVE-2014-6271, CVE-201407169, RDNS" 
> 
> can be used to create an environment in which to test the issue with existing code
> or with the following trivial example:
> 
>    #include <sys/socket.h>
>    #include <netdb.h>
>    #include <assert.h>
>    #include <arpa/inet.h>
>    #include <stdio.h>
>    #include <stdlib.h>
>    #include <unistd.h>
>    #include <netinet/in.h>
> 
>    int main(int argc, char ** argv) {
>     struct in_addr addr;
>     struct sockaddr_in sa;
>     char host[1024];
> 
>     assert(argc==2);
>     assert(inet_aton(argv[1],&addr) == 1);
> 
>     sa.sin_family = AF_INET;
>     sa.sin_addr = addr;
> 
>     assert(0==getnameinfo((struct sockaddr *)&sa, sizeof sa,
>          host, sizeof host, NULL, 0, NI_NAMEREQD));
> 
>     printf("Lookup result: %s\n\n", host);    
> 
>     assert(setenv("REMOTE_HOST",host,1) == 0);
>     execl("/bin/bash",NULL);
>    }
> 
> 
> Credits and timeline
> 
> The flaw was found and reported by Stephane Chazelas (see CVE-2014-6271
> for details).  Dirk-Willem van Gulik (dirkx(at)webweaving.org) found
> the DNS reverse lookup vector.
> 
> 09-04-2011     first reported.
> 2011, 2014     issue verified on various embedded/firewall/waas
>               systems and reported to vendors. 
> ??-09-2014     Apple specific exploited seen.
> 11-10-2014     Apple confirms that with DL1769 in place that
>               "The issue that remains, while it raises 
>               interesting questions, is not a security 
>               issue in and of itself."
> 
> * Common Vulnerability Scoring (Version 2) and vector:
> 
> See CVE-2014-6271.
> 
> 1:https://github.com/mubix/shellshocker-pocs/blob/master/README.md)
> 1.10 / : 1726 $
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: This message is encrypted and/or signed with PGP (gnu-pg, gpg). Contact dirkx@webweaving.org if you cannot read it.
> 
> iQCVAwUBVDujZDGmPZbsFAuBAQLI7AQAmYwSRs64f7TEpA2qworBb4ozKDCGMyhd
> xlmZ5W/iAL8uFdtt0Or6tjo1QfnbjAq2x8r/PJtl+O5DyEDDDWAYizz7Ts9u1NOH
> B9k3xNwy/7OmEloRaCaTZFxDPnqsAoQIIWEcemEJ8ZQq2JOW9dZJ59Mf8i8W2ujJ
> 4c9Wd1S7vPE=
> =OOB5
> -----END PGP SIGNATURE-----
>