GitHub heeft een aantal regelwijzigingen vrijgegeven, voornamelijk het bepalen van het beleid met betrekking tot de locatie van exploits en de resultaten van malwareonderzoekevenals naleving van de huidige Amerikaanse auteursrechtwetgeving.
In de publicatie van de nieuwe beleidsupdates vermelden ze dat ze zich richten op het verschil tussen actief schadelijke inhoud, die niet is toegestaan op het platform, en code in rust ter ondersteuning van beveiligingsonderzoek, wat welkom en aanbevolen is.
Deze updates zijn ook gericht op het wegnemen van dubbelzinnigheid in de manier waarop we termen als "exploit", "malware" en "levering" gebruiken om duidelijkheid van onze verwachtingen en bedoelingen te bevorderen. We hebben een pull-verzoek geopend voor openbaar commentaar en nodigen beveiligingsonderzoekers en -ontwikkelaars uit om met ons samen te werken aan deze verduidelijkingen en ons te helpen de behoeften van de gemeenschap beter te begrijpen.
Onder de wijzigingen die we kunnen vinden, zijn de volgende voorwaarden toegevoegd aan de DMCA-nalevingsregels, naast het eerder bestaande verbod op distributie en het garanderen van de installatie of levering van actieve malware en exploits:
Uitdrukkelijk verbod op het plaatsen van technologieën in het archief om technische beschermingsmiddelen te omzeilen copyright, inclusief licentiesleutels, evenals programma's voor het genereren van sleutels, het overslaan van sleutelverificatie en het verlengen van de vrije werkperiode.
Hierop wordt vermeld dat de procedure wordt ingevoerd om een verzoek in te dienen om de genoemde code te schrappen. De aanvrager van de verwijdering moet technische details verstrekken, met de bedoeling om de aanvraag ter beoordeling in te dienen voorafgaand aan de lockdown.
Door de repository te blokkeren, beloven ze de mogelijkheid te bieden om kwesties en public relations te exporteren en juridische diensten aan te bieden.
De wijzigingen in het malware- en exploitbeleid weerspiegelen kritiek na de verwijdering door Microsoft van een prototype van een Microsoft Exchange-exploit dat wordt gebruikt om aanvallen uit te voeren. De nieuwe regels proberen de gevaarlijke inhoud die wordt gebruikt om actieve aanvallen uit te voeren expliciet te scheiden van de code die bij het beveiligingsonderzoek hoort. Veranderingen gemaakt:
Niet alleen het aanvallen van GitHub-gebruikers is verboden het publiceren van inhoud met exploits of het gebruiken van GitHub als een voertuig voor het leveren van exploit, zoals voorheen, maar publiceert ook kwaadaardige code en exploits die gepaard gaan met actieve aanvallen. Over het algemeen is het niet verboden om voorbeelden te publiceren van exploits die zijn ontwikkeld tijdens beveiligingsonderzoeken en die betrekking hebben op kwetsbaarheden die al zijn opgelost, maar het hangt allemaal af van hoe de term "actieve aanvallen" wordt geïnterpreteerd.
Het posten in elke vorm van JavaScript-broncode die de browser aanvalt, valt bijvoorbeeld onder dit criterium: de aanvaller verhindert niet dat de aanvaller de broncode downloadt naar de browser van het slachtoffer door te zoeken en automatisch te patchen of het prototype van de exploit is gepubliceerd in een onbruikbare vorm, en het uitvoeren ervan.
Hetzelfde geldt voor elke andere code, bijvoorbeeld in C ++: niets verhindert het compileren en draaien op de aangevallen machine. Als een repository met dergelijke code wordt gevonden, is het de bedoeling deze niet te verwijderen, maar de toegang ertoe te sluiten.
Daarnaast is het toegevoegd:
- Een clausule die de mogelijkheid uitlegt om in beroep te gaan in geval van onenigheid met de blokkade.
- Een vereiste voor eigenaren van opslagplaatsen die potentieel gevaarlijke inhoud hosten als onderdeel van beveiligingsonderzoek. De aanwezigheid van dergelijke inhoud moet expliciet worden vermeld aan het begin van het README.md-bestand, en de contactgegevens voor de communicatie moeten worden verstrekt in het SECURITY.md-bestand.
Er wordt gesteld dat GitHub over het algemeen geen gepubliceerde exploits verwijdert, samen met beveiligingsonderzoeken voor reeds onthulde kwetsbaarheden (niet dag 0), maar behoudt zich de mogelijkheid voor om de toegang te beperken als het denkt dat er nog steeds een risico is om deze in-service en real-world te gebruiken aanval misbruikt GitHub-ondersteuning heeft klachten ontvangen over het gebruik van code voor aanvallen.
De wijzigingen bevinden zich nog in de conceptstatus en kunnen gedurende 30 dagen worden besproken.
bron: https://github.blog/