La vulnerabilità di GHOST influisce sui Mac?

Question

La vulnerabilità di GHOST influisce sui Mac?

#1 da (12 voti)

14

Sebbene la vulnerabilità sia indirizzata a Linux, ho letto che si tratta davvero di una vulnerabilità di tipo glibc e alcuni siti suggeriscono di installare una correzione su qualsiasi piattaforma. So che ci sono molti pacchetti là fuori che consentono di installare il software glibc su un Mac (come homebrew, porta, ecc.) Ma non sono sicuro che un'installazione di OS X di serie usi glibc.

Ho provato a compilare il programma GHOST.c indicato nella notifica di vulnerabilità , ma ottieni il seguente errore:

$ 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

Ma questo non mi fa sentire molto meglio, perché sono abbastanza sicuro che ci siano altri compilatori oltre a gcc - in effetti non credo che XCode usi ancora gcc più. (Aggiornamento: a un esame più attento, sembra che gcc sia sinonimo di clang.) Forse il bug è ancora lì ma la funzione è stata rinominata?

Quindi cosa può / deve fare un utente Mac per determinare se il suo sistema è interessato, e se lo è, come può essere corretto, dato che la vulnerabilità può essere o meno nei file binari forniti da Apple?

macosx ghost

posta Michael 28.01.2015 - 17:43

fonte

1 risposta

Leggi altre domande sui tag macosx ghost

Utilizzando l'autenticazione reciproca, dovrei ancora preoccuparmi dell'integrità dei messaggi e dell'attacco di riproduzione? Come mantenere il mio server VPS su Hulk.py all'attacco

score 12 · Accepted Answer

OS X è basato su un derivato BSD, Darwin, che in genere non usa GNU libc. Quindi la mia aspettativa è che la risposta sia "no". Che la funzione _gethostbyname_r , definita da glibc, non sia disponibile su OS X rafforza questa impressione.

Vediamo se può essere d'aiuto qualche ispezione di base della libreria.

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

ancora su 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 sembra sospetto lì, ma controlliamo tutto.

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

Ho iniziato con gm4 poiché si tratta di uno strumento GNU e ho utilizzato otool per tracciare le sue dipendenze della libreria.

Quindi penso che la risposta sia un "no" abbastanza sicuro per quanto riguarda il sistema fornito da Apple. Come afferma la domanda, è certamente possibile installare glibc con strumenti di terze parti (sebbene port search glibc non trovi nulla - nota che glib è totalmente NON uguale a glibc ).