GitHub a publié des modifications de politique qui décrivent les politiques concernant la publication d'exploits et la recherche de logiciels malveillants, ainsi que la conformité au Digital Millennium Copyright Act (DMCA) des États-Unis. Les modifications sont encore à l’état de projet, disponibles pour discussion dans les 30 jours.
En plus de l'interdiction précédemment présente de distribuer et d'assurer l'installation ou la livraison de logiciels malveillants et d'exploits actifs, les termes suivants ont été ajoutés aux règles de conformité DMCA :
- Interdiction explicite de placer dans le référentiel des technologies permettant de contourner les moyens techniques de protection du droit d'auteur, y compris les clés de licence, ainsi que les programmes permettant de générer des clés, de contourner la vérification des clés et de prolonger la période de travail gratuite.
- Une procédure de dépôt d'une demande de suppression d'un tel code est en cours de mise en place. Le demandeur de suppression est tenu de fournir des détails techniques, avec l'intention déclarée de soumettre sa demande à l'examen avant son blocage.
- Lorsque le référentiel est bloqué, ils promettent d'offrir la possibilité d'exporter des problèmes et des PR, et d'offrir des services juridiques.
Les modifications apportées aux règles relatives aux exploits et aux logiciels malveillants répondent aux critiques formulées après que Microsoft a supprimé un prototype d'exploit Microsoft Exchange utilisé pour lancer des attaques. Les nouvelles règles tentent de séparer explicitement le contenu dangereux utilisé pour des attaques actives du code prenant en charge la recherche en matière de sécurité. Modifications effectuées:
- Il est interdit non seulement d’attaquer les utilisateurs de GitHub en publiant du contenu contenant des exploits ou d’utiliser GitHub comme moyen de diffuser des exploits, comme c’était le cas auparavant, mais également de publier du code malveillant et des exploits accompagnant des attaques actives. De manière générale, il n'est pas interdit de publier des exemples d'exploits préparés lors de recherches de sécurité et affectant des vulnérabilités déjà corrigées, mais tout dépendra de la manière dont le terme « attaques actives » sera interprété.
Par exemple, la publication de code JavaScript sous toute forme de texte source qui attaque un navigateur relève de ce critère - rien n'empêche l'attaquant de charger le code source dans le navigateur de la victime à l'aide de fetch, en le corrigeant automatiquement si le prototype d'exploit est publié sous une forme inutilisable. , et l'exécuter. De même avec tout autre code, par exemple en C++ - rien ne vous empêche de le compiler sur la machine attaquée et de l'exécuter. Si un référentiel avec un code similaire est découvert, il est prévu non pas de le supprimer, mais d'en bloquer l'accès.
- La section interdisant le « spam », la tricherie, la participation au marché de la triche, les programmes permettant de violer les règles de tout site, le phishing et ses tentatives a été déplacée plus haut dans le texte.
- Un paragraphe a été ajouté expliquant la possibilité de faire appel en cas de désaccord avec le blocage.
- Une exigence a été ajoutée pour les propriétaires de référentiels hébergeant du contenu potentiellement dangereux dans le cadre de recherches de sécurité. La présence d'un tel contenu doit être explicitement mentionnée au début du fichier README.md, et les coordonnées doivent être fournies dans le fichier SECURITY.md. Il est précisé qu'en général GitHub ne supprime pas les exploits publiés lors des recherches de sécurité pour les vulnérabilités déjà divulguées (et non 0-day), mais se réserve la possibilité d'en restreindre l'accès s'il considère qu'il subsiste un risque que ces exploits soient utilisés pour de véritables attaques. et dans le service, le support GitHub a reçu des plaintes concernant le code utilisé pour des attaques.
Source: opennet.ru