Scout Browser goes under peer review, analyse, revisione

Le navigateur Scout objet d’une évaluation par les pairs

Clamer son efficacité ne suffit pas. Le moment de vérité se produit lorsque des experts externes ou des pairs passent au crible votre travail et vous donnent le feu vert en connaissance de cause.

Dans le secteur académique, cela s’appelle évaluation des pairs, une pratique essentielle à tout article digne d’intérêt. Les développeurs de logiciels appellent cela analyse de code externe. C’est précisément ce à quoi nous avons soumis notre navigateur Scout. Nous avions en effet amassé suffisamment de modifications (outre le code Chromium) pour justifier une analyse de code externe.

Mais avant de vous en exposer les tenants et aboutissants, le temps est venu de présenter les « meilleures pratiques » et processus d’analyse mis en œuvre par Avira en interne en ce qui concerne le codage. Après tout, une analyse externe ne saurait surpasser le codage faisant l’objet de son analyse :

Principes de programmation sécurisée

Vous trouverez ci-dessous une liste de choses à faire et à éviter que nous suivons à la lettre en matière de programmation. Il s’agit d’un document interne qui couvre les conditions types de programmation. Il inclut des directives générales (sprintf vs snprintf) ainsi que des directives spécifiques à chaque projet.

Pour l’équipe Scout, un des principes directeurs énonce « Pas touche au sandbox ». Dans les navigateurs Chrome et Chromium, le sandbox s’apparente à un mur entourant le navigateur et séparant ce dernier du système d’exploitation. En cas de piratage transformant le navigateur en un objet malveillant, celui-ci ne peut pas être nuisible pour le système. Nous veillons à ne jamais compromettre son intégrité.

Analyse de code lors de la programmation

Nous avons configuré nos outils de sorte que « seul le code analysé et approuvé par deux autres développeurs au moins accède au référentiel ». C’est là un important filet de sécurité pour les développeurs que nous sommes. Ainsi, même dans les jours sans, le code passe toujours devant les yeux de deux autres membres de l’équipe afin d’assurer que nous visons toujours la manière la plus efficace et la plus sécurisée d’atteindre nos objectifs. Cela permet à nos développeurs de toujours dormir sur leurs deux oreilles, et par extension aux utilisateurs finaux également, même s’ils n’en sont pas forcément conscients.

En toute honnêteté, il est parfois quelque peu difficile d’accepter la critique, mais c’est en l’acceptant que nous apprenons et que nous nous améliorons.

Analyses externes

Nous collaborons avec plusieurs sociétés externes spécialisées dans l’analyse de code. Ces experts sont capables d’identifier les bogues et les vulnérabilités dans un code. Dès lors que nous avons compilé suffisamment de nouveau code, nous tirons au sort l’un des noms de ces sociétés et les invitons à procéder à une analyse en interne. La dernière analyse a été conduite par X41. Leurs équipes ont passé une semaine auprès de l’équipe Scout, à vérifier le code et poser des questions complexes. Passé ce délai, ils avaient identifié une douzaine de bogues (mineurs à modérés) à corriger. Cette semaine s’est avérée riche en apprentissages et en bons moments également pour l’équipe de développement Scout.

Fuzzing

Le fuzzing est un test consistant à bombarder les interfaces (réseau, fichiers, entrées utilisateur) de données aléatoires et à observer la réaction du logiciel, notamment s’il plante ou présente un comportement anormal. Cela peut résulter de fichiers compromis ou de paquets réseau tronqués. Le test peut ainsi injecter des milliers de ces fichiers compromis par seconde, nous rapprochant de la détection de bogue entièrement automatisée. Nous avons mis au point nos propres tests et la société à laquelle nous avons fait appel a également une vaste expérience du fuzzing des navigateurs.

Le code source Chromium est au départ de nature largement aléatoire (merci Google !). Mais la technologie que nous avons ajoutée au package du navigateur Scout ne l’était pas. C’est la raison pour laquelle nous avons dû nous en occuper personnellement.

Une dernière chose : les Bug bounties

Avira organise des bug bounties pour nombre de ses produits. Ces événements constituent une belle distraction pour les experts en technologie créatifs qui sont invités à identifier les bogues dans les produits contre rétribution. Mais nous n’avons pas (encore) ouvert de bug bounty pour Scout. Le code provient en majorité de Chromium et Google organise ses propres bug bounties pour ces bogues. Il ne serait pas très exaltant ni très lucratif pour les aficionados de participer à un bug bounty Scout maintenant. Nous serons de retour dès que nous aurons de nouveaux bogues à identifier.

Cet article est également disponible en: AnglaisAllemandItalien

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