Qualche giorno fa’ ci siamo occupati delle “miracolose” prestazioni ottenute dal neobrowser di casa Google.
Lo sviluppatore Scott Hanselman, dopo aver ha spiegato i vantaggi della libreria Open Source Microsoft “WTL” utilizzata proprio da Chrome, affrontava un ultimo ed interessante tema: per ottenere determinati risultati e funzionalità è stato disassemblato Windows?
In realtà all’interrogativo non era stata data una risposta definitiva, anche perché si tratterebbe di un’affermazione carica di significati e rischi, in considerazione del fatto che l’EULA Microsoft vieta esplicitamente questa pratica.
La disponibilità del codice sorgente unita ai dubbi giustamente sollevati ha però provocato un moto di interesse all’interno della Rete, ed in particolare in quella schiera di sviluppatori, utenti etici, addetti ai lavori o semplici “curiosi ficcanaso”, determinati a scovare qualche indizio sostanziale delle ipotesi stilate all’interno dell’articolo di Hanselman.
Tra questi, Arstechnica ha spinto l’analisi ancor più in profondità.
Partiamo da lontano.
Come sappiamo ormai tutti e piuttosto bene, Google Chrome all’apertura di ogni nuovo tab (la scheda che sostituisce la vecchia finestra e che visualizza un sito) fa coincidere la creazione di un nuovo processo.
Il medesimo procedimento è replicato anche in presenza di plugin ed è stata inoltre reso indipendente il funzionamento dell’interfaccia dal motore di rendering e parte dedicata al processing dei dati.
Una feature senz’altro comoda ma che nasce anche da attente analisi sui fattori di rischio riguardo l’uso di un browser oggigiorno.
Se infatti l’incauto internauta si dovesse imbattere in qualche sito creato ad hoc per immettere codice maligno client-side e far crashare l’applicazione, il risultato sarebbe circostanziato al solo sito incriminato, lasciando intatto l’utilizzo delle altre parti dell’applicativo stesso.
Un’architettura che viene definita modulare, con un approccio di tipo sandbox.
In realtà era stata Microsoft stessa ad innalzare il livello delle policy utilizzate dai browser, prima con IE7 (dove era vietato esplicitamente il poter mescolare le aree di sicurezza con lo stesso processo, ad esempio Intranet ed Internet) e poi con IE8, attualmente in Beta release e che utilizza lo stesso concetto di Chrome: un tab per un’istanza dell’applicazione.
Un’altra funzionalità di cui si avvale Internet Explorer è La Data Execution Protection, utilizzata ormai da qualche anno nei processori della famiglia X86 (per la precisione con gli Athlon64 e il bit NX) e che sostanzialmente previene gli attacchi che fanno uso del buffer overflow.
Proprio nella gestione di questa feature, arrivano i “problemi”.
Per adattarsi infatti alle varie versioni di Windows, che non fruiscono allo stesso modo della DEP (le Win32 API la mettono a disposizione ancor prima che le cpu l’avessero introdotto, ma poi negli anni, come abbiamo già anticipato, sono stati apportati dei cambiamenti), gli sviluppatori si sono trovati di fronte al problema di non avere nemmeno la documentazione necessaria per poter beneficiare e così si sono trovati “costretti” a disassemblare lo stesso kernel di Windows come possiamo notare da questa porzione di codice:
“// Completely undocumented from Microsoft. You can find this information by
// disassembling Vista’s SP1 kernel32.dll with your favorite disassembler.
enum PROCESS_INFORMATION_CLASS {
ProcessExecuteFlags = 0x22,
}”
”
Una palese violazione del contratto di cui riportiamo un estratto:
- work around any technical limitations in the software;
- reverse engineer, decompile or disassemble the software, except and only to the extent that applicable law expressly permits, despite this limitation;
- use components of the software to run applications not running on the software;
- make more copies of the software than specified in this agreement or allowed by applicable law, despite this limitation;
E il lato paradossale della vicenda è che l’EULA stessa di Chrome usa i medesimi vincoli.
E’ interessante notare come, dopo l’analisi tecnica, seppur ci siano diversi particolari piuttosto definiti e che non lasciano molto spazio ad interpretazioni (ovvero che Google avrebbe effettivamente disassemblato parte del kernel di Windows) l’accento si sposti su un altro tema.
Peter Bright, il redattore di Arstechnica e curatore dell’articolo afferma infatti quasi la necessità tavolta di queste azioni, causate dalla volontà di Microsoft di rilasciare una solamente documentazione base (e di non fornire una lista ad esempio una lista di funzionalità de facto messe a disposizione dalle API, il cui elenco, ad esempio, viene aggiornato sì però solo con la release successiva), ma che non soddisfa evidentemente le esigenze degli sviluppatori che vogliono ottenere qualcosa di più dalle proprie applicazioni: in questo caso, quel “qualcosa” è rappresentato dalle politiche di sicurezza del browser Google.
Questa vicenda avrà delle ripercussioni legali tra i due colossi oppure aprirà gli occhi sul fatto che se a monte si stabiliscono meno forzature, ne beneficiamo tutti noi, tra utenti finali, programmatori e le stesse software house?
Ai posteri l’ardua sentenza, noi vi terremo comunque informati :)
