10

Is Apache vulnerable to CVE-2015-1781 (buffer overflow in the gethostbyname_r() family of functions)?

How can I quickly check if a system of mine is secure?

  • CVE-2014-1781? CVE-2015-1781? can you provide a link to vulnerability? – Ali May 4 '15 at 9:04
  • CVE-2015-1781 glibc: buffer overflow in gethostbyname_r() and related functions with misaligned buffer . – chenwen2 May 4 '15 at 9:11
  • check the end of my answer again – Ali May 4 '15 at 11:44
9

You must check the version of your glibc first: using this command can help:

ldd --version

The end of the answer has a good things you can skip and go there

According to this reference this vulnerability works on glibc version before 2.21-3. if your glibc is older than this version it is vulnerable.

The problem has been fixed upstream but a new version has yet to be released.

Also there is another vulnerability that Last revised is: 04/13/2015 and also is related to glibc version 2.20 and before it.

Also read this one: Red Hat alert RHSA-2015:0863-01 (glibc)

Arjun Shankar of Red Hat discovered that the nss_dns code does not adjust the buffer length when the buffer start pointer is aligned. As a result, a buffer overflow can occur in the implementation of functions such as gethostbyname_r, and crafted DNS responses might cause application crashes or result in arbitrary code execution. This can only happen if these functions are called with a misaligned buffer. I looked at quite a bit of source code, and tested applications with a patched glibc that logs misaligned buffers. I did not observe any such misaligned buffers.[Reference]

GHOST gethostbyname() heap overflow in glibc (CVE-2015-0235)

This is another vulnerability related to glibc and gethostbyname() this artice said: "to the best of our knowledge, the buffer overflow cannot be triggered in any of [these]:

apache, cups, dovecot, gnupg, isc-dhcp, lighttpd, mariadb/mysql,

nfs-utils, nginx, nodejs, openldap, openssh, postfix, proftpd,

pure-ftpd, rsyslog, samba, sendmail, sysklogd, syslog-ng, tcp_wrappers,

vsftpd, xinetd."

So I think like this vulnerability your mentioned vulnerability does not affect on apache

and maybe this vulnerability has an effect on Apache or maybe not, but untill clarifying this issue. the fast countermeasure is upgrading glibc to last version.

  • Is about the Apache not libc. The user already know about the vulnerability and probably how to check it. – Sacx May 4 '15 at 10:50
  • Thanks for your answer. My glibc(ldd (GNU libc) 2.5) is vulnerable.My apache's version is 2.2.22. – chenwen2 May 5 '15 at 3:23
  • Welcome, yes it is but the answer said that this vulnerability does not has effect on apache. – Ali May 5 '15 at 5:29
0

Apache httpd source: 2.4.12

I did a Source code Grep for 'GLIBC' and 'gethostbyname'

  • I found Refrences to the GlibC Libraries (so Apache could be using them)
  • I also found the following uses of 'gethostbyname' :

    httpd-2.4.12/support/logresolve.pl.in:213: $hostname = gethostbyaddr(gethostbyname($ip), AF_INET);

    httpd-2.4.12/server/util.c:45:#include [netdb.h] /* for gethostbyname() */

    httpd-2.4.12/os/os2/core_header.def:13: "gethostbyname"

    httpd-2.4.12/docs/manual/developer/thread_safety.html.en:175: [code]gethostbyname()[/code] which are not thread-safe on most C

    httpd-2.4.12/docs/manual/developer/thread_safety.html.en:178: [code]gethostbyname()[/code] are thread-safe on your OS, c-client

    httpd-2.4.12/docs/manual/misc/perf-tuning.html.en:147: could consider doing the [code]gethostbyname[/code] call in the

    httpd-2.4.12/docs/manual/misc/perf-tuning.html.fr:161: certains CGIs, vous pouvez effectuer l'appel � [code]gethostbyname[/code]

    httpd-2.4.12/docs/manual/misc/perf-tuning.html.tr.utf8:152: bu ihtiyaçlarına yönelik olarak [code]gethostbyname[/code] çağrıları

    httpd-2.4.12/docs/manual/misc/perf-tuning.html.ko.euc-kr:139: CGI [code]gethostbyname[/code]

    httpd-2.4.12/test/test_limits.c:123: if ((he = gethostbyname(addr)) == NULL) {

    httpd-2.4.12/test/test_limits.c:124: perror("gethostbyname");

    httpd-2.4.12/modules/arch/netware/mod_nw_ssl.c:196: hep = gethostbyname(w);

    httpd-2.4.12/modules/metadata/mod_unique_id.c:64: * gethostbyname (gethostname()) is unique across all the machines at the

So apache httpd could be vulnerable, it further depands on what version of glibc is beeing used. the one reported at risk is Any version below glibc 2.12 (glib 6)

  • From what I see only 2 modules are using gethostbyname ... Core server I assume is not affected. – Sacx May 4 '15 at 10:01
  • 1
    the ' httpd-2.4.12/os/os2/core_header.def:13: "gethostbyname" ' Line makes me think core might be affected. apperntly apapche uses glibc somewhere in the headers handling. – LvB May 4 '15 at 10:04
  • 1
    Looking in that file the definition is related to mod_unique_id not the core. So the core is not touched by this function. – Sacx May 4 '15 at 10:13
  • 1
    I did not see that, but if that is the case Core is not affected but some modules are. – LvB May 4 '15 at 10:16
  • Is exactly what I said :) – Sacx May 4 '15 at 10:22
0

Apache is using Apache Portability Runtime and they implemented their own apr_gethostbyname, so the core server is not vulnerable.

But over the time, some modules, apparently they didn't use APR gethostbyname function, so is very plausible to still find some modules using it.

Also the apache is correctly validating all the inputs, so is a very low chance to hit the overflow even the Apache is using this function.

I made a quick check and I didn't find any reference to gethostbyname_r, so 99.999% Apache Web Server is not vulnerable.

Update:

Also you can see my colleagues are already looking in the source code and gethostbyname was spoted in just 2 modules.

  • Your assuming none of the other libraries implement this somewhere. but I agree it does not seem to be there. – LvB May 4 '15 at 9:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.