GitHub a publié des modifications des règles qui définissent la politique concernant l'hébergement des exploits et des résultats de recherches sur les logiciels malveillants, ainsi que le respect de la loi américaine sur le droit d'auteur dans l'ère numérique (DMCA). Les modifications sont encore en phase de brouillon, accessibles pour discussion pendant 30 jours.
Dans les règles de conformité au DMCA, en plus de l'interdiction précédemment existante de distribuer et de faciliter l'installation ou la livraison de logiciels malveillants actifs et d'exploits, des conditions supplémentaires ont été ajoutées :
- Interdiction explicite de placer dans les dépôts des technologies permettant de contourner les mesures techniques de protection des droits d'auteur, y compris des clés de licence, ainsi que des programmes pour générer des clés, contourner la vérification des clés et prolonger la période d'utilisation gratuite.
- Un processus de demande de suppression de ce type de code est mis en place. La personne soumettant la demande de suppression doit fournir des détails techniques, avec l'intention déclarée de transmettre cette demande à un examen avant le blocage.
- Lors du blocage du dépôt, il est promis de permettre l'exportation des issues et des PR, et de proposer des services juridiques.
Les modifications apportées aux règles concernant les exploits et les logiciels malveillants tiennent compte des critiques formulées après que Microsoft ait supprimé le prototype d'exploit pour Microsoft Exchange, utilisé pour mener des attaques. Les nouvelles règles tentent de séparer explicitement le contenu présentant un danger et utilisé pour mener des attaques actives, et le code accompagnant les recherches en matière de sécurité. Les changements apportés sont :
- Il est interdit non seulement d'attaquer les utilisateurs de GitHub en y hébergeant du contenu d'exploits ou d'utiliser GitHub comme moyen de livraison d'exploits, comme c'était le cas auparavant, mais aussi d'héberger du code malveillant et des exploits associés à la conduite d'attaques actives. De manière générale, il n'est pas interdit d'héberger des exemples d'exploits préparés dans le cadre de recherches en sécurité et concernant des vulnérabilités déjà corrigées, mais cela dépendra de l'interprétation du terme « attaques actives ».
Par exemple, la publication de tout type de code source JavaScript attaquant un navigateur entre sous ce critère — rien n'empêche un attaquant de charger le code source dans le navigateur de la victime via fetch, de le patcher automatiquement si le prototype de l'exploit est publié dans un état non fonctionnel, et de l'exécuter. Il en va de même pour tout autre code, par exemple en C++, — rien n'empêche de le compiler sur la machine attaquée et de l'exécuter. Lorsqu'un référentiel contenant un tel code est découvert, il est prévu de ne pas le supprimer, mais de restreindre son accès.
- Le paragraphe déplacé plus haut dans le texte, interdisant le « spam », la manipulation des résultats, la participation au marché de la manipulation, les programmes violant les règles de certains sites, le phishing et ses tentatives.
- Ajout d'un point expliquant la possibilité de faire appel en cas de désaccord avec un blocage.
- Ajout d'une exigence pour les propriétaires de référentiels contenant du contenu potentiellement dangereux dans le cadre de recherches en sécurité. La présence de ce contenu doit être clairement mentionnée au début du fichier README.md, et des coordonnées de contact doivent être fournies dans le fichier SECURITY.md. Il est indiqué qu'en général, GitHub ne supprime pas les exploits publiés avec des recherches en sécurité pour des vulnérabilités déjà divulguées (non 0-day), mais se réserve le droit de restreindre l'accès s'il juge qu'il existe un risque d'utilisation de ces exploits pour de véritables attaques et que des plaintes concernant l'utilisation du code pour des attaques parviennent au support de GitHub.
Source : opennet.ru
