Różności i nowinki technologia

Przepełnienie bufora, naruszenie licencji i zły kod: bliskie wyzwanie FreeBSD 13

Wydaje się, że główny zespół programistów FreeBSD w większości nie widzi potrzeby aktualizowania swoich procedur przeglądu i zatwierdzania.
Powiększać / Wydaje się, że główny zespół programistów FreeBSD w większości nie widzi potrzeby aktualizowania swoich procedur przeglądu i zatwierdzania.

Aurich Lawson (po KC Green)

Na pierwszy rzut oka Matthew Macy wydawał się całkiem rozsądnym wyborem przeniesienia WireGuard do jądra FreeBSD. WireGuard to zaszyfrowany protokół tunelowania punkt-punkt, część tego, co większość ludzi uważa za „VPN”. FreeBSD to system operacyjny podobny do Uniksa, który obsługuje wszystko, od routerów Cisco i Juniper po stos sieciowy Netflix, a Macy miała duże doświadczenie w zespole programistów, w tym pracę nad wieloma sterownikami sieciowymi.

Więc kiedy Jim Thompson, dyrektor generalny Netgate, który produkuje routery oparte na FreeBSD, zdecydował, że nadszedł czas, aby FreeBSD cieszyło się tym samym poziomem obsługi WireGuard w jądrze, co Linux, skontaktował się z Macy’m, aby zaoferować kontrakt. Macy przeportowałby WireGuard do jądra FreeBSD, gdzie Netgate mógłby następnie użyć go w popularnej dystrybucji routera pfSense firmy. Umowa została zaoferowana bez terminów i kamieni milowych; Macy miał po prostu wykonać zadanie według własnego harmonogramu.

Biorąc pod uwagę poziom doświadczenia Macy – w szczególności kodowanie jądra i stosy sieciowe – projekt wyglądał jak wsad. Ale wszystko poszło nie tak prawie natychmiast. Twórca WireGuard, Jason Donenfeld, nie słyszał o projekcie, dopóki nie pojawił się na liście mailingowej FreeBSD, a Macy nie wydawała się zainteresowana pomocą Donenfelda, gdy została zaoferowana. Po około dziewięciu miesiącach pracy w niepełnym wymiarze godzin, Macy umieścił swój port – w dużej mierze niesprawdzony i niedostatecznie przetestowany – bezpośrednio w sekcji HEAD repozytorium kodu FreeBSD, gdzie zaplanowano włączenie go do FreeBSD 13.0-RELEASE.

To nieoczekiwane zobowiązanie podniosło stawkę dla Donenfelda, którego projekt zostałby ostatecznie oceniony na podstawie jakości dowolnego wydania produkcyjnego pod nazwą WireGuard. Donenfeld zidentyfikował liczne problemy z kodem Macy’ego, ale zamiast sprzeciwić się zwolnieniu portu, Donenfeld zdecydował się je naprawić. Współpracował z deweloperem FreeBSD Kylem Evansem i Mattem Dunwoodie, deweloperem OpenBSD, który pracował nad WireGuardem dla tego systemu operacyjnego. Ta trójka zastąpiła prawie cały kod Macy w szalonym tygodniowym sprincie.

To poszło bardzo źle w przypadku Netgate, który sponsorował pracę Macy. Netgate już pobrał kod beta Macy z kandydata do wydania FreeBSD 13 i umieścił go w produkcji w wydaniu pfSense 2.5.0. Modernizacja wózka widłowego wykonana przez Donenfelda i współpracowników – wraz z ostrą charakterystyką kodu Macy’ego przez Donenfelda – postawiła firmę przed poważnym problemem PR.

Publiczna reakcja Netgate obejmowała oskarżenia o „irracjonalne nastawienie do mmacy i Netgate” oraz nieodpowiedzialne ujawnienie „szeregu exploitów zero-day” – pomimo niemal równoczesnej deklaracji Netgate, że nie istnieją żadne luki w zabezpieczeniach.

Ta bojowa reakcja Netgate’a wzbudziła wzmożoną kontrolę z wielu źródeł, które ujawniły zaskakujące elementy przeszłości Macy’ego. On i jego żona Nicole zostali aresztowani w 2008 roku po dwóch latach spędzonych na próbie nielegalnej eksmisji lokatorów z małego apartamentowca w San Francisco, który kupili.

Macys próbowali zmusić najemców do opuszczenia budynku, obejmując przecinanie belek stropowych, aby budynek nie nadawał się do zamieszkania przez ludzi, wycinanie dziur bezpośrednio w podłogach mieszkań najemców oraz wykuwanie niezwykle groźnych e-maili, które wyglądały, jakby pochodziły od samych najemców. Para uciekła do Włoch, aby uniknąć oskarżenia, ale ostatecznie zostali poddani ekstradycji z powrotem do Stanów Zjednoczonych – gdzie przyznali się do mniejszej liczby przestępstw i spędzili po cztery lata i cztery miesiące.

