Quote:
Originally Posted by andrewthomas
Looking it over, not seeing much to be concerned about here.
|
I don't think you need to stock up on canned tuna and move to Montana just yet. That said, when the costs of correction are small, I can't
think of an intelligent reason to choose more vulnerable over less.
These glibc vulerabilities vary in risk severity (don't they all?) but since I was investing time to do the audit in the first place I preferred to be
comprehensive and take care of all outstanding CVEs (including lesser threats).
Let me explain them a bit because your one-liners are misleading.
- CVE-2013-4788: Pointer encryption (or mangling) was implemented in glibc at the end of 2005 yet never properly initialized pointer guards
during static compiles making the calculation of target addresses trivial for an attacker. The fix doesn't introduce a new hardening feature;
it corrects a broken feature many have relied on for the past 8 years.
- CVE-2013-4237: Your comment about powerpc architectures seems to have come from here and you'll have to ask Jamie what he meant.
However, all that's required to trigger this on Linux is for an attacker to craft an fs response in excess of NAME_MAX (eg malicious CIFS
network message).
- CVE-2013-4458 Your description is incomplete. The vulnerability exists in the getaddrinfo code-path and can be triggered by an attacker
that either has access to the hosts file or controls a DNS zone. For example, here getaddrinfo performs an IPv6 DNS lookup of
ipv6.test-ipv6.com:
Code:
/* Copyright 0x7dd by mancha */
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
int main(void)
{
struct addrinfo *result;
struct sockaddr_in6 addr;
char ip[46];
if (getaddrinfo("ipv6.test-ipv6.com", NULL, NULL, &result)) { exit(1); }
addr.sin6_addr = ((struct sockaddr_in6 *)result->ai_addr)->sin6_addr;
inet_ntop(result->ai_family, &(addr.sin6_addr), ip, sizeof ip);
printf("ip: %s\n", ip);
}
--mancha
