Wprowadzenie do problemu / definicja luki
Pliki wsadowe .bat i .cmd są „starym” mechanizmem automatyzacji, ale w praktyce przez cały czas napędzają mnóstwo procesów: logon scripts, instalacje, naprawy, narzędzia helpdesku, taski w harmonogramie, procedury odzyskiwania czy operacje w środowiskach z ograniczonym dostępem do PowerShella.
Ich słabym punktem jest to, iż są tekstowe i łatwo je zmienić — a w pewnych scenariuszach atakujący może próbować podmienić zawartość skryptu w trakcie jego wykonywania (klasa problemów typu TOCTOU: time-of-check vs time-of-use). Microsoft właśnie testuje mechanizm, który ma ograniczyć ten wektor.
W skrócie
W najnowszych kompilacjach Windows 11 Insider Microsoft dodaje opcję uruchamiania BAT/CMD w bardziej „sztywnym” trybie:
- Skrypt wsadowy nie może zmienić się podczas wykonania (system ma go „zablokować” w trakcie uruchomienia).
- Gdy w środowisku działa Code Integrity, system ma wykonywać walidację podpisu tylko raz (zamiast narzutu „per instrukcja/linia” w skrypcie), co ma poprawić zarówno bezpieczeństwo, jak i wydajność.
- Funkcja jest opisywana jako kontrola dla administratorów oraz autorów polityk Application Control for Business.
Ważna uwaga: w źródłach pojawia się różne nazewnictwo wartości rejestru (szczegóły niżej) — to normalne na etapie Insider, ale trzeba to brać pod uwagę w testach i automatyzacji.
Kontekst / historia / powiązania
Zmiana została ogłoszona w kanałach Insider (m.in. wpis Windows Insider Blog) i jest komunikowana jako rozszerzenie kontroli dla:
- administratorów systemów (ustawienia lokalne, rejestr),
- autorów polityk App Control for Business (czyli praktycznie następcy/ewolucji podejścia WDAC w kierunku łatwiejszego zarządzania).
Drugi element układanki to Code Integrity oraz ochrona oparta o wirtualizację (HVCI / „Memory integrity”), które w wielu organizacjach są elementem twardych baseline’ów bezpieczeństwa. jeżeli CI jest włączone, Microsoft chce ograniczyć koszt weryfikacji podpisów podczas wykonywania dłuższych skryptów.
Analiza techniczna / szczegóły luki
1. „Locking” plików wsadowych podczas wykonania
Idea jest prosta: jeżeli BAT/CMD jest uruchomiony, system ma zapewnić, iż jego treść nie zmieni się w trakcie działania. Ma to utrudnić scenariusze, w których:
- skrypt startuje jako „zaufany” (lub podpisany),
- a następnie jest podmieniany „w locie” na złośliwą wersję, zanim dojdzie do wykonania dalszych poleceń.
W praktyce sprowadza się to do wprowadzenia bezpieczniejszego trybu przetwarzania, który „zamraża” wejście skryptu na czas jego wykonania.
2. Gdzie i jak to włączyć
Z komunikatów wynika, iż tryb da się włączyć:
- przez wartość w rejestrze w gałęzi Command Processor,
- oraz przez kontrolę w mechanizmie polityk aplikacyjnych (manifest/ustawienie dla autorów polityk App Control).
Rozbieżność nazwy klucza:
- Windows Insider Blog wskazuje wartość LockBatchFilesWhenInUse (DWORD 0/1) pod HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor.
- BleepingComputer opisuje to jako LockBatchFilesInUse w tym samym miejscu.
Na etapie Insider to może oznaczać: doprecyzowanie nazewnictwa, korektę w kolejnych buildach albo różnice między gałęziami/kanałami. W praktyce: automaty wdrożeniowe powinny wykrywać build i weryfikować faktyczną obsługiwaną nazwę (np. poprzez test w labie i kontrolę zachowania, a nie tylko „set registry and pray”).
3. Podpisy i Code Integrity: „walidacja tylko raz”
Drugi element jest szczególnie interesujący dla środowisk z włączonym Code Integrity. Microsoft deklaruje, że:
- wcześniej w tym trybie walidacja mogła odbywać się z większym narzutem,
- teraz ma być wykonana jednorazowo, co redukuje koszt i daje bardziej przewidywalny runtime dla dłuższych skryptów.
To jest ważne, bo długie, „linijkowe” BAT-y potrafią być krytyczne dla operacji (np. deployment w nocy), a każdy dodatkowy narzut potrafi wydłużyć okna serwisowe.
Praktyczne konsekwencje / ryzyko
Co zyskujesz
- Większa odporność na manipulację skryptem w trakcie wykonania (ważne przy skryptach uruchamianych z udziałów sieciowych, repo narzędziowych, katalogów roboczych z szerokimi uprawnieniami, itp.).
- Mniej kosztowna weryfikacja podpisu w scenariuszach z Code Integrity, co może poprawić stabilność i czas wykonywania automatyzacji.
Co może pójść nie tak
- Skrypty, które same siebie modyfikują (tak, to się zdarza…), generują kolejne pliki wsadowe „w locie” w tym samym miejscu lub polegają na nietypowym łańcuchu include/call mogą zachowywać się inaczej.
- Jeśli organizacja ma rozbudowane pipeline’y, które „podmieniają” treść BAT-a podczas rollout’u, blokada może ujawnić ukryte problemy procesowe (brak wersjonowania, brak atomowych podmian, złe uprawnienia do udziałów).
Rekomendacje operacyjne / co zrobić teraz
- Nie włączaj tego na produkcji w ciemno – potraktuj jako zmianę semantyki wykonywania BAT/CMD. Zacznij od labu/VM z buildem Insider.
- Zidentyfikuj „krytyczne” skrypty wsadowe (logowanie, deployment, naprawy, runbooki) i sprawdź:
- czy skrypt jest wykonywany z lokalnego dysku vs udział sieciowy,
- kto ma prawo zapisu do lokalizacji,
- czy w trakcie działania nie następuje „podmiana” pliku przez inne narzędzia.
- Jeśli używasz Application Control for Business, podejdź do tego „politykowo”: wymuś spójność uruchamiania w organizacji poprzez mechanizmy App Control, zamiast lokalnych „tweaków”.
- Dopnij higienę repozytoriów skryptów:
- atomowe wdrożenia (np. zapis do nowej nazwy + rename),
- minimalizacja uprawnień zapisu,
- podpisywanie, jeżeli to ma sens w twoim modelu zaufania.
- W środowiskach z HVCI/Memory integrity zweryfikuj wpływ na czasy wykonań — Microsoft sugeruje poprawę, ale realny efekt zależy od tego, jak i gdzie uruchamiasz skrypty.
Różnice / porównania z innymi przypadkami
- Smart App Control / App Control to kontrola „czy coś w ogóle może się uruchomić” (zależnie od podpisu/reputacji/polityki).
- Opisywana zmiana dla BAT/CMD dotyka dodatkowo integralności skryptu w czasie wykonania oraz kosztu weryfikacji przy Code Integrity. To inny poziom: nie tylko „allow/deny”, ale też „runtime hardening”.
Podsumowanie / najważniejsze wnioski
Microsoft testuje w Windows 11 Insider mechanizm, który:
- ma uniemożliwiać modyfikację BAT/CMD w trakcie uruchomienia, ograniczając klasyczny wektor TOCTOU,
- oraz ma zmniejszać narzut walidacji podpisu w środowiskach z Code Integrity (walidacja „raz na start”).
Dla organizacji, które wciąż polegają na wsadówkach, to potencjalnie bardzo sensowna zmiana — pod warunkiem, iż przejdzie przez testy kompatybilności i nie rozjedzie istniejących procesów automatyzacji.
Źródła / bibliografia
- Windows Insider Blog – ogłoszenie kompilacji z nową kontrolą dla BAT/CMD i opisem „signature validation only once”. (Windows Blog)
- BleepingComputer – omówienie nowości i sposobu włączenia (Insider). (BleepingComputer)
- Microsoft Learn – Application Control for Windows / Smart App Control (kontekst polityk aplikacyjnych). (Microsoft Learn)
- Microsoft Learn – Virtualization-based protection of code integrity (HVCI/Memory integrity) – kontekst „Code Integrity”. (Microsoft Learn)
