JavaOne 2007 - otwarte możliwości

Log4j, czyli dziurawy świat open source bez budżetu

Od mniej więcej dwóch dni internet płonie, a administratorzy są wzywani na nadgodziny lub weekend by łatać krytyczną lukę w powszechnie używanej w aplikacjach Java bibliotece Log4j. Służy ona za interfejs do raportowania zdarzeń do systemowych lub aplikacyjnych logów, bez konieczności samodzielnego dbania o dostęp do nich. Luka umożliwia zdalne wykonanie kodu na prawach aplikacji.

Jak wykorzystać niniejszą podatność? Trzeba wysłać do aplikacji złośliwe żądanie, które zostanie zalogowane przez Log4j w nieprzetworzonej postaci. Przejście żądania "przez" bibliotekę poskutkuje, zamiast zapisania go do logów, wykonaniem kodu. A więc jeżeli aplikacja stosuje Log4j (w wersji 2.x), jeszcze nie musi to oznaczać że jest podatna. Ale jeżeli istnieje taka część żądania, która ląduje w logach niepołamana, niezaciemniona i "niewy-escape-owana", aplikacja jest zagrożona. Takich aplikacji jest... mnóstwo. Są dosłownie wszędzie. Wszak "trzy miliardy urządzeń stosują Javę", jak zwykł mawiać Oracle.

Załatane, ale gdzie?

Jest już, oczywiście, łatka, ale wiele aplikacji rozprowadzanych jest razem z runtimem. To doskonałe podejście ułatwiające rozwój oprogramowania, uodparniające przy okazji na problemy z zależnościami. Ale w przypadku zastosowań lub kalendarzy wydawniczych, gdzie aktualizacje przeprowadzane są rzadko, będzie to oznaczać dziurawą bibliotekę obecną nieprzyzwoicie długo.

A to jest z tych problemów, który naprawdę szybko powinien zniknąć. Problem jest na tyle poważny, że jest o nim głośno w niespodziewanych miejscach: Microsoft aktualizuje Minecrafta i wydaje artykuł na temat problemu. Kaspersky opisuje poziom ryzyka. Docker silnie zaleca administratorom przegląd swoich kontenerów pod kątem Log4j. VmWare wydaje tuziny aktualizacji. Okta naprawia swoje narzędzia zapewniające bezpieczne... logowanie (no pun intended).

Niewdzięczne zajęcie

Podatność otrzymała identyfikator CVE-2021-44228 i pieszczotliwą nazwę "Log4Shell" (nie mylić z Left 4 Dead). Nieoficjalna lista podatnego oprogramowania ma 18 stron i rośnie. Weekend w infosec jest pracowity, także dla autora niniejszej notatki. Powstaje zatem pytanie - jak to jest możliwe? Jakim cudem problem z jedną biblioteką wywołuje pożar na taką skalę?

Odpowiedź jest prosta: to powtórka z roku 2014 i podatności Heartbleed. Olbrzymia dziura w OpenSSL istniała niezauważona przez długi czas ze względu na to, że projekt był chronicznie niedofinansowany. Etatowo, w pełnym tego słowa znaczeniu, nie pracował nad nim nikt. Problem był na tyle duży, że OpenBSD dokonało nawet forka: LibreSSL. A na OpenSSL stoi niemal cały internet.

Jest kilka takich programów. OpenSSL, cURL i Perl to tylko kilka pierwszych przykładów z brzegu. W tym tygodniu okazało się, że do zbioru zapuszczonych programów należy także Log4j. Jego opiekunem jest Fundacja Apache. Biblioteka nie miała jednak pełnoetatowych deweloperów. Nie jest to jedyny taki projekt w Fundacji.

Wstrząs związany z Heartbleed doprowadził do sypnięcia groszem w stronę OpenSSL. Najwyraźniej jest więcej projektów, które pilnie tego potrzebują. Jednak jak stworzyć ich listę, w którym miejscu postawić granicę i - przede wszystkim - skąd wziąć na to pieniądze?

Zastosowanie narzędzi Open Source oraz Spring Framework do budowania aplikacji webowych

Streszczenie:

