If you're using any reasonably well-supported distribution, you don't need the original patch itself. Most distributions would have updated libc by now, and pushed it to their repositories, and all you need to do is use the package manager to upgrade libc. (If they haven't done so by now, seriously consider switching distributions.) And this is indeed the case with Amazon Linux. From their security bulletins:
[C]ustomers using Amazon EC2 who’ve modified their configurations to
use non-AWS DNS infrastructure should update their Linux environments
immediately following directions provided by their Linux distribution.
EC2 customers using the AWS DNS infrastructure are unaffected and
don’t need to take any action.
For Amazon EC2 customers using Amazon Linux and who’ve modified their
configuration to use non-AWS DNS infrastructure:
A fix for CVE-2015-7547 has been pushed to the Amazon Linux AMI
repositories, with a severity rating of Critical. Instances launched
with the default Amazon Linux configuration on or after 2016/02/16
will automatically include the required fix for this CVE.
The patch if you want to look at it, is the part that begins with diff --git a/resolv/nss_dns/dns-host.c b/resolv/nss_dns/dns-host.c
in the email:
CVE-2015-7547
2016-02-15 Carlos O'Donell
[BZ #18665]
* resolv/nss_dns/dns-host.c (gaih_getanswer_slice): Always set
*herrno_p.
(gaih_getanswer): Document functional behviour. Return tryagain
if any result is tryagain.
* resolv/res_query.c (__libc_res_nsearch): Set buffer size to zero
when freed.
* resolv/res_send.c: Add copyright text.
(__libc_res_nsend): Document that MAXPACKET is expected.
(send_vc): Document. Remove buffer reuse.
(send_dg): Document. Remove buffer reuse. Set *thisanssizp to set the
size of the buffer. Add Dprint for truncated UDP buffer.
diff --git a/resolv/nss_dns/dns-host.c b/resolv/nss_dns/dns-host.c
index a255d5e..47cfe27 100644
--- a/resolv/nss_dns/dns-host.c
+++ b/resolv/nss_dns/dns-host.c
@@ -1031,7 +1031,10 @@ gaih_getanswer_slice (const querybuf *answer, int anslen, const char *qname,
int h_namelen = 0;
if (ancount == 0)
- return NSS_STATUS_NOTFOUND;
+ {
+ *h_errnop = HOST_NOT_FOUND;
+ return NSS_STATUS_NOTFOUND;
+ }
...
The clearest post I’ve seen on this issue is Matthew Garrett’s (including the comments).
Matthew has now released a tool to check your system locally: build it, run it with
sudo ./mei-amt-check
and it will report whether AMT is enabled and provisioned, and if it is, the firmware versions (see below). The README has more details.
To scan your network for potentially vulnerable systems, scan ports 623, 624, and 16992 to 16993 (as described in Intel’s own mitigation document); for example
nmap -p16992,16993,16994,16995,623,664 192.168.1.0/24
will scan the 192.168.1/24 network, and report the status of all hosts which respond. Being able to connect to port 623 might be a false positive (other IPMI systems use that port), but any open port from 16992 to 16995 is a very good indicator of enabled AMT (at least if they respond appropriately: with AMT, that means an HTTP response on 16992 and 16993, the latter with TLS).
If you see responses on ports 16992 or 16993, connecting to those and requesting /
using HTTP will return a response with a Server
line containing “Intel(R) Active Management Technology” on systems with AMT enabled; that same line will also contain the version of the AMT firmware in use, which can then be compared with the list given in Intel’s advisory to determine whether it’s vulnerable.
See CerberusSec’s answer for a link to a script automating the above.
There are two ways to fix the issue “properly”:
- upgrade the firmware, once your system’s manufacturer provides an update (if ever);
- avoid using the network port providing AMT, either by using a non-AMT-capable network interface on your system, or by using a USB adapter (many AMT workstations, such as C226 Xeon E3 systems with i210 network ports, have only one AMT-capable network interface — the rest are safe; note that AMT can work over wi-fi, at least on Windows, so using built-in wi-fi can also lead to compromission).
If neither of these options is available, you’re in mitigation territory. If your AMT-capable system has never been provisioned for AMT, then you’re reasonably safe; enabling AMT in that case can apparently only be done locally, and as far as I can tell requires using your system’s firmware or Windows software. If AMT is enabled, you can reboot and use the firmware to disable it (press CtrlP when the AMT message is displayed during boot).
Basically, while the privilege vulnerability is quite nasty, it seems most Intel systems aren’t actually affected. For your own systems running Linux or another Unix-like operating system, escalation probably requires physical access to the system to enable AMT in the first place. (Windows is another story.) On systems with multiple network interfaces, as pointed out by Rui F Ribeiro, you should treat AMT-capable interfaces in the same way as you’d treat any administrative interface (IPMI-capable, or the host interface for a VM hypervisor) and isolate it on an administrative network (physical or VLAN). You cannot rely on a host to protect itself: iptables
etc. are ineffective here, because AMT sees packets before the operating system does (and keeps AMT packets to itself).
VMs can complicate matters, but only in the sense that they can confuse AMT and thus produce confusing scanning results if AMT is enabled. amt-howto(7)
gives the example of Xen systems where AMT uses the address given to a DomU over DHCP, if any, which means a scan would show AMT active on the DomU, not the Dom0...
Best Answer
Answer to my question, from Qualys:
My compiled research below for anyone else looking:
Disclaimer
Despite what a lot of other threads/blogs might tell you, I suggest not to immediately update every single OS you have blindly without thoroughly testing these
glibc
updates. It has been reported that the glibc updates have caused massive application segfaults forcing people to roll back their glibc updates to their previous version.One does not simply mass-update a production environment without testing.
Background Information
GHOST is a 'buffer overflow' bug affecting the gethostbyname() and gethostbyname2() function calls in the glibc library. This vulnerability allows a remote attacker that is able to make an application call to either of these functions to execute arbitrary code with the permissions of the user running the application.
Impact
The gethostbyname() function calls are used for DNS resolving, which is a very common event. To exploit this vulnerability, an attacker must trigger a buffer overflow by supplying an invalid hostname argument to an application that performs a DNS resolution.
Current list of affected Linux distros
RHEL (Red Hat Enterprise Linux) version 5.x, 6.x and 7.x
CentOS Linux version 5.x, 6.x & 7.x
Ubuntu Linux version 10.04, 12.04 LTS
Debian Linux version 6.x, 7.x
Linux Mint version 13.0
Fedora Linux version 19 (or older should upgrade)
SUSE Linux Enterprise
openSUSE (versions older than 11 should upgrade)
What packages/applications are still using the deleted glibc?
(credits to Gilles)
For CentOS/RHEL/Fedora/Scientific Linux:
For Ubuntu/Debian Linux:
What C library (glibc) version does my Linux system use?
The easiest way to check the version number is to run the following command:
Sample outputs from RHEL/CentOS Linux v6.6:
Sample outputs from Ubuntu Linux 12.04.5 LTS:
Sample outputs from Debian Linux v7.8:
GHOST vulnerability check
The University of Chicago is hosting the below script for easy downloading:
Compile and run it as follows:
Red Hat Access Lab: GHOST toolDo not use this tool, its reporting is wrong, the Vulnerability checker from Qualys is accurate.Patching
CentOS/RHEL/Fedora/Scientific Linux
Now restart to take affect:
Alternatively, if your mirror don’t contain the newest packages, just download them manually. *note: For more advanced users
CentOS 5
CentOS 6
Ubuntu/Debian Linux
Restart:
SUSE Linux Enterprise
To install this SUSE Security Update use YaST online_update. Or use the following commands as per your version:
SUSE Linux Enterprise Software Development Kit 11 SP3
SUSE Linux Enterprise Server 11 SP3 for VMware
SUSE Linux Enterprise Server 11 SP3
SUSE Linux Enterprise Server 11 SP2 LTSS
SUSE Linux Enterprise Server 11 SP1 LTSS
SUSE Linux Enterprise Desktop 11 SP3
Finally run for all SUSE linux version to bring your system up-to-date:
OpenSUSE Linux
To see a list of available updates including glibc on a OpenSUSE Linux, enter:
To simply update installed glibc packages with their newer available versions, run:
Nearly every program running on your machine uses glibc. You need to restart every service or app that uses glibc to ensure the patch takes effect. Therefore, a reboot is recommended.
How to restart init without restarting or affecting the system?
To immediately mitigate the threat in a limited manner is by disabling reverse DNS checks in all your public facing services. For example, you can disable reverse DNS checks in SSH by setting
UseDNS
tono
in your/etc/ssh/sshd_config
.Sources (and more information):