Does the GHOST vulnerability affect Macs?

Question

Although the vulnerability targets Linux, I have read that it is really a glibc vulnerability, and some sites suggest that one should install a fix on any platform. I know that there are a lot of packages out there that let you install glibc software on a Mac (such as homebrew, port, etc.) but I am not sure if a stock OS X install uses glibc.

I tried compiling the GHOST.c program given in the vulnerability notification, but get the following error:

$ gcc -o GHOST GHOST.c
Undefined symbols for architecture x86_64:
  "_gethostbyname_r", referenced from:
      _main in ccwPC2Tn.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status

But this doesn't make me feel much better, because I'm pretty sure there are other compilers besides gcc - in fact I don't think XCode even uses gcc any more. (Update: on closer inspection, it appears that gcc is a synonym for clang.) Perhaps the bug is still there but the function has been renamed?

So what can/should a Mac user do to determine if his or her system is affected, and if it is, how can it be fixed, given that the vulnerability may or may not be in binaries supplied by Apple?

[Related Question/Answer](http://stackoverflow.com/questions/19821041/g-ld-symbols-not-found-for-architecture-x86-64) — RoraΖ, Jan 28 '15 at 20:18

score 12 · Accepted Answer · edited Jan 29 '15 at 08:43

OS X is based on a BSD derivative, Darwin, which does not typically use GNU libc. So my expectation is that the answer is "no". That the _gethostbyname_r function, defined by glibc, is not available on OS X reinforces this hunch.

Let's see if some basic inspection of the library can help.

On a CentOS host:

$ strings /lib64/libc.so.6 | grep -i gnu
gnu_dev_makedev
gnu_get_libc_release
gnu_get_libc_version
gnu_dev_minor
gnu_dev_major
GNU C Library stable release version 2.12, by Roland McGrath et al.
Compiled by GNU CC version 4.4.7 20120313 (Red Hat 4.4.7-4).
        GNU Libidn by Simon Josefsson
<http://www.gnu.org/software/libc/bugs.html>.

yet on a mac:

# otool -L /usr/bin/gm4
/usr/bin/gm4:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
# otool -L /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
        /usr/lib/system/libcache.dylib (compatibility version 1.0.0, current version 47.0.0)
        /usr/lib/system/libcommonCrypto.dylib (compatibility version 1.0.0, current version 55010.0.0)
        /usr/lib/system/libcompiler_rt.dylib (compatibility version 1.0.0, current version 6.0.0)
        /usr/lib/system/libcopyfile.dylib (compatibility version 1.0.0, current version 85.1.0)
        /usr/lib/system/libdispatch.dylib (compatibility version 1.0.0, current version 187.7.0)
        /usr/lib/system/libdnsinfo.dylib (compatibility version 1.0.0, current version 395.7.0)
        /usr/lib/system/libdyld.dylib (compatibility version 1.0.0, current version 195.5.0)
        /usr/lib/system/libkeymgr.dylib (compatibility version 1.0.0, current version 23.0.0)
        /usr/lib/system/liblaunch.dylib (compatibility version 1.0.0, current version 392.35.0)
        /usr/lib/system/libmacho.dylib (compatibility version 1.0.0, current version 800.0.0)
        /usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 2026.0.0)
        /usr/lib/system/libquarantine.dylib (compatibility version 1.0.0, current version 36.0.0)
        /usr/lib/system/libremovefile.dylib (compatibility version 1.0.0, current version 21.0.0)
        /usr/lib/system/libsystem_blocks.dylib (compatibility version 1.0.0, current version 53.0.0)
        /usr/lib/system/libsystem_c.dylib (compatibility version 1.0.0, current version 763.12.0)
        /usr/lib/system/libsystem_dnssd.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/system/libsystem_info.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/system/libsystem_kernel.dylib (compatibility version 1.0.0, current version 1699.24.8)
        /usr/lib/system/libsystem_network.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/system/libsystem_notify.dylib (compatibility version 1.0.0, current version 80.1.0)
        /usr/lib/system/libsystem_sandbox.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/system/libunc.dylib (compatibility version 1.0.0, current version 24.0.0)
        /usr/lib/system/libunwind.dylib (compatibility version 1.0.0, current version 30.0.0)
        /usr/lib/system/libxpc.dylib (compatibility version 1.0.0, current version 77.17.0)
# strings /usr/lib/libSystem.B.dylib | grep -i gnu

libsystem_c looks suspicious there, but let's check everything.

# for dl in /usr/lib/system/lib*.dylib; do echo $dl; strings $dl | grep -i gnu; done
...trimmed...
/usr/lib/system/libunwind.dylib
malformed DW_CFA_GNU_negative_offset_extended dwarf unwind, reg too big
...trimmed...

I started with gm4 since it's a GNU tool, and used otool to trace down its library dependencies.

So I think the answer is a fairly safe "no" as far as the Apple-supplied system goes. As the question states, it's certainly possible to install glibc with third-party tools (although port search glibc doesn't find anything - note that glib is totally NOT the same as glibc).

Does the GHOST vulnerability affect Macs?

1 Answers1

Linked

Related