W pracy opisano sposób tworzenia aplikacji webowej przy wykorzystaniu technologii Java EE wraz ze Spring Framework. W pierwszym etapie przedstawiono proces wytwarzania oprogramowania w języku Java. Następnie dokonano przeglądu dostępnych narzędzi typu Open Source wspierających tworzenie aplikacji webowej uwzględniając: przechowywanie oraz kontrolę wersji kodu, budowanie aplikacji, kontrolę poprawności, jakości kodu, zapewnienie ciągłej integracji kodu. W dalszym etapie opracowano koncepcję aplikacji wykorzystującej opisywane wyżej narzędzia i technologie oraz dokonano ich porównania. The thesis aims to describe creating the web application which uses Java EE and Spring Framework technologies. It begins with a presentation how to create software in Java programming language. In the next chapters, the available tools assisting in designing web applications (such as Open Source) have been reviewed. The following aspects have been taking into account: storage and control of a code version, building an application, control of code’s correctness, quality of a code and assurance of continuous code integration. Furthermore, the tools and technologies described above have been applied in the concept of the application and their applicability have been compared.

JavaOne 2007 - otwarte możliwości

Sun ogłosił udostępnienie OpenJDK jako open source i praktycznieJava została całkowicie otwarta. Firma przedstawiła również pierwsze elementy nowego języka programowania JavaFX Script.

Sun ogłosił udostępnienie OpenJDK jako open source i praktycznieJava została całkowicie otwarta. Firma przedstawiła również pierwsze elementy nowego języka programowania JavaFX Script.

Rich Green, wiceprezes SUN Microsystems ds. oprogramowania, wysłał symboliczny list ogłaszający środowisku OPEN SOURCE, że oprogramowanie narzędziowe OpenJdk (Java Development Kit??) jest już dostępne.

Na oczach 15 tys. uczestników konferencji JavaOne 2007 Rich Green, wiceprezes Sun Microsystems ds. oprogramowania wysłał symboliczny e-mail ogłaszający środowisku open source, że oprogramowanie narzędziowe OpenJDK (Java Development Kit) jest już dostępne. Reakcja środowiska open source była natychmiastowa, zaledwie dwie godziny wystarczyły, aby Gentoo Linux skompilowało i dołączyło OpenJDK do swojej dystrybucji. W ciągu pierwszych 24 godzin deweloperzy Fedora Linux zgłosili łatę dotyczącą kompilacji i skompilowali OpenJDK w swoim środowisku, a programiści GNU/Classpath zaproponowali dwie poprawki dotyczące renderowania grafiki. Tym samym Sun udowodnił, że wie jak wykorzystać siłę open source. Rozumie potrzeby środowiska i potrafi z nim współpracować. Podejmuje odważne decyzje, które na pierwszy rzut oka trudno uzasadnić ekonomicznie. Tymczasem te posunięcia przekładają się na 20-proc. roczny wzrost przychodów.

OpenJDK będzie rozwijane jako projekt open source. Powołany został tymczasowy zarząd OpenJDK składający się z trzech przedstawicieli środowiska open source i dwóch z Sun Microsystems, który w pierwszej kolejności ma ustalić zasady rządzące procesem wytwarzania - podejmowania decyzji w zakresie funkcjonalności, przyjmowania łat i inne potrzebne reguły. Struktura jest potrzebna, aby zarządzać projektem tego rozmiaru.

Jakie skutki przyniesie otwarcie JDK? Czy pojawią się inne wersje? Zapewne tak, problem w tym, aby zapewnić kompatybilność pomiędzy różnymi dystrybucjami JDK. Dlatego Sun wybrał dla OpenJDK licencję GPLv2. Konieczność udostępnienia zmodyfikowanego kodu ma uchronić środowisko przed niestandardowymi odgałęzieniami. Ponadto Sun udostępni TCK - narzędzia do sprawdzania zgodności ze specyfikacją. Jeśli warunek kompatybilności będzie spełniony, różnorodność może przynieść wiele dobrego.

F3 = Java FX

Dużym wydarzeniem na JavaOne było przedstawienie pierwszego elementu nowego języka Java FXScript oraz Java FXMobile. Wcześniej technologia ta pojawiła się w sieci pod nazwą F3 (Form Follows Function) na blogu Chrisa Oliviera. Java FXScript jest nowym językiem skryptowym dedykowanym tworzeniu bogatych interfejsów graficznych. Jego siła tkwi w prostej składni pozwalającej wykorzystać możliwości drzemiące w Java2D. Dotychczas deweloperzy byli skazani na AWT, Swinga, czy SWT, a praca z nimi nie należała do przyjemności. Projektanci interfejsów mogli jedynie marzyć o wyrafinowanych efektach, gdyż tworzenie ich było zbyt trudne i czasochłonne. JavaFX pozwala na wykorzystanie gotowych kontrolek ze Swinga i poddanie ich w prosty sposób dowolnym transformacjom w Java2D API.

