Underpinning the vast majority of internet connections is the Domain Name Service, or DNS. This translates textual names (like www.infoq.com) into their numeric counterparts (199.119.126.68). This is typically achieved from C code using the getaddrinfo function, which performs the translation and returns the information in a suitable data structure for subsequent connections. This function is used widely in applications and services, including performing some checks when incoming requests are made (such as mail servers using forward lookups to check for invalid hostname combinations). It may also be triggered by advertising networks injecting in images loaded from hostile servers, which can be used to transparently trigger an attack. It's a good job we all use AdBlockers, isn't it?
Google security researchers, along with RedHat and the GlibC team, have discovered a buffer overflow in the getaddrinfo function and have assigned it the identifier CVE-2015-7574). As a buffer overflow, it is potentially remotely exploitable and due to its presence in many embedded routines, from log scraping to intrusion detection, may be trivially exposed through a carefully crafted DNS response.
The problem occurs because the lookup reserves a fixed-size buffer of 2k for the DNS response, and stores this on the stack. If a DNS response larger than 2k comes in, the response can overwrite the stack, which thereby hands control over to the crafted content. Measures such as ASLR provide a level of security in these cases, but these too can be circumvented.
Any Linux system that is using GLibC 2.9 or newer is vulnerable (which are most systems since 2010; RedHat 6 and onwards) and needs to be patched urgently. The GLIbC team have provided a fix, and most Linux distributions have provided an update through their security channels which are avaialble for upgrade. Since GLibC is typcially dynamically linked, upgrading the library is sufficient; although processes that uses it will need to be restarted in order to pick up the changes. A reboot of the entire system will perform this and is the safest way, though for critical systems individual daemons can be restarted instead.
For those that can't patch immediately, disallowing larger DNS packets will provide temporary protection. Limiting response sizes of DNS packets to 512 bytes will prevent the issue from occuring, though this will break DNSSEC since this typically uses larger packets to communicate data.
Embedded firewalls may also be at risk, depending on whether they are using the GLibC implementation or not. OSX and iOS devices use BSD libraries so are not directly affected by this specific bug, although they may have other bugs. Android uses the Bionic libc library, which means that it is not subject to this specific bug (although it doesn't rule out the possibility of there being similar bugs in both BSD and Bionic libc libraries).
Anyone who manages a Linux system should immediately upgrade their version of GLibC as provided by their distribution vendor to protect themselves against the attack. Those that cannot should put in mitigating rules on the firewalls to disallow large DNS packets, such as this iptables answer from ServerFault:
-A INPUT -p udp --sport 53 -m length --length 511:65535 -j DROP
-A INPUT -p udp --dport 53 -m length --length 511:65535 -j DROP