Scout Browser goes under peer review, analyse, revisione

Revisione paritaria per il Browser Scout

Dire che siamo bravi non è abbastanza. Il momento della verità arriva quando un esperto esterno o un tuo pari esamina attentamente quello che fai e ti valuta con un bel pollice rivolto verso l’alto.

Nel mondo accademico questa procedura è chiamata revisione paritaria ed è essenziale per qualsiasi documento meritevole. Tra gli sviluppatori di software viene invece chiamata revisione esterna del codice. Ed è proprio quello che abbiamo fatto con il nostro browser Scout. Abbiamo accumulato un numero sufficiente di modifiche (aggiunte al codice Chromium) da giustificare una revisione esterna del codice.

Ma prima di entrare nel merito di questa revisione, è giunto il momento di parlare delle “buone prassi” interne che seguiamo in Avira per la codifica. Dopo tutto una revisione esterna non può essere meglio della precedente codifica che lui (o lei) sta osservando.

Principi di programmazione sicura

Questa è una lista di cose “da fare” e “da non fare” che dobbiamo seguire scrupolosamente durante la programmazione. Si tratta di un documento interno che copre condizioni tipiche. Vi sono alcune linee guida generali (sprintf vs snprintf) e altre specifiche per il progetto.

Per il team di Scout una regola fondamentale è “non rompere la sandbox”. Nei browser Chrom(ium) la sandbox è un recinto intorno al browser che lo separa dal sistema operativo. In questo modo anche se il browser viene hackerato e diventa dannoso non può compromettere il sistema. Stiamo attentissimi a rispettare questa regola.

Revisione del codice durante la programmazione

Abbiamo configurato i nostri strumenti in modo che “soltanto i codici che sono stati rivisti e accettati da altri due sviluppatori possano entrare nel repository”. Questa è una misura di sicurezza importante per i nostri sviluppatori. Anche quando abbiamo una giornata no, ci sono altri due membri del team che controllano il nostro codice e si assicurano che sia stato scelto il percorso più efficace e sicuro per raggiungere i nostri obiettivi. Grazie a questa procedura noi sviluppatori possiamo dormire sonni tranquilli e, anche se probabilmente non ne sono consapevoli, possono farlo anche gli utenti finali.

Diciamoci la verità: a volte non è facile accettare queste critiche, ma dalle critiche possiamo imparare e migliorare.

Revisioni esterne

Lavoriamo con diverse società esterne specializzate nella revisione dei codici. Si tratta di esperti che cercano bug e vulnerabilità all’interno del codice. Quando abbiamo messo insieme una quantità sufficiente di codice nuovo, peschiamo uno dei loro biglietti da visita e li invitiamo a svolgere una revisione in-house. L’ultima di queste è stata affidata a X41. Gli esperti di questa società hanno trascorso una settimana con il nostro team di Scout controllando il nostro codice e ponendo domande insidiose. Al termine della settimana i revisori avevano trovato una decina di bug (di piccola e media entità) che avremmo dovuto correggere. Per il team di sviluppatori di Scout si è trattato di una settimana istruttiva e divertente.

Fuzzing

Il fuzzing è una tecnica che bombarda le interfacce (rete, file, input dell’utente) con dati inaspettati per poi vedere cosa accade, ad esempio un arresto anomalo del software oppure un comportamento strano. Questo può essere causato da file contenenti piccoli errori, pacchetti di rete danneggiati e molto altro. Questi file danneggiati vengono testati a una velocità di diverse migliaia al secondo permettendoci di avvicinarci sempre più a un rilevamento completamente automatico dei bug. Ce ne occupiamo personalmente e la società esterna che abbiamo coinvolto ha molta esperienza nel fuzzing dei browser.

Il codice sorgente Chromium è già stato sottoposto a un fuzzing approfondito (grazie, Google!). Ma lo stesso non si può dire della tecnologia che abbiamo aggiunto al pacchetto del browser Scout. Di conseguenza abbiamo dovuto lavorarci personalmente.

Un’ultima cosa: programmi bug bounty

Avira organizza programmi bug bounty per molti dei suoi prodotti. Si tratta di piacevoli eventi per esperti di tecnologia dotati di creatività che possono cercare bug all’interno dei prodotti e ricevere una ricompensa per la loro segnalazione. Ma per Scout non abbiamo (ancora) programmi di questo tipo. Il nostro codice è formato per la maggior parte dal codice di Chromium e Google ha un proprio bug bounty per questi bug. Quindi al momento un bug bounty per Scout sarebbe un evento piuttosto noioso e poco lucrativo per i partecipanti. Lo organizzeremo non appena avremo più bug da scovare.

Questo articolo è disponibile anche in: IngleseTedescoFrancese

I use science to protect people. My name is Thorsten Sick and I do research projects at Avira. My last project was the ITES project where I experimented with Sandboxes, Sensors and Virtual Machines. Currently I am one of the developers of the new Avira Browser