Potencjał drzemiący w tej technologii być może pozwoli Javie w przyszłości rywalizować np. z produktami Adobe. Jest to jednakże przyszłość, i to odległa. Potrzebne są narzędzia, które pozwolą projektantom pracować w graficznym środowisku podobnym do Flasha. Niezbędna będzie również kompilacja do kodu binarnego - obecnie wymagany jest interpreter, którego objętość wg twórców przekracza 700 KB, choć pakiet javafxrt.jar obecny we wtyczce do Eclipse zajmuje niemalże 2 MB. Ten fakt zdecydowanie wyklucza zastosowanie tej technologii na wielu mniejszych stronach WWW. Pytanie brzmi, dlaczego Sun zdecydował się zaprezentować tak niedopracowaną technologię? Odpowiedź jest prosta - firma zmieniła podejście do wytwarzania kodu, zwracając się ku środowisku wolnego oprogramowania. W tym modelu nie można siedzieć we własnej piaskownicy z własnymi zabawkami, ale trzeba się nimi jak najszybciej dzielić. Przynosi to wymierny efekt w postaci informacji zwrotnej, takiej jak zgłoszenia błędów, pojawianie się poprawek i rozszerzeń. Krok ten należy również rozpatrywać w kategoriach marketingowych. Sunowi zależy na budowaniu jak największego środowiska i próbuje to osiągnąć również poprzez błyszczące gadżety. Nie ulega jednakże wątpliwości, że natywne, uniwersalne rozwiązanie do tworzenia bogatych interfejsów jest potrzebne. Sun musi jednak jak najszybciej dostarczyć narzędzi, co obiecuje już za pół roku.

JavaFX Mobile

Sun zwrócił uwagę na ogromny potencjał urządzeń mobilnych. Już teraz jest na świecie ponad 2 mld telefonów komórkowych zdolnych uruchamiać kod Javy. Dlatego też na JavaOne wiele mówiło się o "wielofunkcyjnych urządzeniach podłączonych do Internetu". Rozmaite firmy prezentowały narzędzia do tworzenia aplikacji, zestawy komponentów oraz same urządzenia mobilne.

Pewnie dlatego pierwszy element nowego języka JavaFX Mobile jest dedykowany urządzeniom przenośnym. Ma to być panaceum na pofragmentowany mobilny świat. Czy hasło "write once run everywhere" ma szansę się ziścić? Wydaje się, że te wszystkie małe urządzenia są tak różne, że nie jest to możliwe. Nikt nie zaprzecza jednak, że taki standard, jak JavaFX jest potrzebny. Sun musi próbować skłonić producentów sprzętu do unifikacji. Silnym bodźcem jest potrzeba dużej ilości oprogramowania. JavaFX Mobile jest kompletnym stosem oprogramowania. Jako jądro wykorzystuje Linuxa, uzupełnionego zestawem frameworków dotyczących multimediów, grafiki, komunikacji, PIM i telefonii. Wszystko to jest dostępne poprzez API z Javy (i tylko z Javy). Dodatkowo skrypty JavaFX pozwalają łatwo tworzyć zaawansowane interfejsy.

Czy rzeczywiście jest to nowatorskie rozwiązanie? Microsoft dostarcza Windows na urządzenia mobilne od lat i oferuje platformę .Net dedykowaną sprzętowi tej klasy. Sun zdecydował się jednak na darmowe udostępnienie wszystkich narzędzi. Firma od lat powtarza, że istotne znaczenie ma społeczność budowana od ćwierć wieku, a którą Sun otwierając produkty, wzmocnił i poszerzył. Bezpośrednie zyski firma będzie czerpać z umów licencyjnych z producentami sprzętu.

Co dalej z Javą SE?

W przyszłym roku ma się pojawić Java SE (Standard Edition) w wersji 7. Sun wprowadza superpakiety, które mają rozwiązać problem publicznych artefaktów, zwiększając możliwości hermetyzacji. Za pomocą dodatkowego pliku będzie można poinstruować kompilator, które z elementów - pakietów, podpakietów czy klas - w budowanym superpakiecie mają być widoczne dla kodu znajdującego się poza nim.

Hermetyzacja będzie również działała na etapie wykonania kodu, gdyż informacja o superpakietach będzie wkompilowana w postaci dodatkowego atrybutu w klasie. Pozwoli to lepiej ukryć szczegóły implementacji w dużych bibliotekach. Przedstawiciele Suna wspomnieli również o domknięciach jako kolejnej ważnej nowości w Java SE 7. Ta konstrukcja pozwala na tworzenie callbacków bez konieczności wykorzystania interfejsów, definiowania anonimowych klas i tworzenia ich obiektów.