Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
4 added 105 characters in body
source | link

The CVE details site keeps track of vendor details for vulnerabilities, it's not upup yet but it should appear shortly here fully complete yet but, you can find it should appear shortly at here: http://www.cvedetails.com/cve/CVE-2015-0235/ (see the recent Shellshock CVE-2014-7169 page for example). The oss-sec email list is a good way to keep track of breaking news.

This non-trivial exploitation of the vulnerability is explained in detail in the advisory, take the example of the (not-exploitable) mount.nfs in §4.2 : a setuid-root binary on most distributions, so a good opportunity for local privilege escalation:

This is how OpenSSH uses those functions also, see the wrapper getaddrinfo() in openbsd-compat/fake-rfc25553.c. That function is only enabled at compile time if the host has no native getaddrinfo() (or you fudge configure to fool it). glibc has had that function since 1996 (pre v2.0), so gethostbyname() won't be called by OpenSSH. 

If your OpenSSH is built with libwrap, then the sshd binary will have some unresolved symbolssymbol dependencies for gethostbyname* because of that — Qualys claim both TCP wrappers and OpenSSH are safe (for now). The only other use of gethostbyname() in OpenSSH is in HP-UX specific code where the X DISPLAY need contain an IP rather than a hostname, not relevant here.

In the general case, since conforming DNS data cannot contain problematic long/malformed IP addresses, reverse look up and forward/reverse checks are not an attack vector. Where hostnames/dotted-quad addresses are part of a higher protocol (e.g. the SMTP EHLO name, as used exploiting Exim) then you might have something. For OpenSSH this would suggest host names in port-forwarding, close. Close, but no cigar, even if OpenSSH did use gethostbyname() directly:

where NI_MAXHOST is 1025 in versions I've checked so far. and thisThis would be a less severe post-authentication attack vector in any case.

The CVE details site keeps track of vendor details for vulnerabilities, it's not up yet but it should appear shortly at here: http://www.cvedetails.com/cve/CVE-2015-0235/ (see the recent Shellshock CVE-2014-7169 page for example). The oss-sec email list is a good way to keep track of breaking news.

This non-trivial exploitation of the vulnerability is explained in detail in the advisory, take the example of mount.nfs in §4.2 : a setuid-root binary on most distributions, so a good opportunity for local privilege escalation:

This is how OpenSSH uses those functions also, see the wrapper getaddrinfo() in openbsd-compat/fake-rfc25553.c. That function is only enabled at compile time if the host has no native getaddrinfo() (or you fudge configure to fool it). glibc has had that function since 1996 (pre v2.0), so gethostbyname() won't be called by OpenSSH. If your OpenSSH is built with libwrap, then the sshd will have some unresolved symbols for gethostbyname* because of that — Qualys claim both TCP wrappers and OpenSSH are safe (for now). The only other use of gethostbyname() in OpenSSH is in HP-UX specific code where the X DISPLAY need contain an IP rather than a hostname, not relevant here.

In the general case, since conforming DNS data cannot contain problematic long/malformed IP addresses, reverse look up and forward/reverse checks are not an attack vector. Where hostnames/dotted-quad addresses are part of a higher protocol (e.g. the SMTP EHLO name, as used exploiting Exim) then you might have something. For OpenSSH this would suggest host names in port-forwarding, close, but no cigar even if OpenSSH did use gethostbyname() directly:

where NI_MAXHOST is 1025 in versions I've checked so far. and this would be a post-authentication vector in any case.

The CVE details site keeps track of vendor details for vulnerabilities, it's not up yet but it should appear shortly here fully complete yet, you can find it here: http://www.cvedetails.com/cve/CVE-2015-0235/ (see the recent Shellshock CVE-2014-7169 page for example). The oss-sec email list is a good way to keep track of breaking news.

This non-trivial exploitation of the vulnerability is explained in detail in the advisory, take the example of the (not-exploitable) mount.nfs in §4.2 : a setuid-root binary on most distributions, so a good opportunity for local privilege escalation:

