Personal tools

AusCERT Conference

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.

https://isc.sans.edu/forums/diary/CVE20157547+Critical+Vulnerability+in+glibc+getaddrinfo/20737/

Lots of Cisco kit, including many AV tools:

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160218-glibc

Actually, lots of everything, including: VMWare, Juniper, Checkpoint, Sophos, Citrix and BlueCat Networks.

https://www.reddit.com/r/networking/comments/46jfjf/cve20157547_mega_thread/

 

** 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:

https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html

 

- 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

    that overflow.

  - 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

    management flaw.

 

Frank Denis (formerly of OpenDNS) published this article, which is a bit more readable than the libc-alpha mailing list post:

 

    https://00f.net/2016/02/17/cve-2015-7547/

 

    [...]

 

    Using TCP

 

    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

    the client.

 

    [...]

 

    Using UDP

 

    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:

 

 https://lists.dns-oarc.net/pipermail/dns-operations/2016-February/014347.html

 

    > 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.

 

 https://lists.dns-oarc.net/pipermail/dns-operations/2016-February/014349.html

 

    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

  lookups.

 

* 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)."

 

http://dankaminsky.com/2016/02/20/skeleton/

 

http://dankaminsky.com/2016/02/21/ghost/

 

This is a big problem.

 

Other references:

https://www.exploit-db.com/exploits/39454/