It has been reported that a new vulnerability in glibc may be affecting some servers.
The impact of this bug is reduced significantly by the following reasons: - A patch already exists (since May 21, 2013), and has been applied and tested since glibc-2.18, released on August 12, 2013: [BZ #15014] * nss/getXXbyYY_r.c (INTERNAL (REENTRANT_NAME)) [HANDLE_DIGITS_DOTS]: Set any_service when digits-dots parsing was successful. * nss/digits_dots.c (__nss_hostname_digits_dots): Remove redundant variable declarations and reallocation of buffer when parsing as IPv6 address. Always set NSS status when called from reentrant functions. Use NETDB_INTERNAL instead of TRY_AGAIN when buffer too small. Correct computation of needed size. * nss/Makefile (tests): Add test-digits-dots. * nss/test-digits-dots.c: New test. - The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead. - Many programs, especially SUID binaries reachable locally, use gethostbyname() if, and only if, a preliminary call to inet_aton() fails. However, a subsequent call must also succeed (the "inet-aton" requirement) in order to reach the overflow: this is impossible, and such programs are therefore safe. - Most of the other programs, especially servers reachable remotely, use gethostbyname() to perform forward-confirmed reverse DNS (FCrDNS, also known as full-circle reverse DNS) checks. These programs are generally safe, because the hostname passed to gethostbyname() has normally been pre-validated by DNS software: . "a string of labels each containing up to 63 8-bit octets, separated by dots, and with a maximum total of 255 octets." This makes it impossible to satisfy the "1-KB" requirement. . Actually, glibc's DNS resolver can produce hostnames of up to (almost) 1025 characters (in case of bit-string labels, and special or non-printable characters). But this introduces backslashes ('\') and makes it impossible to satisfy the "digits-and-dots" requirement.
PowerMTA does not use the functions referenced and therefore is not vulnerable to the bug. As always, however, it is recommended that the underlying OS/architecture of the PowerMTA server be fully patched for purposes of security and to avoid any issues.