This is how OpenSSH uses those functions also, see the wrapper getaddrinfo() in openbsd-compat/fake-rfc25553.c. That function is only enabled at compile time if the host has no native getaddrinfo() (or you fudge configure to fool it). glibc has had that function since 1996 (pre v2.0), so gethostbyname() won't be called by OpenSSH. 

If your OpenSSH is built with libwrap, then the sshd binary will have some symbol dependencies for gethostbyname* because of that — Qualys claim both TCP wrappers and OpenSSH are safe (for now). The only other use of gethostbyname() in OpenSSH is in HP-UX specific code where the X DISPLAY need contain an IP rather than a hostname, not relevant here.

In the general case, since conforming DNS data cannot contain problematic long/malformed IP addresses, reverse look up and forward/reverse checks are not an attack vector. Where hostnames/dotted-quad addresses are part of a higher protocol (e.g. the SMTP EHLO name, as used exploiting Exim) then you might have something. For OpenSSH this would suggest host names in port-forwarding. Close, but no cigar, even if OpenSSH did use gethostbyname() directly:

where NI_MAXHOST is 1025 in versions I've checked so far. This would be a less severe post-authentication attack vector in any case.

3 typo/braino/wording
source | link

One can reasonably conclude (see below) that it will require some detailed analysis to determine if an arbitrary software package is vulnerable, and what configuration or mitigations may apply. Any service which performs name resolution could be at risk (patch, and be safe!).

The CVE details site keeps track of vendor details for vulnerabilities, it's not up yet but it should appear shortly at here: http://www.cvedetails.com/cve/CVE-2015-0235/ (see the recent Shellshock CVE-2014-7169 page for example). The oss-sec mailingemail list is a good way to keep track of breaking informationnews.

(I don't buy the OpenSSH "mitigation" linked to, useDNSUseDNS doescauses a reverse look up of the IP address of the TCP connection, which of course cannot be sufficiently controlled by the attacker. I'll update this when I have a chance to verify the steps taken. Reverse DNS in OpenSSH or OpenSSH+libwrap is not exploitable.)

Because of common programming idioms, and the very specific code paths to the vulnerable code, many programs are not vulnerable. To be clear, there is a problem inaffecting a specific handful of DNS related functions in glibc(<2.18), and DNS is an excellent way to get attacker controlled data into a system, though it's not a great way to get arbitrary data in. But, unlike some recent high profile issues, simply using the library or using those functions does not automatically make a program vulnerable.

That said, this is a newly publicised issue, other ways to trigger the issue may be found, thisthere is not anno excuse to put off patching. The gethostbyname* functions in question are considered "obsolete" since they do not support IPv6 notations and have been replacereplaced by functions that do, but they are very prevalent.

