GitHub opublikował zmiany w zasadach określających politykę dotyczącą publikacji exploitów oraz wyników badań malware, a także przestrzegania obowiązującego w USA Ustawy o prawie autorskim w erze cyfrowej (DMCA). Zmiany są na razie w stanie roboczym i dostępne do dyskusji przez 30 dni.
W zasadach przestrzegania DMCA, oprócz wcześniej obowiązującego zakazu rozpowszechniania oraz dostarczania aktywnego malware i exploitów, wprowadzono następujące warunki:
- Wyraźny zakaz umieszczania w repozytoriach technologii omijających techniczne środki ochrony praw autorskich, w tym kluczy licencyjnych, a także programów do generowania kluczy, omijania weryfikacji kluczy i przedłużania okresu próbnego.
- Wprowadzono procedurę składania wniosków o usunięcie takiego kodu. Od wnioskodawcy wymagane jest przedstawienie szczegółów technicznych, z deklarowanym zamiarem przekazania tego wniosku do ekspertyzy przed zablokowaniem.
- Podczas blokowania repozytoriów obiecano zapewnić możliwość eksportu issue i PR-ów, a także zaoferować usługi prawne.
Zmiany w zasadach dotyczących exploitów i malware uwzględniają krytykę, która pojawiła się po usunięciu przez firmę Microsoft prototypu exploita dla Microsoft Exchange, wykorzystywanego do przeprowadzania ataków. W nowych zasadach podjęto próbę wyraźnego rozdzielenia treści stwarzających zagrożenie i wykorzystywanych do przeprowadzania aktywnych ataków oraz kodu towarzyszącego badaniom w zakresie bezpieczeństwa. Wprowadzone zmiany:
- Zabronione jest nie tylko atakowanie użytkowników GitHub poprzez umieszczanie na nim treści z exploitami czy wykorzystywanie GitHub jako środka dostarczania exploitów, jak to miało miejsce wcześniej, ale także umieszczanie złośliwego kodu i exploitów towarzyszących przeprowadzaniu aktywnych ataków. Ostatecznie nie zabrania się publikowania przykładów exploitów opracowanych w trakcie badań bezpieczeństwa i dotyczących już naprawionych luk, ale wszystko będzie zależało od interpretacji terminu „aktywnych ataków”.
Na przykład publikacja jakiejkolwiek wersji tekstów źródłowych kodu JavaScript, atakującego przeglądarkę, podlega temu kryterium — atakujący nie ma żadnych przeszkód, aby załadować kod źródłowy do przeglądarki ofiary przez fetch, automatycznie go spatchować, jeśli prototyp exploita został opublikowany w nieoperacyjnym stanie, i go wykonać. Podobnie jak z każdym innym kodem, na przykład w C++, — nic nie stoi na przeszkodzie, aby skompilować go na atakowanej maszynie i wykonać. W przypadku odkrycia repozytorium z takim kodem planuje się nie usuwać go, ale zamknąć do niego dostęp.
- Przeniesiony wyżej w tekście rozdział, zabraniający „spamu”, sztucznego nabicia, udziału w rynku sztucznego nabijania, programów naruszających zasady jakichkolwiek stron, phishingu i jego prób.
- Dodano punkt z wyjaśnieniem możliwości złożenia apelacji w przypadku niezgody z zablokowaniem.
- Dodano wymóg dla właścicieli repozytoriów, w których w ramach badań bezpieczeństwa umieszczana jest potencjalnie niebezpieczna treść. Obecność takiej treści musi być wyraźnie wspomniana na początku pliku README.md, a w pliku SECURITY.md powinny być podane dane kontaktowe do kontaktu. Wskazano, że ogólnie GitHub nie usuwa exploitów opublikowanych wraz z badaniami bezpieczeństwa dla już ujawnionych podatności (nie 0-day), ale zastrzega sobie prawo do ograniczenia dostępu, jeśli uzna, że istnieje ryzyko wykorzystania tych exploitów do rzeczywistych ataków i w służbie wsparcia GitHub wpłynęły skargi dotyczące użycia kodu do ataków.
Źródło: opennet.ru
