The annual AusCERT conference is Australia's best cyber security event for anyone with an interest in cyber and information security.
AusCERT PKI certificate service
The AusCERT Certificate Service offers PKI certificates for people, servers and software for Australian and New Zealand education and research organisations.
AusCERT Vision & Mission Statement
AusCERT is the trusted cyber emergency response team for the Australian information economy, providing valued incident prevention and detection.
A New Skeleton Key
We've been busy lately, patching our machines against the Linux glibc CVE-2015-7547 vulnerability. It's a particularly nasty vulnerability, as it affects any software that communicates with DNS, including all the likely suspects but also such unlikely candidates as sudo. Simply put, if you run any Linux-based platform or device, you're probably affected. So, what do we know about it, so far?
** What is vulnerable?
Red Hat Enterprise Linux 6/7 and related, Debian squeeze/wheezy/jessie and related, most anything else Linux/embedded running glibc after 2.9 are vulnerable. Version 2.9 was introduced in May 2008.
Lots of Cisco kit, including many AV tools:
Actually, lots of everything, including: VMWare, Juniper, Checkpoint, Sophos, Citrix and BlueCat Networks.
** Not vulnerable:
BSD based things including OSX and related appliances.
*** DNS resolvers allowing the malicious requests through
The other side of the coin is the dns resolvers themselves, which can allow the malicious requests through for all devices/hosts that use them.
My understanding at the moment: there is a very high possibility that even using trusted resolvers from firewalled machines that don’t do direct dns lookups is not going to help overly much, patching glibc seems to be the way forward here.
This from the glibc patch:
- Mitigating factors for UDP include:
- A firewall that drops UDP DNS packets > 512 bytes.
- A local resolver (that drops non-compliant responses).
- Avoid dual A and AAAA queries (avoids buffer management error) e.g.
Do not use AF_UNSPEC.
- No use of `options edns0` in /etc/resolv.conf since EDNS0 allows
responses larger than 512 bytes and can lead to valid DNS responses
- No use of `RES_USE_EDNS0` or `RES_USE_DNSSEC` since they can both
lead to valid large EDNS0-based DNS responses that can overflow.
- Mitigating factors for TCP include:
- Limit all replies to 1024 bytes.
- Mitigations that don't work:
- Setting `options single-request` does not change buffer management
and does not prevent the exploit.
- Setting `options single-request-reopen` does not change buffer
management and does not prevent the exploit.
- Disabling IPv6 does not disable AAAA queries. The use of AF_UNSPEC
unconditionally enables the dual query.
- The use of `sysctl -w net.ipv6.conf.all.disable_ipv6=1` will not
protect your system from the exploit.
- Blocking IPv6 at a local or intermediate resolver does not work to
prevent the exploit. The exploit payload can be delivered in A or
AAAA results, it is the parallel query that triggers the buffer
Frank Denis (formerly of OpenDNS) published this article, which is a bit more readable than the libc-alpha mailing list post:
Using TCP requires closing the connection or sending invalid, short
responses. No matter the responses it is receiving or forwarding, a
recursive server is very unlikely to ever have this behavior. So, the
only realistic way to exploit this vulnerability using TCP is by a
man-in-the-middle, namely an active attacker between the resolver and
According to the advisory, it takes 3 specially-crafted UDP responses to
exploit the vulnerability: one being a valid 2048-bytes long responses,
one triggering a retry, and a last one being larger than 2048 bytes,
smashing random things on the stack for fun and profit.
Florian Weimer (one of the glibc maintainers) wrote this on the dns-operations mailing list:
> Are you or anyone else aware of further research whether an attacker
> could penetrate the major caching resolver implementations?
I'm hesistant to name specific implementations publicly (because it
could be construed as blaming glibc's exposure on them). But we have
encountered one implementation which does close TCP connections
without sending responses in an overload situation.
The relevant TCP behavior is hop-by-hop, and as such it is influenced
by middleboxes and their connection and state management. This makes
it difficult to make accurate statements without detailed knowledge of
the network of interest.
Yes, that's exactly what I thought when reading the original bug
report. It is the main reason why I de-prioritized it. I finally
got around writing a reproducer for the UDP case, and Carlos noticed
the TCP vector while fixing the UDP bug.
It sounds like the TCP path to exploitation is more important than the UDP path, because the UDP path is effectively mitigated by the stub resolver / Linux distro defaults. (I don't think there's any Linux distro that enables "options edns0" in /etc/resolv.conf by default. And folks who *do* want EDNS0/DNSSEC on the end machine are likely to install a local full-service resolver and point the stub resolver to that local daemon.)
One thing that was glossed over in the original Google blog post was this statement:
Remote code execution is possible, but not straightforward. It
requires bypassing the security mitigations present on the system,
such as ASLR. We will not release our exploit code, but a
non-weaponized Proof of Concept has been made available
simultaneously with this blog post.
IIUC, ASLR bypasses are probabilistic, and the more entropy the better (which is another good reason to prefer 64-bit to 32-bit for x86 hardware). So it sounds like the most successful exploitation scenario is going to be something like:
* The attacker can force the victim stub resolver machine to do multiple
* The attacker can force the victim stub resolver machine to perform
lookups for arbitrary, attacker-controlled zones.
* The attacker can perform some sort of DoS/overload attack against the
full-service resolver that the victim stub resolver machine relies on,
in order to induce the exact pattern of TCP reset/disconnect behavior
needed to reach the vulnerable code path in the stub resolver.
That makes me think that the most critical machines to protect are things like mail servers, not fresh network installs of Linux distros.
Dan Kaminsky, the same fellow that discovered and has a DNS poisoning attack named after himself had this to day: "Ghost was actually a really “fiddly” bug, in a way CVE-2015-7547 just isn’t." It seems even with ASLR in place mitigating, all that's required it to attempt the vuln multiple times and an exploit may be successful.
He also said: "TL;DR: The glibc DNS bug (CVE-2015-7547) is unusually bad.
Even Shellshock and Heartbleed tended to affect things we knew were on the network and knew we had to defend. This affects a universally used library
(glibc) at a universally used protocol (DNS)."
This is a big problem.