Ovvero: come e perché Apple ha castrato un software potenzialmente pericoloso per studiare le sue protezioni tecnologiche. E cosa si può fare per rimettere a posto le cose.

di Nicola D’Agostino

Nell’ultima versione di Mac OS X, la 10.5, l’ambiente di sviluppo XCode è stato profondamente rinnovato e include una potente utility chiamata DTrace.
Sviluppata originariamente da Sun ed inclusa in Solaris 10, Dtrace permette di monitorare accuratamente e senza impatto sulle performance il funzionamento di qualsiasi software in esecuzione ed Apple, attenta alle novità, ha mutuato questa tecnologia open source pubblicizzandone la presenza in Leopard il cui software di analisi e troubleshooting Instruments ne fa ampio uso

La scoperta di Leventhal

La scelta ha incontrato l’approvazione di uno dei tre creatori di DTrace, Adam Leventhal, che nell’estate del 2007 è stato invitato alla convention Apple per sviluppatori e ha conosciuto ed incontrato il team di Cupertino che aveva adottato (ed adattato) la sua “creatura”.

Qualche mese dopo la soddisfazione di Leventhal si è trasformata in sorpresa e poi perplessità alla scoperta che Apple aveva apportato qualche piccola ma sostanziale modifica. Usando la versione inclusa in Mac OS X a Leventhal non ridavano i conti e nello specifico è risultato che iTunes, seppure in esecuzione, non risultavano all’appello di DTrace.

Un DTrace menomato

L’ipotesi che Apple avesse deciso di disabilitare DTrace per alcuni specifici software si è rivelata realtà e, usando i coloriti toni di Leventhal, qualcuno a Cupertino non ha gradito uno strumento egalitario decidendo di appesantire dtrace_probe(), il cuore dell’utility con questo orpello:

#if defined(__APPLE__)
/*
* If the thread on which this probe has fired belongs to a process marked P_LNOATTACH
* then this enabling is not permitted to observe it. Move along, nothing to see here.
*/
if (ISSET(current_proc()->p_lflag, P_LNOATTACH)) {
continue;
}
#endif /* __APPLE__ */


In altre parole Apple impedisce esplicitamente che DTrace esamini o salvi dati relativi a processi che non ammettono il tracing per mezzo della richiesta PT_DENY_ATTACH.

Il caso

La conclusione di Leventhal è moderata nei termini ma pesante nel giudizio: una scelta del genere non solo è errata concettualmente ma va contro l’obbiettivo del software da lui cocreato oltre che contro lo spirito dell’open source e invoca il ripristino delle piene funzionalità.

Alla questione è stata data ampia eco su vari siti e testate che l’hanno sintetizzata attorno all’uso o meglio abuso del PT_DENY_ATTACH e le possibili motivazioni.
Il pensiero va immediatamente alla volontà di Apple di proteggere i suoi interessi economici e di celare ad occhi indiscreti meccanismi delicati. Quali? Ma quelli relativi alle protezioni di DRM per i contenuti audiovisuali che commercializza attraverso l’iTunes Store e gestisce con il layer di protezione Fairplay.

Tra le reazioni tecniche la più interessante è quella dello sviluppatore indipendente Landon Fuller che ha caldeggiato anche lui la rimozione dei blocchi da parte di Apple ma nel frattempo ha deciso, come già in passato, di rimboccarsi le maniche ed affrontare subito il problema.

Una Kext per aggirare il blocco

In “Fixing ptrace(pt_deny_attach, …) on Mac OS X 10.5 Leopard” Fuller non solo dà un’infarinatura tecnica sui meccanismi in azione ma fornisce un hack, una patch per aggirare le modifiche di Apple: la soluzione passa attraverso una KEXT, cioè un’estensione del kernel da scaricare ed installare.

Ciò che fa l’estensione è tenere d’occhio i puntatori alle chiamate di sistema in Xnu (il kernel di Mac OS X) e, quando necessario, inserisce del codice sostitutivo come si può vedere dall’output del comando dmesg (che interroga il buffer del kernel):


[ptrace] Found nsysent at 0x502780 (count 427), calculated sysent location 0x5027a0.
[ptrace] Sanity check 0 1 0 3 4 4: sysent sanity check succeeded.
[ptrace] Patching ptrace(PT_DENY_ATTACH, ...).
[ptrace] Blocking PT_DENY_ATTACH for pid 82248.


Sottolineiamo che si tratta di una soluzione indipendente, non universalmente testata e da usare a proprio rischio e pericolo. Detto questo nelle scritte qui sopra si può notare che l’estensione fa anche dei controlli per evitare un kernel panic. Se c’è qualche problema il modulo scritto da Fuller semplicemente non viene caricato. Se invece tutto è ok il PT_DENY_ATTACH di Apple viene disabilitato ed i processi non avranno alcun velo, come nel DTrace originale.

Landon Fuller, patch-man

Ha un curriculum prestigioso l’autore della pezza a DTrace: Landon Fuller infatti per diversi anni è stato proprio in Apple lavorando sulle basi di Mac OS X ed in seguito al sistema di distribuzione del software BSD-based, che ora si chiama MacPorts.

Già qualche mese fa Fuller si è fatto notare per aver fornito a tempo di record numerosi fix di sicurezza al chiacchierato “Month of Apple Bugs”, iniziativa un po’ provocatoria volta a divulgare “buchi di sicurezza nell’SO del Mac o in programmi di Apple che ci girano sopra”.

A chi volesse approfondire la figura le gesta di questo smanettone consigliamo la lettura di un articolo su Storie di Apple.

Nota le immagini sono “courtesy of Apple” e tratte dal blog di Adam Leventhal.

Una versione di questo articolo è stata pubblicata su "Hacker Journal" 146 del febbraio 2008