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: di...@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 di...@webweaving.org if you cannot read it. > > iQCVAwUBVDujZDGmPZbsFAuBAQLI7AQAmYwSRs64f7TEpA2qworBb4ozKDCGMyhd > xlmZ5W/iAL8uFdtt0Or6tjo1QfnbjAq2x8r/PJtl+O5DyEDDDWAYizz7Ts9u1NOH > B9k3xNwy/7OmEloRaCaTZFxDPnqsAoQIIWEcemEJ8ZQq2JOW9dZJ59Mf8i8W2ujJ > 4c9Wd1S7vPE= > =OOB5 > -----END PGP SIGNATURE----- >