Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



24.05.2022

Nowe możliwości w zakresie...

VMware rozszerza ofertę zabezpieczeń end-to-end dla obciążeń cloud-native poprzez ochronę...
24.05.2022

Zarządzanie kluczami

IBM przedstawił nowe rozwiązanie do zarządzania kluczami w wielu chmurach, oferowane jako...
24.05.2022

Ochrona przed zagrożeniami

ESET wprowadził nowe wersje swoich produktów biznesowych do ochrony stacji roboczych,...
24.05.2022

Value Stream Management

Micro Focus zaprezentował nową platformę do zarządzania strumieniem wartości VSM (ang....
24.05.2022

Unijna decyzja Value Stream...

Komisja rynku wewnętrznego i ochrony konsumentów Parlamentu Europejskiego poparła...
24.05.2022

Nowy laptop Dynabooka

Sprzęt waży 1,45 kg, a jego grubość to 17,8 mm. Jest odporny na czynniki zewnętrzne, gdyż...
24.05.2022

Przepływ pracy

QNAP oferuje model TS-435XeU wykorzystujący procesor Marvell OCTEON TX2 CN9131 2,2 GHz z...
24.05.2022

Wideo bez wstrząsów

Kamera stałopozycyjna firmy Axis Communications służy do monitoringu miejsc zagrożonych...
24.05.2022

Akceleratory dla naukowców

Firma AMD ogłosiła wprowadzenie do sprzedaży opartych na architekturze AMD CDNA 2...

Zatrute open source

Data publikacji: 03-02-2022 Autor: Maciej Olanicki

Powiedzieć, że przed oprogramowaniem open source stoją dziś duże wyzwania, to powiedzieć tyle, co nic. Wraz ze wzrostem popularności tego zjawiska (czy jak wolą niektórzy – idei) pojawiły się nowe zagrożenia charakterystyczne w zasadzie wyłącznie dla wolnego oprogramowania. Liczne ich przykłady mogliśmy odnotować także w ciągu ostatnich miesięcy.

 

Zapewne wiele satysfakcji czuli twórcy wolnego oprogramowania, gdy po latach rządów Steve Ballmera nadeszła epoka Satyi Nadelli, a Microsoft ogłosił swoją bezgraniczną niemal miłość do Linuksa. Oczywiście wciąż pozostaje to przełomowym momentem w historii tej korporacji i to nie tylko za sprawą transpozycji z firmy świadczącej produkty i usługi przede wszystkim na rynku konsumenckim na dostawcę gigantycznej usługi chmurowej wykorzystywanej przede wszystkim przez inne firmy. Microsoft daje bowiem bardzo namacalne dowody swojej miłości, zwłaszcza deweloperom, którzy dziś mogą korzystać z wielu narzędzi, bibliotek i frameworków za darmo dzięki otwarciu ich źródeł.


Jednak twierdzenie, że ta miłość Microsoftu jest bezinteresowna, byłoby naiwne, wszak mowa o jednej z największych korporacji IT, której funkcjonowanie ma w pierwszej kolejności zadowalać licznych udziałowców rozsianych po całym świecie. Rzecz jasna nie tylko Microsoft wykonał wspomnianą woltę i dziś trudno sobie wyobrazić funkcjonowanie największych usług Amazona czy Google'a bez wykorzystywania niemal na każdym etapie prac społeczności open source. W skrajnych przypadkach mowa wręcz o opakowaniu wolnego oprogramowania marką i sprzedawaniu go jako własnego w modelu SaaS.


Ten ogromny wzrost popularności i zainteresowania wolnym oprogramowaniem przerodził się w wiele nowych zagrożeń zarówno dla samego światka open source, jak też bezpieczeństwa rozumianego całkiem dosłownie. Warto przyjrzeć się bliżej temu zagadnieniu, zwłaszcza że przykładów nie brakuje.


> Superskalarność zagrożeń


Niemal co kilka tygodni pojawiają się doniesienia o krytycznych podatnościach we wszelkiej maści komponentach open source rozwijanych często latami przez wiele niezależnie pracujących od siebie developerów, organizujących się na grupach dyskusyjnych. I jeszcze kilkanaście lat temu nie stanowiłoby to takiego problemu jak dziś. Ot, odnotowano by, że komponent wykorzystywany np. przez opensource’owy system operacyjny niektórych routerów jest dziurawy, a następnie problem zostałby kolektywnie rozwiązany i opublikowana zostałaby aktualizacja oprogramowania, którą w niektórych przypadkach zapewne udałoby się wymusić. Słowem, cała procedura nie różniłaby się szczególnie od tego, jak przebiega proces łatania oprogramowania własnościowego. Ale tak było kiedyś.


Dziś szeroko pojęte wolne oprogramowanie jest dosłownie wszędzie – od smartfonów po najbardziej zaawansowane chmury obliczeniowe oferowane i wykorzystywane przez wierchuszkę listy Fortune 500. Jeśli np. w wolnej bibliotece odnaleziona zostanie aktywnie wykorzystywana podatność, straty mogą automatycznie skalować się do trudnych do wyobrażenia sobie kwot. Ponadto często dochodzi także do tego, że duże usługi budowane są z użyciem forków popularnych narzędzi open source, które od pewnego momentu rozwijane są już nie przez społeczność, lecz przez dostawcę usługi. W przypadku mniejszych projektów może dochodzić do sytuacji, w której poprawki wdrażane w głównym branchu nie zawsze trafiają do forka, co może prowadzić do katastrofy. Podobne praktyki często stosuje się mniej lub bardziej umyślnie z popularnymi systemami CMS czy silnikami forów dyskusyjnych w rodzaju Discourse’a. Liczba autorskich modyfikacji jest tak duża, że administratorzy zwlekają z aktualizacją, licząc na to, że do naruszenia bezpieczeństwa nie dojdzie.


> Problematyczne zależności


Doskonałym przykładem, nie bójmy się tego słowa, katastrofy tego rodzaju jest ujawniona pod koniec 2021 roku podatność Log4j. Wystarczyła krytyczna podatność pojedynczej biblioteki Java, aby postawić na nogi w zasadzie cały świat IT. Podatność pozwalała bowiem na zdalne wykonanie kodu i przejęcie kontroli nad całą aplikacją dzięki wprowadzeniu np. w formularzy odpowiednio spreparowanych danych. Te były przez bibliotekę błędnie przetwarzane i prowadziły do RCE. Problem został dość sprawnie rozwiązany, lecz to nie w jego wystąpieniu tkwi problem, lecz w popularności Log4j. Jest ona bowiem używana przez znaczną część developerów Java, a co zatem idzie – przekłada się na ogromną liczbę podatnych usług, które Log4j wykorzystują jako zależność. Dziura w Log4j zarażała zarówno aplikacje webowe, jak i lokalne i wymusiła wydanie odpowiednich instrukcji i zaleceń w zasadzie przez wszystkich liczących się dziś graczy – Google, Microsoft, Vmware, Amazon i długo by jeszcze wymieniać. To jednak nie najpopularniejsze i aktywnie rozwijane usługi są w tym przypadku problemem, lecz aplikacje legacy, które być może nigdy nie doczekają się aktualizacji biblioteki i już zawsze będą narażać na niebezpieczeństwo swoich użytkowników.

 

Krytyczne podatności istnieć będą zawsze, ale to niejedyny przykład sytuacji, w której błąd w jednym wolnym komponencie naraża na szwank bezpieczeństwo milionów użytkowników. Czasem może bowiem chodzić o świadomy sabotaż. Do takiej sytuacji doszło przecież w kwietniu ub.r., kiedy wykryto, że pracownicy naukowi Uniwersytetu w Michigan świadomie i z premedytacją wprowadzali wadliwe aktualizacje do jądra Linux, czyli do oprogramowania, które mogło finalnie dotrzeć na ogromną część wszystkich urządzeń elektronicznych, jakie działają aktualnie na świecie. Greg Kroah-Hartman i Leon Romanovsky wielokrotnie wprowadzali do kodu Linuksa błędy w celu, jak sami twierdzili, przeprowadzania eksperymentu. Ich działanie miało bowiem stać się przyczynkiem do badań nad tym, jak podatne jest oprogramowanie open source na podobne złośliwe działania. Ich praktyka została jednak dostrzeżona przez społeczność rozwijającą jądro, a sami naukowcy (choć wspomniana społeczność zapewne nazwałaby ich zupełnie inaczej) zapewnili swojej uczelni całkowitą blokadę możliwości prac nad Linuksem.

 

[...]

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"