r   e   k   l   a   m   a
r   e   k   l   a   m   a

Wstępniak na nowy tydzień: bezpieczne okna to otwarte okna?

Strona główna AktualnościDOBREPROGRAMY

W ostatnich tygodniach już dwukrotnie badacze z google'owego Projektu Zero ujawnili luki w Windows, zanim Microsoft zdołał przygotować i wydać do nich łatki. 90 dni, jakie w ramach tej inicjatywy przyznaje się producentowi oprogramowania, najwyraźniej nie wystarczyło. Sporo gromów z tej okazji spadło na Google, oskarżone o to, że robi to co dobre dla siebie, a niekoniecznie dobre dla użytkowników. Znaleźli się i tacy, którzy pochwalili publiczne ujawnianie luk, uniemożliwiające zamiatanie problemów pod dywan. Nie jest łatwo to ocenić, szczególnie w czasach, gdy sam prezydent Stanów Zjednoczonych wypowiada się o bezpieczeństwie w sposób bardzo dwuznaczny.

To już nie słodkie lata 90, kiedy błędy w oprogramowaniu można było naprawiać latami, albo w ogóle. Świat nam przyspieszył i Microsoft (a także inni producenci, ale Microsoft w szczególności, z wiadomych względów) nie będzie mógł liczyć na taryfę ulgową ani u whitehatów ani u blackhatów. 90 dni okresu łaski oferowane przez Projekt Zero to i tak bardzo dużo. Podczas ostatniej konferencji Linux.conf.au, Linus Torvalds przypomniał, że na liście kernel security na przygotowanie łatki daje się pięć dni roboczych. Czemu więc takie „odpowiedzialne ujawnienia” prowadzą do awantur, oskarżeń o narażanie użytkowników, a niekiedy nawet straszenia prawnikami?

Wydaje mi się, że w grę wchodzi z jednej strony egoizm i duma badaczy, z drugiej spychologia, stosowana przecież w każdej organizacji. Pożądanie sławy, nawet złej (ale przeliczalnej na pieniądze) sławy musi skłaniać do ujawniania luk, tak szybko jak to tylko możliwe, z dorobionym do tego ideologicznym zapleczem „odpowiedzialnego” ujawnienia. Z drugiej strony firmy software'owe nie chcą, albo i nie potrafią angażować się w kosztowne i nieprzyjemne badania bezpieczeństwa swoich produktów, więc oskarżanie badaczy o nieodpowiedzialność, zamiatanie spraw pod dywan lub straszenie prawnikami to reakcje zrozumiałe. Tyle przynajmniej, jeśli chodzi o to, co dzieje się w tej sprawie na powierzchni. Sprawy związane z czarnym rynkiem exploitów, w który zaangażowani są przecież nie tylko zawodowi blackhaci, ale też jawnie działające firmy i agencje wywiadowcze wielu państw, to zupełnie inna para kaloszy.

r   e   k   l   a   m   a

Wiele można zarzucić otwartoźródłowemu oprogramowaniu, ale przynajmniej w kwestii rozwiązywania problemów z bezpieczeństwem spisuje się ono znacznie bardziej przyzwoicie, niż oprogramowanie zamknięte, własnościowe. Nawet jeśli opowieść o milionie oczu, patrzących na kod źródłowy i dostrzegających w nim odpowiednio wcześnie błędy jest w czasach ogromnie złożonego oprogramowania już tylko mitem (co widzi milion oczu patrzących na milion linii nieznanego sobie wcześniej kodu?), to i tak doczekało się ono znacznie lepszych rozwiązań instytucjonalnych. Przypomnę tu choćby inicjatywę Core Infrastructure, fundowaną przez takie firmy jak IBM, Intel, VMware, Cisco, ale też Microsoft i Adobe – choć zasilana przez korporacyjne pieniądze, w rzeczywistości sterowana jest przez niezależnych programistów, naukowców i ekspertów (m.in. słynnego Bruce'a Schneiera). Pieniądze z Core Infrastructure trafiają do najważniejszych projektów Open Source, napędzających kluczową infrastrukturę informatyczną świata, by pomóc w ich rozwoju i wzmacnianiu bezpieczeństwa.

W ten sposób Core Infrastructure pozwala przejść od podejścia reaktywnego, w którym działa się w odpowiedzi na sytuacje kryzysowe, do podejścia proaktywnego, w którym identyfikuje się problemy, zanim one jeszcze wystąpią. O jakim jednak proaktywnym podejściu do bezpieczeństwa można mówić w odniesieniu do zamkniętego oprogramowania, gdzie decyzje obarczone są z konieczności organizacyjną inercją i cierpią na zależność od aktualnej polityki firmy?

Może więc Microsoft, zamiast narzekać na badaczy Google, zastanowiłby się nad jedną, ale za to fundamentalną kwestią – czemu w ogóle Windows jest zamkniętym systemem? Czy w jądrze NT znajdują się tak wielkie tajemnice, że ich poznanie dałoby konkurencji władzę nad światem? Czy upublicznienie kodu sprawiłoby, że każdy by sobie sam potajemnie kompilował nielicencjonowane kopie? A może po prostu kod jest tak brzydko napisany, że w Redmond po prostu się go wstydzą? Skoro Windows napędza kluczową infrastrukturę planety, na czele z systemami sterowania piecami hutniczymi, nie może być traktowane tak nieodpowiedzialnie. Rosnąca złożoność oprogramowania sprawia, że rośnie też powierzchnia ataków, a Microsoft, z zasobami jakie posiada, najwyraźniej nie radzi sobie z tym zbyt dobrze.

Tu jest jakaś historyczna szansa dla Satyi Nadelli. Zamiast utrudniać dostęp do informacji, jak zrobiono to ostatnio, kończąc z darmowymi zapowiedziami biuletynów bezpieczeństwa, powinien w trosce o użytkowników Windows otworzyć kod systemu, a przynajmniej jego kluczowych komponentów, choćby w stylu, jaki praktykuje Apple (gdzie jądro Xnu i uniksowy fundament systemu Darwin są w pełni otwarte). No chyba, że Biały Dom na to nie pozwala – ale to znów inna para kaloszy.

Tyle na temat bezpieczeństwa i Windows. A co w dobrychprogramach? Pasjonaci już wiedzą – trwa druga tura naboru na współpracowników. Liczymy na to, że już do końca tego tygodnia będziemy mogli włączyć ich do pracy redakcji. Przyniesie to nietrywialne zmiany, ale o tym już następnym razem.

Korzystając z okazji, zaproszę jeszcze Czytelników z Wrocławia na rozpoczynający się dzisiaj GeekWeekWro, któremu patronuje nasz portal – interesującą inicjatywę głównie dla zainteresowanych programowaniem, ale chyba nie tylko. Wszystkich zaś oczywiście zapraszam do kolejnego, ciekawego tygodnia z dobreprogramy.pl.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.