Nic dziwnego, że historia Macy’ego jako właściciela lokalu prześladowała go zawodowo – co przyczyniło się do jego braku uwagi na skazany na zagładę port WireGuard.

„Nie chciałem nawet wykonywać tej pracy” – powiedziała w końcu Macy. „Byłem wypalony, spędziłem wiele miesięcy z zespołem po COVID … Cierpiałem przez lata werbalnego znęcania się ze strony niedziałających i pół-niewykonujących projektu, którego jedyną ważną rzeczą jest to, że oni nie są nie przestępcami. Skorzystałem z okazji, aby opuścić projekt w grudniu … po prostu poczułem moralny obowiązek [the WireGuard port] za linią mety. Więc będziesz musiał mi wybaczyć, jeśli moje ostatnie wysiłki były trochę bez przekonania. “

To przyznanie się do odpowiedzi, dlaczego tak doświadczony, wykwalifikowany programista może tworzyć gorszy kod – ale rodzi znacznie większe pytania dotyczące procesów i procedur w samym komitecie rdzenia FreeBSD.

W jaki sposób tak wiele sub-par kodu sprawiło, że stał się głównym systemem operacyjnym o otwartym kodzie źródłowym? Gdzie był przegląd kodu, który powinien go zatrzymać? I dlaczego zarówno główny zespół FreeBSD, jak i Netgate wydawały się bardziej skoncentrowane na fakcie dyskredytowania kodu niż na jego rzeczywistej jakości?

Jakość kodu

Pierwsza kwestia dotyczy tego, czy kod Macy rzeczywiście miał istotne problemy. Donenfeld powiedział, że tak, i zidentyfikował kilka głównych problemów:

  • Spać, aby złagodzić warunki wyścigu
  • Funkcje walidacyjne, które po prostu zwracają wartość true
  • Katastrofalne luki kryptograficzne
  • Fragmenty protokołu wg. Nie zostały zaimplementowane
  • Paniki jądra
  • Obejścia bezpieczeństwa
  • Instrukcje printf głęboko w kodzie kryptograficznym
  • „Spektakularne” przepełnienia bufora
  • Labirynty Linuksa → ifdefs FreeBSD

Ale Netgate argumentował, że Donenfeld przesadził ze swoją negatywną oceną. Twierdzili, że oryginalny kod Macy nie był taki zły.

Pomimo tego, że nie miał żadnych programistów jądra na swoim miejscu, Ars był w stanie zweryfikować przynajmniej część twierdzeń Donenfelda bezpośrednio, szybko i bez pomocy z zewnątrz. Na przykład znalezienie funkcji walidacji, która po prostu zwróciła wartość true – i printf oświadczenia ukryte głęboko w pętlach kryptograficznych – nie wymagały niczego bardziej skomplikowanego niż grep.

Pusta funkcja walidacji

Aby potwierdzić lub zaprzeczyć twierdzeniu o pustej funkcji walidacji – takiej, która zawsze „zwraca prawdę” zamiast faktycznie sprawdzać poprawność przekazanych do niej danych – wyszukaliśmy wystąpienia return true lub return (true) w Macy’s if_wg kod sprawdzony we FreeBSD 13.0-HEAD.

root@banshee:~/macy-freebsd-wg/sys/dev/if_wg# grep -ir 'return.*true' . | wc -l
21

Jest to wystarczająco mała liczba zwrotów, aby łatwo było je sprawdzić ręcznie, więc użyliśmy grep aby znaleźć te same dane, ale z trzema wierszami kodu znajdującymi się bezpośrednio przed i po każdym return true:

root@banshee:~/macy-freebsd-wg/sys/dev/if_wg# grep -ir -A3 -B3 'return.*true' .

Wśród ważnych zastosowań return true, odkryliśmy jedną pustą funkcję walidacji w module/module.c:

wg_allowedip_valid(const struct wg_allowedip *wip)
{

 return (true);
}

Prawdopodobnie warto wspomnieć, że ta pusta funkcja walidacji nie znajduje się na samym dole rozległej masy kodu—module.c jak napisano, to łącznie tylko 863 wierszy kodu.

Nie próbowaliśmy dalej ścigać użycia tej funkcji, ale wydaje się, że ma ona na celu sprawdzenie, czy źródło i / lub miejsce docelowe pakietu należy do WireGuarda allowed-ips list, która określa, które pakiety mogą być kierowane w dół danego tunelu WireGuard.

Zostaw komentarz

Maciek Luboński
Z wykształcenia jestem kucharzem , ale to nie przeszkadza mi pisać dla Was tekstów z wielu ciekawych dziedzin , których sam jestem fanem.Piszę dużo i często nie na tak jak trzeba , ale co z tego skoro tak naprawdę liczy się pasja.

Najlepsze recenzje

Video

gallery

Facebook