Affidabilità di kernel.org dopo l'attacco

15

Quali sono le implicazioni sulla sicurezza del compromesso di kernel.org sull'affidabilità della base di codice ospitata nel repository Git del sito? L'annuncio di oggi ha illustrato le attenuazioni fornite dagli hash a 160 bit, dal mirroring dei siti e dalla natura distribuita dello sforzo di sviluppo. Le rassicurazioni sono solide considerando che gli hash per il repository Git principale sono collocati con il codice hash e l'utilizzo / mirroring tipico alla luce del fatto che il sito è stato compromesso per 17 giorni prima del rilevamento? Infine, quali miglioramenti, se ce ne sono, potrebbero essere suggeriti in base a questo evento?

    
posta zedman9991 01.09.2011 - 22:49
fonte

2 risposte

20

Bene, per quanto riguarda l'uso di Git, si scopre che il software e la natura distribuita fanno molto per proteggere il codice e rilevare modifiche dannose. Per i principianti, nessun vecchio commit può essere modificato a meno che non corrisponda al corrispondente hash SHA-1. Anche se un commit ha fatto corrispondere un certo SHA-1, questo avrebbe influito sugli hash SHA-1 del bambino, quindi è fuori. Niente di più vecchio della data della violazione potrebbe essere ragionevolmente alterato o interromperà il repository e la sincronizzazione.

Potrebbero essere aggiunti commit in quel periodo di 17 giorni. Poiché i timestamp fanno parte dell'hash SHA-1 per un commit, possiamo restringere la lista dei commit "sospetti" osservando qualcosa di più antico degli ultimi commit prima della violazione o qualsiasi cosa in cui la data child del commit è più recente rispetto a data genitore. Se hai mai provato a modificare un commit in git dopo che ha raggiunto un repository condiviso, capisci quanto sia gravemente ovvio che qualcosa di storico sia stato alterato.

Poiché le copie complete dell'hash del kernel che contengono la cronologia completa sono così ampiamente distribuite e vengono sempre aggiornate in modo incrementale seguendo una catena di commit che non possono essere fatti andare all'indietro senza che l'utente sia consapevole, il codice sorgente del kernel è in effetti notevolmente sicuro anche quando il sito web di hosting è compromesso.

Infine, poiché solo un numero limitato di individui è in grado di impegnarsi legittimamente nel kernel, possiamo aspettarci che siano in grado di annotare eventuali aggiornamenti alle loro sezioni che non si aspettano. I controlli umani dei sign-off (tipo di controllo tecnico, ma non di tipo) giocano un ruolo importante nel sapere da dove proviene il contenuto.

Tutto sommato, compromettere la fonte del kernel in modo non rilevato mentre è in Git sarebbe uno degli hack più impressionanti del decennio. Uno sarebbe più facile scivolare nel codice attraverso canali appropriati che sembrano innocui ma dannosi.

    
risposta data 02.09.2011 - 03:20
fonte
4

Questa domanda non dovrebbe essere intitolata "attendibilità del PRE-attacco kernel.org"? A pensarci bene, credo che la domanda abbia avuto risposta. : -)

Probabilmente spenderei la maggior parte del mio tempo analitico cercando di decidere quanto sono sicuro della loro determinazione della prima data di attacco possibile.

    
risposta data 02.09.2011 - 17:07
fonte

Leggi altre domande sui tag