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...

Problem Y2K22

Data publikacji: 03-02-2022 Autor: Adam Kamiński

Noworoczny poranek nie dla wszystkich był czasem odpoczynku po sylwestrowym, całonocnym szaleństwie. W domach wielu administratorów IT rozdzwoniły się telefony zaniepokojonych użytkowników Microsoft Exchange – ich serwery pocztowe uległy awarii.


Wraz z przekraczaniem magicznej daty styku końca jednego roku i początku drugiego na światło dzienne wychodzi wiele nowych podatności i luk w zabezpieczeniach, które narażają krytyczne zasoby cyfrowe przedsiębiorstw na cyberzagrożenia. Nie uniknął tego również Microsoft. Gdy zegar wybił północ (00:00 UTC ) 1 stycznia 2022 r., niektóre wersje serwera pocztowego Microsoft Exchange w wariancie on-prem uległy awarii. Aktualizacja spowodowała blokowanie się wiadomości w kolejkach transportowych w lokalnych serwerach Exchange 2016 i Exchange 2019, w tym serwerów używanych przez klientów w trybie Exchange Hybrid. Rosnąca kolejka poczty wypełniała dyski, a kiedy plik mail.que osiągał maksymalną określoną wielkość, maile przepadały. Okazało się, że serwery nie były w stanie przetworzyć nowej daty, co oznaczało, że nie mogły przetwarzać poczty. Analitycy cyberbezpieczeństwa zauważyli ten problem, gdy zaplanowana poprawka umożliwiająca przetwarzanie nowej daty nie została dostarczona.

 

Luki te dotyczą lokalnych serwerów Microsoft Exchange, klienci Exchange Online są już chronieni i nie muszą podejmować żadnych działań.

 

> Nowa data, nowy problem

 

W czym tkwił problem? Format daty dla niektórych składników Exchange’a – w tym dla silnika filtrującego (Microsoft Filtering Engine) umożliwiającego skanowanie zawartości usługi przez program antywirusowy i reguły antyspamowe – przyjmuje zapis „YYMMDDHHmm”, co oznacza, że data 1 stycznia 2022 r. zgodnie z tym formatem miałaby postać 2201010000. Data jest konwertowana na podpisaną liczbę int32 i przechowywana w zmiennej typu long, a jej maksymalna wartość (czyli LONG_MAX) to 2147483647. Już w tym miejscu widać, gdzie leży problem – pojemność zmiennej long kończyła się na 2021 r. Kiedy komponent antywirusowy konwertuje datę do wspomnianego formatu na podpisaną liczbę 32-bitową, nowa wartość 2 201 010 001 przekracza maksymalną wartość long liczby int. Powoduje to przepełnienie liczb całkowitych, które zawieszało serwery Exchange, skutkując utknięciem e-maili w kolejkach transportowych lokalnych serwerów Exchange. Sprawdzanie wersji wykonywane względem pliku sygnatury powodowało z kolei awarię silnika malware, co również skutkowało zatrzymaniem wiadomości w kolejkach transportowych.

 

W przypadku wystąpienia tego problemu w dzienniku zdarzeń serwera Exchange widoczne były błędy, a konkretnie zdarzenia 5300:

 

Log Name: Application
Source: FIPFS
Logged: 1/1/2022 1:03:42 AM
Event ID: 5300
Level: Error
Computer: server1.contoso.com
Description: The FIP-FS "Microsoft" Scan Engine failed to load. PID: 23092, Error Code: 0x80004005. Error Description: Can't convert "2201010001" to long;


i zdarzenia 1106:


Log Name: Application
Source: FIPFS
Logged: 1/1/2022 11:47:16 AM
Event ID: 1106
Level: Error
Computer: server1.contoso.com
Description: The FIP-FS
Scan Process failed initialization. Error: 0x80004005. Error Details: Unspecified error.

 

Nowa data przyczyniła się do awarii skanera warstwy systemu plików (FIP-FS), co kładło usługę filtrującą. Jeżeli obiekt nie przeszedł przez cały proces, uznawany był za nieprzetworzony i lądował w rosnącej kolejce.

 

> Mitygowanie

 

Choć w 2022 r. może wydawać się to niewiarygodne, doraźnym rozwiązaniem problemu było czasowe wstrzymanie działania modułu antywirusowego w Exchange'u i wyłączenie skanowania AntiMalware poprzez Disable-Antimalwarescanning.ps1. 1/x. Wyłączenie skanera antymalware’owego w Exchange’u nie powinno wydawać się wielkim problemem, bo funkcja ta jest tylko dodatkiem do usługi pocztowej, a każde przedsiębiorstwo powinno być wyposażone w przeznaczone do tego rozwiązanie antymalware’owe, jednak zdumiewa to, że „wyłącz antywirusa” wciąż bywa rozwiązaniem. Co więcej brak połączenia z internetem również uchroniłby przed pobraniem aktualizacji i wystąpieniem awarii.

 

Na blogu zespołu Exchange’a już przed południem 1 stycznia pojawił się wpis o rozwiązaniu problemu. Microsoft oświadczył w nim, że problem powodujący blokowanie się wiadomości w kolejkach transportowych w lokalnych serwerach Exchange 2016 i Exchange 2019 został już rozwiązany. Z oświadczenia wynika, że dotyczy on wadliwego funkcjonowania sprawdzania daty wraz ze zmianą nowego roku i nie jest to awaria samego silnika antywirusowego, skanowania złośliwego oprogramowania lub problem związany z bezpieczeństwem. Serwery Edge Transport nie zostały dotknięte tą luką.

 

[...]

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"