¿La vulnerabilidad de GHOST afecta a las Mac?

Question

¿La vulnerabilidad de GHOST afecta a las Mac?

#1 de djmitche (12 votos)

14

Aunque la vulnerabilidad se dirige a Linux, he leído que es realmente una vulnerabilidad de glibc, y algunos sitios sugieren que se debería instalar una solución en cualquier plataforma. Sé que hay una gran cantidad de paquetes que te permiten instalar el software glibc en una Mac (como homebrew, puerto, etc.) pero no estoy seguro de si una instalación de OS X en stock usa glibc.

Intenté compilar el programa GHOST.c dado en la notificación de vulnerabilidad , pero recibe el siguiente 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

Pero esto no me hace sentir mucho mejor, porque estoy bastante seguro de que hay otros compiladores además de gcc; de hecho, creo que XCode ni siquiera usa gcc. (Actualización: en una inspección más cercana, parece que gcc es un sinónimo de clang.) Tal vez el error todavía está allí, pero la función ha sido renombrada?

Entonces, ¿qué puede / debe hacer un usuario de Mac para determinar si su sistema está afectado y, en caso afirmativo, cómo puede solucionarse, dado que la vulnerabilidad puede o no estar en los binarios suministrados por Apple?

macosx ghost

pregunta Michael 28.01.2015 - 17:43

fuente

1 respuesta

Lea otras preguntas en las etiquetas macosx ghost

¿Dónde puedo encontrar contratos de prueba de seguridad de ejemplo o plantilla? [cerrado] Inspección profunda de paquetes: ¿Algún ejemplo real de mitigación de amenazas a través de DPI? [cerrado]

score 12 · Accepted Answer

OS X se basa en un derivado de BSD, Darwin, que normalmente no utiliza GNU libc. Así que mi expectativa es que la respuesta es "no". Que la función _gethostbyname_r , definida por glibc, no esté disponible en OS X refuerza esta corazonada.

Veamos si puede ayudar alguna inspección básica de la biblioteca.

En un host CentOS:

$ 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>.

todavía en un 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 parece sospechoso allí, pero revisemos todo.

# 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...

Comencé con gm4 ya que es una herramienta GNU y usé otool para rastrear sus dependencias de la biblioteca.

Así que creo que la respuesta es un "no" bastante seguro en lo que respecta al sistema suministrado por Apple. Como dice la pregunta, es posible instalar glibc con herramientas de terceros (aunque port search glibc no encuentra nada, tenga en cuenta que glib no es lo mismo que glibc ).