The above calling pattern of inet_aton() thenbefore trying gethostbyname() is the common idiom I was referringreferred to above. Given an arbitrary string in hostname, first check to see if it can be treated as a valid IP dotted-quad via inet_aton() (cheap, and low-latency), otherwise see if it is a DNS host name via gethostbyname() (not cheap, and potentially high-latency. See section 3 - Mitigating factors of the advisory.

This is how OpenSSH uses those functions also, see the wrapper getaddrinfo() in openbsd-compat/fake-rfc25553.c. That function is only enabled at compile time if the host has no native getaddrinfo() (or you fudge configure to fool it). glibc has had that function since 1996 (pre v2.0), so gethostbyname() won't be called by OpenSSH. If your OpenSSH is built with libwrap, then the sshd will have some unresolved symbols for gethostbyname* because of that — Qualys claim both TCP wrappers and OpenSSH are safe (for now). The only other use of gethostbyname() in OpenSSH is onin HP-specificUX specific code where the X DISPLAYDISPLAY need contain an IP rather than a hostname, not relevant here.

One can reasonably conclude (see below) that it will require some detailed analysis to determine if an arbitrary software package is vulnerable, and what configuration or mitigations may apply. Any service which performs name resolution could be at risk.

The CVE details site keeps track of vendor details for vulnerabilities, it's not up yet but it should appear shortly at here: http://www.cvedetails.com/cve/CVE-2015-0235/ (see the recent Shellshock CVE-2014-7169 page for example). The oss-sec mailing list is a good way to keep track of breaking information.

(I don't buy the OpenSSH "mitigation" linked to, useDNS does a reverse look up of the IP address of the TCP connection, which of course cannot be sufficiently controlled by the attacker. I'll update this when I have a chance to verify the steps taken. Reverse DNS in OpenSSH or OpenSSH+libwrap is not exploitable.)

Because of common programming idioms, and the very specific code paths to the vulnerable code, many programs are not vulnerable. To be clear, there is a problem in a specific handful of DNS related functions in glibc, and DNS is an excellent way to get attacker controlled data into a system, though it's not a great way to get arbitrary data in. But, unlike some recent high profile issues, simply using the library or using those functions does not automatically make a program vulnerable.

That said, this is a newly publicised issue, other ways to trigger the issue may be found, this is not an excuse to put off patching. The functions in question are considered "obsolete" since they do not support IPv6 notations and have been replace by functions that do, but they are very prevalent.

The above calling pattern of inet_aton() then gethostbyname() is the common idiom I was referring to. Given an arbitrary string in hostname, first check to see if it can be treated as a valid IP dotted-quad via inet_aton() (cheap, and low-latency), otherwise see if it is a DNS host name via gethostbyname() (not cheap, and potentially high-latency. See section 3 - Mitigating factors of the advisory.

This is how OpenSSH uses those functions also, see the wrapper getaddrinfo() in openbsd-compat/fake-rfc25553.c. That function is only enabled at compile time if the host has no native getaddrinfo() (or you fudge configure to fool it). glibc has had that function since 1996 (pre v2.0), so gethostbyname() won't be called by OpenSSH. If your OpenSSH is built with libwrap, then the sshd will have some unresolved symbols for gethostbyname* because of that — Qualys claim both TCP wrappers and OpenSSH are safe (for now). The only other use of gethostbyname() in OpenSSH is on HP-specific code where the X DISPLAY need contain an IP rather than a hostname, not relevant here.

One can reasonably conclude (see below) that it will require some detailed analysis to determine if an arbitrary software package is vulnerable, and what configuration or mitigations may apply. Any service which performs name resolution could be at risk (patch, and be safe!).

The CVE details site keeps track of vendor details for vulnerabilities, it's not up yet but it should appear shortly at here: http://www.cvedetails.com/cve/CVE-2015-0235/ (see the recent Shellshock CVE-2014-7169 page for example). The oss-sec email list is a good way to keep track of breaking news.

(I don't buy the OpenSSH "mitigation" linked to, UseDNS causes a reverse look up of the IP address of the TCP connection, which of course cannot be sufficiently controlled by the attacker. I'll update this when I have a chance to verify the steps taken. Reverse DNS in OpenSSH or OpenSSH+libwrap is not exploitable.)

Because of common programming idioms, and the very specific code paths to the vulnerable code, many programs are not vulnerable. To be clear, there is a problem affecting a handful of DNS related functions in glibc(<2.18), and DNS is an excellent way to get attacker controlled data into a system, though it's not a great way to get arbitrary data in. But, unlike some recent high profile issues, simply using the library or using those functions does not automatically make a program vulnerable.

That said, this is a newly publicised issue, other ways to trigger the issue may be found, there is no excuse to put off patching. The gethostbyname* functions in question are considered "obsolete" since they do not support IPv6 notations and have been replaced by functions that do, but they are very prevalent.

The above calling pattern of inet_aton() before trying gethostbyname() is the common idiom referred to above. Given an arbitrary string in hostname, first check to see if it can be treated as a valid IP dotted-quad via inet_aton() (cheap, and low-latency), otherwise see if it is a DNS host name via gethostbyname() (not cheap, and potentially high-latency. See section 3 - Mitigating factors of the advisory.

This is how OpenSSH uses those functions also, see the wrapper getaddrinfo() in openbsd-compat/fake-rfc25553.c. That function is only enabled at compile time if the host has no native getaddrinfo() (or you fudge configure to fool it). glibc has had that function since 1996 (pre v2.0), so gethostbyname() won't be called by OpenSSH. If your OpenSSH is built with libwrap, then the sshd will have some unresolved symbols for gethostbyname* because of that — Qualys claim both TCP wrappers and OpenSSH are safe (for now). The only other use of gethostbyname() in OpenSSH is in HP-UX specific code where the X DISPLAY need contain an IP rather than a hostname, not relevant here.

2 added 1581 characters in body
source | link

One can reasonably conclude (see below) that it will require some detailed analysis to determine if an arbitrary software package is vulnerable, and what configuration or mitigations may apply. Qualys Any service which performs name resolution could be at risk.

Qualys have already provided a list of software using the affected functions which they cannot exploit at this time:

Right now, only Exim is confirmed exploitable.

(I don't buy the OpenSSH "mitigation" linked to, useDNS does a reverse look up of the IP address of the TCP connection, which of course cannot be sufficiently controlled by the attacker. I'll update this when I have a chance to verify the steps takenI'll update this when I have a chance to verify the steps taken. Reverse DNS in OpenSSH or OpenSSH+libwrap is not exploitable.)

Because of common programming idioms, and the very specific code paths to the vulnerable code, many programs are not vulnerable. To be clear, there is a problem in a specific handful of DNS related functions in glibc, and DNS is an excellent way to get attacker controlled data into a system, though it's not a great way to get arbitrary data in. But, unlike some recent high profile issues, simply using the library or using those functions does not automatically make the codea program vulnerable.

This non-trivial exposure to this issue isexploitation of the vulnerability is explained in detail in the advisory, take the example of mount.nfs in §4.2 : a setuid-root binary on most distributions, so a good opportunity for local privilege escalation:

The above calling pattern of inet_aton() then gethostbyname() is the common idiom I was referring to. Given an arbitrary string in hostname, first check to see if it can be treated as a valid IP dotted-quad via inet_aton() (cheap, and low-latency), otherwise see if it is a DNS host name via gethostbyname() (not cheap, and potentially high-latency. See section 3 - Mitigating factors of the advisory.

This is how OpenSSH uses those functions also, see the wrapper getaddrinfo() in openbsd-compat/fake-rfc25553.c. That function is only enabled at compile time if the host has no native getaddrinfo() (or you fudge configure to fool it). glibc has had that function since 1996 (pre v2.0), so gethostbyname() won't be called by OpenSSH. If your OpenSSH is built with libwrap, then the sshd will have some unresolved symbols for gethostbyname* because of that — Qualys claim both TCP wrappers and OpenSSH are safe (for now). The only other use of gethostbyname() in OpenSSH is on HP-specific code where the X DISPLAY need contain an IP rather than a hostname, not relevant here.

In the general case, since conforming DNS data cannot contain problematic long/malformed IP addresses, reverse look up and forward/reverse checks are not an attack vector. Where hostnames/dotted-quad addresses are part of a higher protocol (e.g. the SMTP EHLO name, as used exploiting Exim) then you might have something. For OpenSSH this would suggest host names in port-forwarding, close, but no cigar even if OpenSSH did use gethostbyname() directly:

      if (strlen(host) >= NI_MAXHOST) {
            error("Forward host name too long.");
            return 0;
      }

where NI_MAXHOST is 1025 in versions I've checked so far. and this would be a post-authentication vector in any case.

One can reasonably conclude (see below) that it will require some detailed analysis to determine if an arbitrary software package is vulnerable, and what configuration or mitigations may apply. Qualys have already provided a list of software using the affected functions which they cannot exploit at this time:

Right now, only Exim is confirmed.

(I don't buy the OpenSSH "mitigation" linked to, useDNS does a reverse look up of the IP address of the TCP connection, which of course cannot be sufficiently controlled by the attacker. I'll update this when I have a chance to verify the steps taken.)

Because of common programming idioms, and the very specific code paths to the vulnerable code, many programs are not vulnerable. To be clear, there is a problem in a specific handful of DNS related functions in glibc, and DNS is an excellent way to get attacker controlled data into a system. But, unlike some recent high profile issues, simply using the library or using those functions does not automatically make the code vulnerable.

This non-trivial exposure to this issue is explained in detail in the advisory, take the example of mount.nfs in §4.2 : a setuid-root binary on most distributions, so a good opportunity for local privilege escalation:

The above calling pattern of inet_aton() then gethostbyname() is the common idiom I was referring to. Given an arbitrary string in hostname, first check to see if it can be treated as a valid IP dotted-quad via inet_aton() (cheap, and low-latency), otherwise see if it is a DNS host name via gethostbyname() (not cheap, and potentially high-latency.

This is how OpenSSH uses those functions also, see the wrapper getaddrinfo in openbsd-compat/fake-rfc25553.c.

One can reasonably conclude (see below) that it will require some detailed analysis to determine if an arbitrary software package is vulnerable, and what configuration or mitigations may apply. Any service which performs name resolution could be at risk.

Qualys have already provided a list of software using the affected functions which they cannot exploit at this time:

Right now, only Exim is confirmed exploitable.

(I don't buy the OpenSSH "mitigation" linked to, useDNS does a reverse look up of the IP address of the TCP connection, which of course cannot be sufficiently controlled by the attacker. I'll update this when I have a chance to verify the steps taken. Reverse DNS in OpenSSH or OpenSSH+libwrap is not exploitable.)

Because of common programming idioms, and the very specific code paths to the vulnerable code, many programs are not vulnerable. To be clear, there is a problem in a specific handful of DNS related functions in glibc, and DNS is an excellent way to get attacker controlled data into a system, though it's not a great way to get arbitrary data in. But, unlike some recent high profile issues, simply using the library or using those functions does not automatically make a program vulnerable.

This non-trivial exploitation of the vulnerability is explained in detail in the advisory, take the example of mount.nfs in §4.2 : a setuid-root binary on most distributions, so a good opportunity for local privilege escalation:

The above calling pattern of inet_aton() then gethostbyname() is the common idiom I was referring to. Given an arbitrary string in hostname, first check to see if it can be treated as a valid IP dotted-quad via inet_aton() (cheap, and low-latency), otherwise see if it is a DNS host name via gethostbyname() (not cheap, and potentially high-latency. See section 3 - Mitigating factors of the advisory.

This is how OpenSSH uses those functions also, see the wrapper getaddrinfo() in openbsd-compat/fake-rfc25553.c. That function is only enabled at compile time if the host has no native getaddrinfo() (or you fudge configure to fool it). glibc has had that function since 1996 (pre v2.0), so gethostbyname() won't be called by OpenSSH. If your OpenSSH is built with libwrap, then the sshd will have some unresolved symbols for gethostbyname* because of that — Qualys claim both TCP wrappers and OpenSSH are safe (for now). The only other use of gethostbyname() in OpenSSH is on HP-specific code where the X DISPLAY need contain an IP rather than a hostname, not relevant here.

In the general case, since conforming DNS data cannot contain problematic long/malformed IP addresses, reverse look up and forward/reverse checks are not an attack vector. Where hostnames/dotted-quad addresses are part of a higher protocol (e.g. the SMTP EHLO name, as used exploiting Exim) then you might have something. For OpenSSH this would suggest host names in port-forwarding, close, but no cigar even if OpenSSH did use gethostbyname() directly:

      if (strlen(host) >= NI_MAXHOST) {
            error("Forward host name too long.");
            return 0;
      }

where NI_MAXHOST is 1025 in versions I've checked so far. and this would be a post-authentication vector in any case.

1
source | link