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


12.05.2022

Odszyfrowanie historii

Z inicjatywy prezesa IPN, dr. Karola Nawrockiego, powstało Biuro Nowych Technologii. Jego...
01.04.2022

Program partnerski

NGAGEFirma NFON, ogólnoeuropejski dostawca komunikacji głosowej w chmurze, ogłosił...
01.04.2022

SI w TFI PZU

Na platformie do inwestowania inPZU działa już nowa metoda identyfikacji tożsamości...
01.04.2022

Kooperacja w chmurze

To oparta na stworzonej przez NetApp technologii ONTAP i w pełni zarządzana przez...
01.04.2022

Nowe laptopy od Dynabook

Dynabook wprowadza do swojej oferty dwa laptopy z procesorami Intel Core 12. generacji,...
01.04.2022

Ryzen do stacji roboczych

AMD przedstawił nową gamę procesorów Ryzen Threadripper PRO 5000 serii WX.
31.03.2022

Serwery dla MŚP

Firma Lenovo wprowadziła nowe rozwiązania w zakresie infrastruktury IT Future Ready,...
31.03.2022

Innowacyjny kontroler SSD

Microchip zaprezentował nowe kontrolery SSD, które umożliwią obsługę napędów o pojemności...
31.03.2022

Wydajny jak Brother

Brother dodał do swojej oferty trzy nowe, atramentowe urządzenia wielofunkcyjne, które...

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.

 

[...]

Artykuł pochodzi z miesięcznika: IT Professional

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

.

Transmisje online zapewnia: StreamOnline

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