Lista kontrolna bezpieczeństwa sterowników

Ten artykuł zawiera listę kontrolną zabezpieczeń dla deweloperów sterowników w celu zmniejszenia ryzyka kompromitacji sterowników. Bezpieczeństwo kierowców ma kluczowe znaczenie i ma bezpośredni wpływ na niezawodność. Gdy system Windows wykryje, że odbywa się nieprawidłowy dostęp do pamięci, zamknie system operacyjny i wyświetli niebieski ekran błędu. Jako partner systemu Windows musisz pracować, aby zmniejszyć znaczący wpływ, jaki wadliwy sterownik ma na życie naszych klientów.

Aby uzyskać więcej informacji na temat zalet zapewniania bezpiecznego i niezawodnego sterownika, zobacz Wskazówki dotyczące zabezpieczeń sterowników.

Omówienie zabezpieczeń sterowników

Wadą zabezpieczeń jest każda wada, która pozwala atakującemu spowodować awarię sterownika w taki sposób, aby umożliwić atakującemu uzyskanie nieautoryzowanego dostępu, manipulowanie systemem lub naruszenie danych, co potencjalnie powoduje awarię systemu lub stanie się bezużyteczne. Ponadto luki w zabezpieczeniach w kodzie sterownika mogą umożliwić atakującemu uzyskanie dostępu do jądra, co może spowodować naruszenie całego systemu operacyjnego.

Gdy większość deweloperów pracuje nad swoim sterownikiem, koncentruje się na uzyskaniu prawidłowego działania sterownika, a nie na tym, czy złośliwy atakujący podejmie próbę wykorzystania luk w zabezpieczeniach w kodzie. Po zwolnieniu sterownika atakujący mogą jednak próbować sondować i identyfikować wady zabezpieczeń. Deweloperzy muszą rozważyć te problemy podczas fazy projektowania i implementacji, aby zminimalizować prawdopodobieństwo wystąpienia takich luk w zabezpieczeniach. Celem jest wyeliminowanie wszystkich znanych luk w zabezpieczeniach przed wydaniem sterownika.

Tworzenie bezpieczniejszych sterowników wymaga współpracy architekta systemu (świadomego myślenia o potencjalnych zagrożeniach dla sterownika), dewelopera wdrażającego kod (defensywne kodowanie typowych operacji, które mogą być źródłem luk w zabezpieczeniach), i zespołu testowego (aktywnie próbującego znaleźć słabości i luki w zabezpieczeniach). Właściwie koordynując wszystkie te działania, można znacznie zwiększyć bezpieczeństwo kierowcy.

Oprócz uniknięcia problemów związanych z zaatakowanym sterownikiem wiele opisanych kroków, takich jak bardziej precyzyjne użycie pamięci jądra, zwiększy niezawodność sterownika. Zmniejsza to koszty pomocy technicznej i zwiększa zadowolenie klientów z produktu. Wykonanie zadań z poniższej listy kontrolnej pomoże osiągnąć wszystkie te cele.

Lista kontrolna zabezpieczeń:Ukończ zadanie zabezpieczeń opisane w każdym z tych tematów.

Upewnij się, że sterownik jądra jest wymagany

Użyj struktur sterowników

Zarządzanie kontrolą dostępu do sterowników

Kontrola dostępu wyłącznie do sterowników oprogramowania

Przestrzegaj wytycznych dotyczących bezpiecznego kodowania sterowników.

Kod zgodny z HVCI

Stosuj najlepsze praktyki kodowania specyficzne dla technologii

dodaj adnotacje SAL do kodu sterownika

przeprowadzenie przeglądu kodu przez współpracowników

przeprowadzić analizę zagrożeń

Użyj CodeQL, aby sprawdzić kod sterownika

Użyj Weryfikatora Sterowników do sprawdzenia luk w zabezpieczeniach

Sprawdź kod przy użyciu testów zgodności sprzętu

Sprawdź sterowniki gotowe do wysyłki za pomocą narzędzi takich jak BinSkim i SignTool

nie używaj kodu sterownika testowego do podpisu produkcyjnego

Wykonaj prawidłowe podpisywanie sterowników wydania i dystrybuuj pakiet sterowników przy użyciu usługi Windows Update

Dowiedz się, jak sterowniki są zgłaszane przy użyciu Centrum Zgłaszania Sterowników Podatnych i Złośliwych firmy Microsoft

Przeglądanie zasobów dotyczących bezpiecznego kodowania

Przejrzyj Podsumowanie najważniejszych wniosków

Upewnij się, że sterownik jądra jest wymagany

element listy kontrolnej zabezpieczeń nr 1:Upewnij się, że sterownik jądra jest wymagany i że podejście niższego ryzyka, takie jak usługa lub aplikacja systemu Windows, nie jest lepszym rozwiązaniem.

Sterowniki jądra działają w jądrze systemu Windows i problem z ich wykonywaniem w jądrze wystawia na ryzyko cały system operacyjny. Jeśli jakakolwiek inna opcja jest dostępna, prawdopodobnie jest to niższe koszty i ma mniejsze ryzyko niż utworzenie nowego sterownika jądra.

Aby uzyskać więcej informacji na temat korzystania z wbudowanych sterowników systemu Windows, zobacz Czy musisz napisać sterownik?.

Aby uzyskać informacje na temat korzystania z zadań w tle, zobacz Support your app with background tasks (Obsługa aplikacji przy użyciu zadań w tle).

Aby uzyskać informacje na temat korzystania z usług systemu Windows, zobacz Services.

Korzystanie ze struktur sterowników

element listy kontrolnej zabezpieczeń nr 2:Użyj struktur sterowników, aby zmniejszyć rozmiar kodu i zwiększyć jego niezawodność i bezpieczeństwo.

Aby zmniejszyć rozmiar kodu i zwiększyć jego niezawodność i bezpieczeństwo, użyj struktury sterowników systemu Windows. Aby rozpocząć, zapoznaj się z artykułem Using WDF to Develop a Driver(Używanie usługi WDF do tworzenia sterownika). Aby uzyskać informacje na temat używania User Mode Driver Framework (UMDF) o niższym poziomie ryzyka, zobacz Wybieranie modelu sterownika.

Pisanie przestarzałego Modelu Sterowników Windows (WDM) jest bardziej czasochłonne, kosztowne i obejmuje ponowne napisanie kodu dostępnego w strukturach sterowników.

Kod źródłowy platformy Windows Driver Framework (WDF) jest typu open source i dostępny w witrynie GitHub. Jest to ten sam kod źródłowy usługi WDF dostarczany w systemie Windows. Możesz efektywniej debugować sterownik, gdy możesz śledzić interakcje między sterownikiem a usługą WDF. Pobierz go z https://github.com/Microsoft/Windows-Driver-Frameworks.

DMF — struktura modułów sterowników

Rozważ użycie Driver Module Framework (DMF) w swoim projekcie sterownika. Opracowany przez zespół microsoft Surface, DMF to struktura umożliwiająca tworzenie obiektów WDF nazywanych modułami DMF. Kod tych modułów DMF może być współużytkowany między różnymi sterownikami. Ponadto DMF udostępnia bibliotekę modułów DMF, które zostały opracowane dla sterowników i oferują ponowne wykorzystanie kodu dla zadań, takich jak zarządzanie wątkami i zarządzanie operacjami wejścia-wyjścia. Moduł DMF hermetyzuje zadania sterowników w mniejsze jednostki. Każdy moduł jest samodzielny i ma własny kod, kontekst i wywołania zwrotne, co ułatwia ponowne użycie. Aby uzyskać więcej informacji, zobacz Introducing Driver Module Framework i dokumentację witryny GitHub.

Zarządzanie kontrolą dostępu kierowców

element listy kontrolnej zabezpieczeń nr 3:Przejrzyj sterownik, aby upewnić się, że prawidłowo kontrolujesz dostęp.

Zarządzanie kontrolą dostępu do sterowników — WDF

Sterowniki muszą działać, aby uniemożliwić użytkownikom niewłaściwy dostęp do urządzeń i plików komputera. Aby zapobiec nieautoryzowanemu dostępowi do urządzeń i plików, należy:

• Nazwij obiekty urządzeń tylko wtedy, gdy jest to konieczne. Obiekty urządzeń z nazwami są zazwyczaj potrzebne tylko z powodów zgodności z przeszłością, na przykład, jeśli masz aplikację, która oczekuje, że otworzy urządzenie przy użyciu określonej nazwy, lub jeśli używasz urządzenia innego niż PNP lub urządzenia sterującego. Sterowniki WDF nie muszą przypisywać urządzeniu PnP nazwy FDO, aby utworzyć link symboliczny przy użyciu WdfDeviceCreateSymbolicLink.

• Bezpieczny dostęp do obiektów i interfejsów urządzeń.

Aby zezwolić aplikacjom lub innym sterownikom WDF na dostęp do PDO urządzenia PnP, należy użyć interfejsów urządzeń. Aby uzyskać więcej informacji, zobacz Korzystanie z interfejsów urządzeń. Interfejs urządzenia służy jako symboliczne łącze do PDO stosu urządzeń.

Jednym z lepszych sposobów kontrolowania dostępu do obiektu PDO jest określenie ciągu SDDL w INF. Jeśli ciąg SDDL nie znajduje się w pliku INF, system Windows stosuje domyślny deskryptor zabezpieczeń. Aby uzyskać więcej informacji, zobacz Zabezpieczanie obiektów urządzeń i SDDL dla obiektów urządzeń.

Aby uzyskać więcej informacji na temat kontrolowania dostępu, zobacz:

kontrolowanie dostępu do urządzeń w sterownikach KMDF

Nazwy, deskryptory zabezpieczeń i klasy urządzeń — udostępnianie obiektów urządzeń... i bezpieczne od stycznia lutego 2017 r. biuletyn NT Insider opublikowany przez OSR.

Zarządzanie kontrolą dostępu do sterowników — WDM

Jeśli pracujesz ze sterownikiem WDM i użyłeś nazwanego obiektu urządzenia, możesz użyć funkcji IoCreateDeviceSecure i określić SDDL, aby go zabezpieczyć. Podczas implementacji IoCreateDeviceSecure zawsze określaj niestandardowy identyfikator GUID dla DeviceClassGuid. Nie należy tutaj określać istniejącego identyfikatora GUID klasy. W ten sposób istnieje możliwość przerwania ustawień zabezpieczeń lub zgodności dla innych urządzeń należących do tej klasy. Aby uzyskać więcej informacji, zobacz WdmlibIoCreateDeviceSecure.

Aby uzyskać więcej informacji, zobacz:

Zarządzanie dostępem do urządzeń

Kontrolowanie dostępu do przestrzeni nazw urządzeń

model zabezpieczeń systemu Windows dla deweloperów sterowników

Hierarchia ryzyka identyfikatorów zabezpieczeń (SID)

W poniższej sekcji opisano hierarchię ryzyka typowych identyfikatorów SID używanych w kodzie sterownika. Aby uzyskać ogólne informacje na temat języka SDDL, zobacz SDDL for Device Objects, SID Stringsi SDDL String Syntax.

Należy pamiętać, że jeśli wywołujący o niższych uprawnieniach mogą uzyskiwać dostęp do jądra, ryzyko związane z kodem się zwiększa. Na tym diagramie podsumowania ryzyko zwiększa się w miarę zezwalania identyfikatorom zabezpieczeń (SID) z niższymi uprawnieniami na dostęp do funkcjonalności sterownika.

SY (System)
     \/
BA (Built-in Administrators)
     \/
LS (Local Service)
     \/
BU (Built-in User)
     \/
AC (Application Container)

Zgodnie z ogólną zasadą zabezpieczeń najniższych uprawnień skonfiguruj tylko minimalny poziom dostępu wymagany do działania sterownika.

Szczegółowa kontrola zabezpieczeń na poziomie IOCTL WDM

IOCTL (Input/Output Control) w systemie Windows to wywołanie systemowe dla operacji wejściowych/wyjściowych specyficznych dla urządzenia. IOCTL są używane przez aplikacje do komunikowania się ze sterownikami urządzeń, pozwalając tym samym na wysyłanie poleceń lub żądanie informacji od sprzętu. Aby uzyskać więcej informacji, zobacz Wprowadzenie do Kodeksu Kontroli We/Wy i Przykładowe Żądanie We/Wy — Omówienie.

Aby dodatkowo zarządzać zabezpieczeniami, gdy wywołania w trybie użytkownika wysyłają IOCTL, kod sterownika może zawierać funkcję IoValidateDeviceIoControlAccess. Ta funkcja umożliwia sterownikowi sprawdzanie praw dostępu. Po otrzymaniu IOCTL sterownik może wywołać IoValidateDeviceIoControlAccess, określając FILE_READ_ACCESS, FILE_WRITE_ACCESS lub oba.

Implementowanie szczegółowej kontroli zabezpieczeń IOCTL nie zastępuje potrzeby zarządzania dostępem sterowników przy użyciu omówionych wcześniej technik.

Aby uzyskać więcej informacji, zobacz Definiowanie kodów kontroli we/wy oraz Problemy z zabezpieczeniami kodów kontroli we/wy.

Kontrolowanie dostępu tylko do sterowników oprogramowania

element listy kontrolnej zabezpieczeń nr 4:Jeśli sterownik tylko do oprogramowania zostanie utworzony, należy zaimplementować dodatkową kontrolę dostępu.

Sterowniki jądra bazujące wyłącznie na oprogramowaniu nie używają plug-and-play (PnP) do powiązania się z konkretnymi identyfikatorami sprzętu i mogą działać na dowolnym komputerze. Taki sterownik może być używany do celów innych niż pierwotnie przewidziane, tworząc wektor ataku.

Ponieważ sterowniki jądra realizowane wyłącznie przez oprogramowanie zawierają dodatkowe ryzyko, powinny być ograniczone do działania na określonym sprzęcie, na przykład poprzez użycie unikatowego identyfikatora PnP do utworzenia sterownika PnP, lub sprawdzanie tabeli SMBIOS w celu potwierdzenia obecności określonego sprzętu.

Załóżmy na przykład, że firma OEM Fabrikam chce dystrybuować sterownik, który umożliwia narzędzie do podkręcania dla swoich systemów. Jeśli ten sterownik tylko do oprogramowania miał zostać wykonany w systemie z innego producenta OEM, może to spowodować niestabilność systemu lub uszkodzenie. Systemy firmy Fabrikam powinny zawierać unikatowy identyfikator PnP, aby umożliwić tworzenie sterownika PnP, który jest również aktualizowalny za pośrednictwem usługi Windows Update. Jeśli nie jest to możliwe, a firma Fabrikam tworzy starszy sterownik, ten sterownik powinien znaleźć inną metodę, aby sprawdzić, czy jest on wykonywany w systemie Fabrikam, na przykład przez zbadanie tabeli SMBIOS przed włączeniem jakichkolwiek możliwości.

Postępuj zgodnie z wytycznymi dotyczącymi bezpiecznego programowania sterowników

element listy kontrolnej zabezpieczeń nr 5:Przejrzyj kod i usuń wszelkie znane luki w zabezpieczeniach kodu.

Głównym działaniem tworzenia bezpiecznych sterowników jest identyfikowanie obszarów w kodzie, które należy zmienić, aby uniknąć znanych luk w zabezpieczeniach oprogramowania. Wiele z tych znanych luk w zabezpieczeniach oprogramowania dotyczy ścisłego monitorowania użycia pamięci, aby uniknąć problemów z nadpisaniem lub w inny sposób naruszeniem obszarów pamięci używanych przez sterownik.

Narzędzia do skanowania kodu, takie jak CodeQL i testy specyficzne dla sterowników, mogą służyć do lokalizowania niektórych, ale nie wszystkich tych luk w zabezpieczeniach. Te narzędzia i testy zostały opisane w dalszej części tego tematu.

bufory pamięci

• Zawsze sprawdzaj rozmiary buforów wejściowych i wyjściowych, aby upewnić się, że mogą pomieścić wszystkie żądane dane. Aby uzyskać więcej informacji, zobacz Niepowodzenie sprawdzania rozmiaru bufforów.

• Poprawnie zainicjuj wszystkie buforu wyjściowe zerami przed zwróceniem ich do wywołującego. Aby uzyskać więcej informacji, zobacz Błąd inicjowania buforów wyjściowych.

• Zweryfikuj bufory o zmiennej długości. Aby uzyskać więcej informacji, zobacz Niepowodzenie walidacji buforów Variable-Length. Aby uzyskać więcej informacji na temat pracy z buforami i używania ProbeForRead do sprawdzania poprawności, adresu buforu, zobacz Obsługa buforów.

Użyj odpowiedniej metody uzyskiwania dostępu do buforów danych za pomocą IOCTL

Jedną z podstawowych obowiązków sterownika systemu Windows jest transferowanie danych między aplikacjami w trybie użytkownika a urządzeniami systemu. W poniższej tabeli przedstawiono trzy metody uzyskiwania dostępu do danych.

Typ buforu IOCTL	Streszczenie	Aby uzyskać więcej informacji
METODA_BUFOROWANA	Zalecane w większości sytuacji	Korzystanie z buforowanego we/wy
METHOD_IN_DIRECT lub METHOD_OUT_DIRECT	Używane w niektórych szybkich wejściach/wyjściach sprzętu	Przy użyciu bezpośredniego I/O
METODA_BRAK	Unikaj, jeśli jest to możliwe	Używanie ani buforowanych, ani bezpośrednich operacji we/wy

Ogólnie rzecz biorąc, buforowane we/wy zaleca się, ponieważ zapewnia najbezpieczniejsze metody buforowania. Jednak nawet w przypadku użycia buforowanych operacji we/wy istnieją zagrożenia, takie jak osadzone wskaźniki, które musisz ograniczyć.

Aby uzyskać więcej informacji na temat pracy z buforami w IOCTLs, zobacz Metody uzyskiwania dostępu do buforów danych.

Błędy w użyciu buforowanego I/O IOCTL

• Sprawdź rozmiar buforów związanych z IOCTL. Aby uzyskać więcej informacji, zobacz Niepowodzenie sprawdzania rozmiaru bufforów.

• Poprawnie zainicjuj bufory wyjściowe. Aby uzyskać więcej informacji, zobacz Błąd inicjowania buforów wyjściowych.

• Poprawnie zweryfikuj bufory o zmiennej długości. Aby uzyskać więcej informacji, zobacz Niepowodzenie walidacji buforów Variable-Length.

• W przypadku korzystania z buforowanych operacji we/wy upewnij się, aby w polu Informacje struktury IO_STATUS_BLOCK zwrócić odpowiednią długość dla elementu OutputBuffer. Nie zwracaj bezpośrednio długości z żądania odczytu. Rozważmy na przykład sytuację, w której zwrócone dane z przestrzeni użytkownika wskazują, że istnieje bufor o rozmiarze 4K. Jeśli sterownik powinien zwracać tylko 200 bajtów, ale zamiast tego zwraca wartość 4K w polu Informacje, wystąpiła luka w zabezpieczeniach umożliwiająca ujawnienie informacji. Ten problem występuje, ponieważ we wcześniejszych wersjach systemu Windows bufor używany przez Menedżera we/wy dla operacji buforowanych nie jest zerowany. W związku z tym aplikacja użytkownika odzyskuje oryginalne 200 bajtów danych plus 4K - 200 bajtów tego, co znajdowało się w buforze (zawartości puli niestronicowanej). Ten scenariusz może wystąpić we wszystkich zastosowaniach buforowanych operacji we/wy, a nie tylko z IOCTL-ami.

Błędy w bezpośrednim we/wy IOCTL

Poprawnie obsługuj bufory o zerowej długości. Aby uzyskać więcej informacji, zobacz Errors in Direct I/O.

Błędy podczas odwoływania się do adresów przestrzeni użytkownika

• Zweryfikuj wskaźniki osadzone w buforowanych żądaniach wejścia/wyjścia. Aby uzyskać więcej informacji, zobacz Errors in Referencing User-Space Addresses.

• Przed podjęciem próby użycia zweryfikuj dowolny adres w przestrzeni użytkownika przy użyciu interfejsów API, takich jak ProbeForRead.

Kod sterownika musi mieć poprawne wykorzystanie pamięci

• Wszystkie alokacje puli sterowników muszą znajdować się w puli nie wykonywalnej (NX). Korzystanie z pul pamięci NX jest z natury bezpieczniejsze niż korzystanie z wykonywalnych pul niestronicowanych (NP) i zapewnia lepszą ochronę przed atakami przepełnienia.

• Aby umożliwić sterownikom obsługę wirtualizacji HVCI, istnieją dodatkowe wymagania dotyczące pamięci. Aby uzyskać więcej informacji, zobacz Implementowanie kodu zgodnego z standardem HVCI w dalszej części tego artykułu.

Luki w zabezpieczeniach TOCTOU

Istnieje możliwość wystąpienia podatności typu TOCTOU (time of check to time of use) podczas używania bezpośredniego we/wy (w przypadku IOCTLs lub operacji odczytu/zapisu). Należy pamiętać, że ponieważ sterownik uzyskuje dostęp do buforu danych użytkownika, aplikacja użytkownika może jednocześnie uzyskiwać dostęp do tego samego buforu danych.

Aby zarządzać tym ryzykiem, skopiuj wszystkie parametry, które należy zweryfikować z buforu danych użytkownika do pamięci, która jest dostępna wyłącznie z trybu jądra, takiego jak stos lub pula. Następnie gdy nie będzie można uzyskać dostępu do danych przez aplikację użytkownika, zweryfikuj, a następnie przeprowadź operację na przekazanych danych.

Rejestr specyficzny dla modelu MSR - odczyty i zapisy

Funkcje wewnętrzne kompilatora, takie jak __readmsr i __writemsr, mogą służyć do uzyskiwania dostępu do rejestrów specyficznych dla modelu. Jeśli ten dostęp jest wymagany, sterownik musi zawsze sprawdzić, czy rejestr do odczytu lub zapisu jest ograniczony do oczekiwanego indeksu lub zakresu.

Aby uzyskać więcej informacji i przykłady kodu, zobacz Zapewnianie możliwości odczytu/zapisu MSR w Najlepsze rozwiązania dotyczące ograniczania zachowania o wysokim poziomie uprawnień w sterownikach trybu jądra.

Uchwyty

• Sprawdzanie poprawności dojść przekazywanych między trybem użytkownika a pamięcią trybu jądra. Aby uzyskać więcej informacji, zobacz Handle Management i Failure to Validate Object Handles.

Obiekty urządzeń

• Zabezpiecz obiekty urządzeń. Aby uzyskać więcej informacji, zobacz Zabezpieczanie obiektów urządzeń.

• Zweryfikuj obiekty urządzeń. Aby uzyskać więcej informacji, zobacz Niepowodzenie sprawdzania poprawności obiektów urządzeń.

IRPs

Pakiety żądań we/wy systemu Windows są używane do przekazywania żądań we/wy między systemami operacyjnymi i sterownikami trybu jądra, hermetyzując wszystkie niezbędne informacje w pakiecie. Środowiska IRPs ułatwiają asynchroniczny transfer danych, synchronizację i obsługę błędów, zapewniając wydajną i niezawodną komunikację z urządzeniami sprzętowymi. Aby uzyskać więcej informacji, zobacz pakiety żądań we/wy i Omówienie modelu we/wy systemu Windows.

WDF i IRPs

Jedną z zalet korzystania z usługi WDF jest to, że sterowniki WDF zwykle nie uzyskują bezpośredniego dostępu do pakietów żądań wejścia/wyjścia (IRPs). Na przykład framework konwertuje IRP WDM reprezentujące operacje odczytu, zapisu oraz sterowania urządzeń I/O na obiekty żądań, które są odbierane przez KMDF/UMDF w kolejkach I/O. Jeśli to możliwe, zdecydowanie zaleca się korzystanie z usługi WDF.

Jeśli musisz napisać sterownik WDM, zapoznaj się z poniższymi wskazówkami.

Prawidłowe zarządzanie buforami we/wy IRP

Zapoznaj się z tymi tematami, które opisują sposób weryfikowania wartości wejściowych protokołu IRP:

DispatchReadWrite przy użyciu buforowanego I/O

Błędy w buforowanym We/Wy

DispatchReadWrite przy użyciu bezpośredniego we/wy

Błędy w bezpośrednim we/wy

Zweryfikuj wartości skojarzone z IRP, takie jak adresy buforu i długości, pod kątem poprawności.

Jeśli zdecydujesz się używać Neither I/O, należy pamiętać, że w przeciwieństwie do operacji odczytu i zapisu oraz w przeciwieństwie do buforowanych i bezpośrednich operacji wejścia/wyjścia, przy korzystaniu z Neither I/O, wskaźniki buforu i długości nie są weryfikowane przez Menedżera I/O.

Prawidłowa obsługa operacji zakończenia IRP

Sterownik nigdy nie może ukończyć protokołu IRP z wartością stanu STATUS_SUCCESS, chyba że faktycznie obsługuje i przetwarza protokół IRP. Aby uzyskać informacje o prawidłowych sposobach obsługi operacji zakończenia IRP, zobacz Kończenie IRP.

Zarządzanie stanem oczekiwania protokołu IRP sterownika

Sterownik powinien oznaczyć oczekujący IRP przed jego zapisaniem i rozważyć uwzględnienie zarówno wywołania IoMarkIrpPending, jak i przypisania w zsynchronizowanej sekwencji. Aby uzyskać więcej informacji, zobacz Niepowodzenie sprawdzania stanu sterownika i wstrzymywanie przychodzących IRP po wstrzymaniu urządzenia.

Prawidłowo obsłuż operacje anulowania IRP

Operacje anulowania mogą być trudne do poprawnego kodowania, ponieważ zwykle są wykonywane asynchronicznie. Problemy w kodzie, który obsługuje operacje anulowania, mogą być niezauważone przez długi czas, ponieważ ten kod zwykle nie jest wykonywany często w uruchomionym systemie. Pamiętaj, aby zapoznać się ze wszystkimi informacjami podanymi w Anulowanie IRPs. Zwróć szczególną uwagę na Synchronizowanie anulowania IRP-ów oraz kwestie, które należy wziąć pod uwagę podczas anulowania IRP-ów.

Zalecanym sposobem zminimalizowania problemów z synchronizacją skojarzonych z operacjami anulowania jest zaimplementowanie kolejki IRP z bezpiecznym anulowaniem.

Prawidłowo obsługuj czyszczenie i zamykanie operacji IRP

Upewnij się, że rozumiesz różnicę między żądaniami IRP_MJ_CLEANUP i IRP_MJ_CLOSE. Żądania oczyszczania są dostarczane po zamknięciu wszystkich dojść w obiekcie pliku, ale czasami przed ukończeniem wszystkich żądań we/wy. Żądania zamknięcia docierają po zakończeniu lub anulowaniu wszystkich żądań we/wy dla obiektu pliku. Aby uzyskać więcej informacji, zobacz następujące tematy:

DispatchCreate, DispatchClose i DispatchCreateClose Rutyny

Procedury sprzątania

błędy obsługi operacji oczyszczania i zamykania

Aby uzyskać więcej informacji na temat prawidłowego obsługi IRP, zobacz Dodatkowe błędy w obsłudze IRP.

Korzystanie z bezpiecznych funkcji

• Używaj bezpiecznych funkcji ciągów. Aby uzyskać więcej informacji, zobacz Using Safe String Functions.

• Używaj bezpiecznych funkcji arytmetycznych. Aby uzyskać więcej informacji, zobacz Bezpieczne procedury biblioteki liczb całkowitych.

• Używaj bezpiecznych funkcji konwersji. Aby uzyskać więcej informacji, zobacz Podsumowanie funkcji Kernel-Mode Bezpiecznych Liczb Całkowitych.

Inne problemy z zabezpieczeniami

• Użyj blokady lub sekwencji wzajemnego blokowania, aby zapobiec warunkom wyścigu. Aby uzyskać więcej informacji, zobacz błędy w środowisku wieloprocesorowym.

• Upewnij się, że żadne filtry interfejsu transportowego (TDI) ani dostawcy usług warstwowych (LSP) nie są instalowane przez sterownik lub powiązane pakiety oprogramowania podczas instalacji lub użytkowania. Zamiast tego należy używać nowoczesnych interfejsów API, takich jak Platforma Filtrowania Systemu Windows (WFP) .

Dodatkowe luki w zabezpieczeniach kodu

Oprócz możliwych luk w zabezpieczeniach omówionych tutaj ten artykuł zawiera dodatkowe informacje na temat zwiększania zabezpieczeń kodu sterownika trybu jądra: Tworzenie niezawodnych sterowników Kernel-Mode.

Aby uzyskać dodatkowe informacje na temat bezpiecznego kodowania w języku C i C++, zobacz Bezpieczne zasoby kodowania na końcu tego artykułu.

Implementowanie kodu zgodnego z standardem HVCI

element listy kontrolnej zabezpieczeń nr 6:Sprawdź, czy sterownik używa pamięci, aby był zgodny z standardem HVCI.

Integralność pamięci i zgodność Z standardem HVCI

Integralność pamięci, znana również jako funkcja integralności kodu chronionego przez funkcję Hypervisor (HVCI), używa technologii sprzętowej i wirtualizacji do izolowania funkcji podejmowania decyzji dotyczących integralności kodu (CI) z pozostałej części systemu operacyjnego. W przypadku korzystania z zabezpieczeń opartych na wirtualizacji w celu izolowania integralności przepływu sterowania, jedynym sposobem, w jaki pamięć jądra może stać się wykonywalna, jest weryfikacja integralności przepływu sterowania. Oznacza to, że strony pamięci jądra nigdy nie mogą być zapisywalne i wykonywalne (W+X) i nie można bezpośrednio modyfikować kodu wykonywalnego.

Aby zaimplementować kod zgodny z standardem HVCI, upewnij się, że kod sterownika wykonuje następujące czynności:

• Domyślnie wyraża zgodę na korzystanie z serwera NX.
• Używa interfejsów API/flag NX do alokacji pamięci (NonPagedPoolNx).
• Nie używa sekcji, które są zarówno zapisywalne, jak i wykonywalne.
• Nie próbuje bezpośrednio modyfikować pamięci systemu wykonywalnego.
• Nie używa kodu dynamicznego w jądrze.
• Nie ładuje plików danych jako plików wykonywalnych.
• Wyrównanie sekcji jest wielokrotnością 0x1000 (PAGE_SIZE). Na przykład DRIVER_ALIGNMENT=0x1000.

Aby uzyskać więcej informacji na temat używania narzędzia i listy niezgodnych wywołań pamięci, zobacz Implementowanie kodu zgodnego z standardem HVCI.

Aby dowiedzieć się więcej o podstawowych funkcjach systemu związanych z bezpieczeństwem, zobacz Test Przygotowania Integralności Kodów HyperVisor i Integralność Kodów Chroniona przez Hypervisor (HVCI).

Ulepszanie zabezpieczeń instalacji urządzeń

element listy kontrolnej zabezpieczeń nr 7:Przejrzyj wskazówki dotyczące tworzenia i instalacji sterownika, aby upewnić się, że są to najlepsze rozwiązania.

Podczas tworzenia kodu, który instaluje pakiet sterowników, należy upewnić się, że instalacja urządzenia będzie zawsze wykonywana w bezpieczny sposób. Bezpieczna instalacja urządzenia jest taka, która wykonuje następujące czynności:

• Ogranicza dostęp do urządzenia i jego klas interfejsów urządzeń
• Ogranicza dostęp do usług sterowników utworzonych dla urządzenia
• Chroni pliki sterowników przed modyfikacją lub usunięciem
• Ogranicza dostęp do wpisów rejestru urządzenia
• Ogranicza dostęp do klas WMI urządzenia
• Prawidłowo używa funkcji SetupAPI

Aby uzyskać więcej informacji, zobacz następujące tematy:

tworzenie bezpiecznych instalacji urządzeń

wskazówki dotyczące używania interfejsu SetupAPI

przy użyciu funkcji instalacji urządzeń

Zaawansowane tematy dotyczące instalacji urządzeń i sterowników

Postępuj zgodnie z najlepszymi rozwiązaniami dotyczącymi kodu specyficznymi dla technologii

pozycja listy kontrolnej bezpieczeństwa nr 8:Zapoznaj się z następującymi wskazówkami dotyczącymi technologii dla sterownika.

Systemy plików

Aby uzyskać więcej informacji na temat zabezpieczeń sterownika systemu plików, zobacz następujące artykuły:

Wprowadzenie do zabezpieczeń systemów plików

problemy z zabezpieczeniami systemu plików

funkcje zabezpieczeń dla systemów plików

współistnienie z innymi sterownikami filtrów systemu plików

Inicjatywa wirusów firmy Microsoft

Program Microsoft Virus Initiative (MVI) pomaga organizacjom w ulepszaniu rozwiązań zabezpieczeń, z których korzystają nasi klienci, aby zapewnić im bezpieczeństwo. Microsoft zapewnia narzędzia, zasoby i wiedzę dla lepszych, wspólnych doświadczeń charakteryzujących się wysoką wydajnością, niezawodnością i zgodnością. Firma Microsoft współpracuje z partnerami MVI w celu zdefiniowania i przestrzegania bezpiecznych praktyk wdrażania (SDP) w celu zapewnienia bezpieczeństwa i odporności naszych wzajemnych klientów.

Jeśli jesteś dostawcą oprogramowania antywirusowego, zobacz Microsoft Virus Initiative, aby dowiedzieć się, jak dołączyć do mvI, aby uzyskać więcej pomocy dotyczącej wdrażania oprogramowania. Aby uzyskać informacje na temat tego, jak dostawcy zabezpieczeń mogą lepiej wykorzystać zintegrowane funkcje zabezpieczeń systemu Windows w celu zwiększenia bezpieczeństwa i niezawodności, zobacz Najlepsze rozwiązania dotyczące zabezpieczeń systemu Windows dotyczące integrowania narzędzi zabezpieczeń i zarządzania nimi.

NDIS — technologie sieciowe

Aby uzyskać informacje o zabezpieczeniach sterowników NDIS, zobacz Problemy z zabezpieczeniami sterowników sieciowych.

Drukarki

Aby uzyskać informacje dotyczące zabezpieczeń sterowników drukarek, zobacz Zagadnienia dotyczące zabezpieczeń sterowników drukarek V4.

Problemy z zabezpieczeniami sterowników pozyskiwania obrazów systemu Windows (WIA)

Aby uzyskać informacje na temat zabezpieczeń WIA, zapoznaj się z Problemy zabezpieczeń dla sterowników Windows Image Acquisition (WIA).

Dodawanie adnotacji SAL do kodu sterownika

element listy kontrolnej zabezpieczeń nr 9:Dodaj adnotacje SAL do kodu sterownika.

Język adnotacji kodu źródłowego (SAL) udostępnia zestaw adnotacji, których można użyć do opisania sposobu używania jego parametrów przez funkcję, założeń, które wykonuje na ich temat, oraz gwarancji, które wykonuje po zakończeniu. Adnotacje są definiowane w pliku nagłówka sal.h. Analiza kodu programu Visual Studio dla języka C++ używa adnotacji SAL do modyfikowania analizy funkcji. Aby uzyskać więcej informacji na temat SAL 2.0 do tworzenia sterowników Windows, zobacz Adnotacje SAL 2.0 dla sterowników Windows i Używanie adnotacji SAL w celu zmniejszenia wad kodu C/C++.

Aby uzyskać ogólne informacje na temat SAL, zapoznaj się z tym artykułem dostępnym w OSR. adnotacje SAL: Nie nienawidź mnie za to, że jestem piękna

Przegląd kodu przez kolegów

element listy kontrolnej zabezpieczeń #10:Przeprowadź przegląd kodu przez współpracowników, aby wyszukać problemy, które nie są wykrywane przez inne narzędzia i procesy

Poszukaj wiedzy recenzentów kodu, aby wyszukać problemy, które mogły zostać pominięte. Drugi zestaw oczu często widzi problemy, które mogą być pomijane.

Jeśli nie masz odpowiedniego personelu, aby przejrzeć kod wewnętrznie, rozważ skorzystanie z pomocy zewnętrznej w tym celu.

Przeprowadzanie analizy zagrożeń

element listy kontrolnej zabezpieczeń nr 11:Zmodyfikuj istniejący model zagrożenia sterowników lub utwórz niestandardowy model zagrożeń dla sterownika.

Biorąc pod uwagę bezpieczeństwo, wspólną metodologią jest utworzenie konkretnych modeli zagrożeń, które próbują opisać możliwe typy ataków. Ta technika jest przydatna podczas projektowania sterownika, ponieważ zmusza programistę do rozważenia potencjalnych wektorów ataku z wyprzedzeniem. Po zidentyfikowaniu potencjalnych zagrożeń deweloper może następnie rozważyć środki obrony przed tymi zagrożeniami, aby wzmocnić ogólne bezpieczeństwo składnika sterownika.

Aby uzyskać wskazówki dotyczące tworzenia uproszczonego modelu zagrożeń dla sterowników, zobacz Modelowanie zagrożeń dla sterowników. Artykuł zawiera przykładowy diagram modelu zagrożeń sterownika, którego można użyć jako punktu początkowego dla sterownika.

Najlepsze praktyki dotyczące cyklu projektowania zabezpieczeń (SDL) i powiązane narzędzia mogą być wykorzystywane przez dostawców sprzętu (IHV) i producentów OEM w celu poprawy bezpieczeństwa swoich produktów. Więcej informacji można znaleźć w zaleceniach SDL dla producentów OEM.

Sprawdzanie kodu sterownika za pomocą języka CodeQL

element listy kontrolnej zabezpieczeń nr 12:Sprawdzanie luk w zabezpieczeniach w kodzie sterownika za pomocą języka CodeQL.

CodeQL, by GitHub, to semantyczny aparat analizy kodu, a kombinacja rozbudowanego zestawu zapytań zabezpieczeń wraz z niezawodną platformą sprawia, że jest to cenne narzędzie do zabezpieczania kodu sterownika. Więcej informacji można znaleźć w CodeQL i Teście Logo Narzędzi Statycznych.

Sprawdzanie luk w zabezpieczeniach za pomocą weryfikatora sterowników

element listy kontrolnej zabezpieczeń nr 13:Użyj weryfikatora sterowników, aby sprawdzić luki w zabezpieczeniach w kodzie sterownika.

Weryfikator sterowników używa zestawu reguł interfejsu i modelu systemu operacyjnego w celu określenia, czy sterownik prawidłowo współdziała z systemem operacyjnym Windows. Weryfikator sterowników znajduje wady w kodzie sterownika, które mogą wskazywać na potencjalne błędy w sterownikach.

Weryfikator sterowników umożliwia testowanie na żywo sterownika. Weryfikator sterowników monitoruje sterowniki trybu jądra systemu Windows i sterowniki graficzne w celu wykrywania nielegalnych wywołań funkcji lub akcji, które mogą uszkodzić system. Dołączony debuger umożliwia wyświetlanie systemu operacyjnego i wykonywania kodu sterownika w czasie rzeczywistym. Weryfikator sterowników może poddać sterowniki systemu Windows różnym stresom i testom w celu znalezienia nieprawidłowego zachowania. Aby uzyskać więcej informacji, zobacz Driver Verifier.

Weryfikator sterowników współdziała zarówno z sterownikami WDM, jak i KMDF. Aby uzyskać szczegółowe informacje o tym, co może sprawdzić, zobacz następujące tematy.

• reguły dotyczące sterowników WDM
• zasady dotyczące sterowników KMDF

Aby uzyskać więcej informacji na temat sterowników, z którymi może pracować weryfikator sterownika, zobacz reguły zgodności DDI i obsługiwane sterowniki . Aby zapoznać się z dodatkowymi regułami weryfikatora dla określonych typów sterowników, zobacz:

• reguły sterowników NDIS
• zasady dotyczące sterowników Storport
• reguły dotyczące sterowników audio
• Zasady sterowników AVStream

Aby zapoznać się z weryfikatorem sterowników, możesz użyć jednego z przykładowych sterowników (na przykład znanej próbki sterownika tosteru: https://github.com/Microsoft/Windows-driver-samples/tree/main/general/toaster/toastDrv/kmdf/func/featured).

Sprawdzanie kodu przy użyciu testów programu zgodności sprzętu

element listy kontrolnej zabezpieczeń nr 14:Użyj testów programu zgodności sprzętu powiązanego z zabezpieczeniami, aby sprawdzić, czy występują problemy z zabezpieczeniami.

Program zgodności sprzętu zawiera testy związane z zabezpieczeniami, których można użyć do wyszukiwania luk w zabezpieczeniach kodu. Program zgodności sprzętu systemu Windows korzysta z testów w zestawie Windows Hardware Lab Kit (HLK). Testy podstawowe urządzeń HLK mogą być używane w wierszu poleceń do wykonywania kodu sterownika i wyszukiwania słabości. Aby uzyskać ogólne informacje na temat testów podstawowych urządzeń i programu zgodności sprzętu, zobacz Windows Hardware Lab Kit.

Poniższe testy to przykłady testów, które mogą być przydatne do sprawdzania kodu sterownika pod kątem niektórych zachowań związanych z lukami w zabezpieczeniach kodu:

DF — test rozmyty losowego testu IOCTL (niezawodność)

DF - Test otwarć podrozmytych (niezawodność)

DF — test bufora o zerowej długości FSCTL (niezawodność)

DF — rozmyty losowy test FSCTL (niezawodność)

DF — test interfejsu API rozmytego (niezawodność)

Można również użyć fuzzing opóźnienia synchronizacji jądra, które jest dołączone do Weryfikatora Sterowników.

Testy CHAOS (Concurrent Hardware and Operating System) uruchamiają współbieżnie różne testy sterowników PnP, fuzz testing sterowników urządzeń oraz testy systemu zasilania. Aby uzyskać więcej informacji, zobacz testy CHAOS (Podstawy Urządzeń).

Testy penetracyjne Device Fundamentals przeprowadzają różne formy ataków wejściowych, które są krytycznym składnikiem testowania zabezpieczeń. Testy ataków i penetracyjne mogą pomóc w zidentyfikowaniu luk w zabezpieczeniach w interfejsach oprogramowania. Aby uzyskać więcej informacji, zobacz Testy Penetracyjne (Podstawy Urządzeń).

Użyj Device Guard — test zgodności, wraz z innymi narzędziami opisanymi w tym artykule, aby potwierdzić, że sterownik jest zgodny z standardem HVCI.

Niestandardowe i specyficzne dla domeny narzędzia testowe

Rozważ opracowanie niestandardowych testów zabezpieczeń specyficznych dla domeny. Aby opracować dodatkowe testy, zbierz dane wejściowe od oryginalnych projektantów oprogramowania oraz niezwiązane z projektem zasoby programistyczne zaznajomione z opracowywanym konkretnym typem sterownika, a także jedną lub więcej osób zaznajomionych z analizą i zapobieganiem włamaniom.

Sprawdź sterowniki przeznaczone do wysyłki za pomocą narzędzi takich jak BinSkim i SignTool

element listy kontrolnej zabezpieczeń nr 15:Sprawdź skompilowany kod za pomocą narzędzi, takich jak BinSkim i SignTool, zanim zostanie przekazany do Centrum partnerskiego.

Użyj narzędzi takich jak BinSkim i SignTool, aby zbadać pliki binarne, aby sprawdzić skompilowany kod przed przekazaniem go do Centrum partnerskiego do dystrybucji przy użyciu usługi Windows Update. Narzędzia do sprawdzania skompilowanych plików binarnych, zanim zostaną przesłane do dystrybucji, dodają kolejną warstwę ochrony.

BinSkim

BinSkim może identyfikować metody kodowania i tworzenia, które mogą potencjalnie stanowić zagrożenie binarne. BinSkim sprawdza:

• Korzystanie z nieaktualnych zestawów narzędzi kompilatora — pliki binarne powinny być kompilowane względem najnowszych zestawów narzędzi kompilatora, gdzie tylko jest to możliwe, aby zmaksymalizować wykorzystanie bieżących środków zaradczych dotyczących zabezpieczeń na poziomie kompilatora i systemu operacyjnego.
• Niezabezpieczone ustawienia kompilacji — pliki binarne powinny być kompilowane przy użyciu najbezpieczniejszych ustawień umożliwiających ograniczenie zabezpieczeń zapewnianych przez system operacyjny, maksymalizowanie błędów kompilatora i raportowanie ostrzeżeń z możliwością działania.
• Problemy z podpisywaniem — podpisane pliki binarne powinny być podpisane przy użyciu algorytmów kryptograficznie silnych.

BinSkim to narzędzie typu open source i generuje pliki wyjściowe korzystające z formatu wymiany wyników analizy statycznej (SARIF). BinSkim zastępuje poprzednie narzędzie BinScope.

Aby uzyskać więcej informacji na temat BinSkim, zobacz Użyj BinSkim, aby sprawdzić pliki binarne oraz Przewodnik użytkownika BinSkim.

Narzędzie SignTool

Użyj narzędzia SignTool, aby sprawdzić podpisane pliki sterowników. Aby uzyskać więcej informacji, zobacz Weryfikowanie podpisu pliku sterownika Release-Signed i weryfikowanie podpisu pliku wykazu podpisanego przez certyfikat wersji komercyjnej.

Nie należy pisać w środowisku produkcyjnym kodu testowego

element listy kontrolnej zabezpieczeń nr 16:Nie należy produkować kodu tworzenia, testowania i produkcji kodu sterownika jądra.

Kod sterownika jądra używany do programowania, testowania lub produkcji może obejmować niebezpieczne możliwości, które stanowią zagrożenie bezpieczeństwa. Ten niebezpieczny kod nigdy nie powinien być podpisany przy użyciu certyfikatu zaufanego przez system Windows. Prawidłowym mechanizmem wykonywania niebezpiecznego kodu sterownika jest wyłączenie bezpiecznego rozruchu UEFI, włączenie funkcji BCD "TESTSIGNING" i podpisanie kodu programistycznego, testowego i produkcyjnego przy użyciu niezaufanego certyfikatu (na przykład jednego wygenerowanego przez makecert.exe).

Kod podpisany przez zaufany certyfikat wydawców oprogramowania (SPC) lub sygnaturę WHQL (Hardware Quality Labs) systemu Windows nie może ułatwić obejścia technologii integralności kodu i zabezpieczeń systemu Windows. Zanim kod zostanie podpisany przez zaufany podpis SPC lub WHQL, upewnij się najpierw, że jest zgodny ze wskazówkami z dotyczących tworzenia niezawodnych sterowników Kernel-Mode. Ponadto kod nie może zawierać żadnych niebezpiecznych zachowań opisanych poniżej.

Przykłady niebezpiecznego zachowania obejmują następujące elementy:

• Umożliwia mapowanie dowolnego jądra, pamięci fizycznej lub pamięci urządzenia na tryb użytkownika.
• Zapewnienie możliwości odczytu lub zapisu dowolnej pamięci jądra, fizycznej lub urządzenia, w tym portu wejścia/wyjścia (We/Wy).
• Zapewnianie dostępu do przechowywania, które omija kontrolę dostępu systemu Windows.
• Zapewnienie możliwości modyfikowania sprzętu lub oprogramowania układowego, którym sterownik nie został zaprojektowany do zarządzania.

Wykonywanie prawidłowego podpisywania sterownika wydania i rozpowszechnianie pakietu sterowników przy użyciu usługi Windows Update

element listy kontrolnej zabezpieczeń nr 17:Użyj portalu partnerskiego systemu Windows, aby przesłać pakiet sterowników do podpisania i dystrybucji za pośrednictwem usługi Windows Update.

Przed udostępnieniem pakietu sterowników do publicznej wiadomości należy przesłać pakiet do certyfikacji. Aby uzyskać więcej informacji, zobacz Test pod kątem wydajności i zgodności oraz Rozpocznij pracę z programem sprzętowym.

Korzystanie z usługi Windows Update jest zdecydowanie zalecane w przypadku dystrybucji pakietów sterowników. Usługa Windows Update zapewnia niezawodny, bezpieczny, globalnie skalowany i zgodny z przepisami system dystrybucji, który powinien służyć do dostarczania aktualizacji sterowników. Aby uzyskać więcej informacji, zobacz Dystrybucja pakietu sterowników.

Użyj stopniowego wdrażania i flighting sterowników w Centrum partnerskim dla systemu Windows Hardware dystrybuować pakiet sterowników w zdefiniowanych pierścieniach niejawnych testerów systemu Windows, zapewniając jednocześnie automatyczne monitorowanie i ocenę. Monitoruj wdrożenie sterownika przy użyciu miar sterowników firmy Microsoft, takich jak procent maszyn bez awarii trybu jądra w celu zachowania jakości.

Opis bezpiecznych praktyk wdrażania oprogramowania można znaleźć w artykule CISA Safe Software Deployment: How Software Manufacturers Can Ensure Reliability for Customers(Jak producenci oprogramowania mogą zapewnić niezawodność dla klientów).

Dowiedz się, jak sterowniki są zgłaszane przy użyciu Microsoft Vulnerable and Malicious Driver Reporting Center

element listy kontrolnej zabezpieczeń nr 18: Informacje o tym, jak sterowniki są zgłaszane przy użyciu Centrum raportowania luk w zabezpieczeniach i złośliwych sterowników firmy Microsoft

Każdy może przesłać wątpliwy sterownik przy użyciu Microsoft Vulnerable and Malicious Driver Reporting Center. Zapoznaj się z tym wpisem w blogu, aby uzyskać informacje na temat sposobu przesyłania sterowników do analizy — Ulepszanie zabezpieczeń jądra za pomocą nowego centrum raportowania czynników narażonych i złośliwych sterowników firmy Microsoft

Centrum raportowania może skanować i analizować sterowniki systemu Windows utworzone pod kątem architektur x86 i x64. Wrażliwe i złośliwe zeskanowane sterowniki są oflagowane do analizy i zbadania przez zespół ds. sterowników podatnych na zagrożenia firmy Microsoft. Po potwierdzeniu kierowców podatnych na zagrożenia następuje odpowiednie powiadomienie, a następnie zostają oni dodani do listy blokowanych kierowców. Aby uzyskać więcej informacji, zobacz Zalecane reguły blokowania sterowników firmy Microsoft. Te reguły są domyślnie stosowane do urządzeń z włączoną integralnością kodu chronionego przez funkcję Hypervisor (HVCI) i systemu Windows 10 w trybie S.

Przeglądanie bezpiecznych zasobów kodowania

element listy kontrolnej zabezpieczeń nr 19:Przejrzyj te zasoby, aby rozwinąć zrozumienie najlepszych rozwiązań dotyczących bezpiecznego kodowania, które mają zastosowanie do deweloperów sterowników.

Wskazówki Microsoft dotyczące NISTIR 8397

Publikacja rządowa Stanów Zjednoczonych NISTIR 8397: Wytyczne dotyczące minimalnych standardów weryfikacji deweloperów oprogramowania opublikowane przez National Institute of Standards and Technology (NIST) zawiera wskazówki dotyczące tworzenia niezawodnego i bezpiecznego oprogramowania w dowolnym języku programowania.

Tworzenie niezawodnych i bezpiecznych programów języka C++ podsumowuje, jak używać produktów deweloperskich firmy Microsoft dla języka C++ i innych języków, aby postępować zgodnie z wytycznymi NISTIR 8397.

Znana baza danych luk w zabezpieczeniach oprogramowania NIST

National Vulnerability Database (NVD) to przeszukiwalne repozytorium błędów oprogramowania związanych z zabezpieczeniami, w tym sterowników systemu Windows.

Przeszukaj bazę danych luk w zabezpieczeniach NIST

Krajowa Baza Danych o Lukach w Zabezpieczeniach — Omówienie

Bezpieczne standardy kodowania

Carnegie Mellon University SEI CERT - C Coding Standard: Reguły tworzenia bezpiecznych, niezawodnych i bezpiecznych systemów (PDF).

MITRE — słabości rozwiązane przez standard bezpiecznego kodowania CERT C

Microsoft Visual Studio — używanie narzędzi sprawdzających zgodność z wytycznymi Core dla C++

Organizacje ds. bezpiecznego kodowania

Agencja Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury (CISA)

Zasoby CISA

Carnegie Mellon University SEI CERT

SAFECode

OSR

OSR zapewnia szkolenia i usługi doradcze w zakresie rozwoju sterowników. Te artykuły z biuletynu OSR podkreślają kwestie bezpieczeństwa sterowników.

Nazwy, deskryptory zabezpieczeń i klasy urządzeń — udostępnianie obiektów urządzeń... i bezpieczne

Musisz korzystać z ochrony — zabezpieczenia wewnętrzne sterownika urządzenia &

Zabezpieczanie sterowników - Przegląd technik

Meltdown i Spectre: Co z sterownikami?

Analiza przypadku luk w zabezpieczeniach sterowników

Od alertu do podatności sterownika: badanie w usłudze Microsoft Defender ATP ujawnia lukę w eskalacji uprawnień

Zabezpieczenia łańcucha dostaw oprogramowania i lista materiałowa oprogramowania (SBOMs)

SBOMs udostępniają listę składników używanych w tworzeniu oprogramowania, takiego jak oprogramowanie typu open source, składniki, a nawet narzędzia do tworzenia. Dzięki temu producenci i konsumenci mogą lepiej spisać i oceniać ryzyko związane z licencjami i lukami w zabezpieczeniach. Microsoft używa SPDX (Software Package Data Exchange) jako formatu dokumentu SBOM. Aby uzyskać więcej informacji, zobacz Generowanie rachunków materiałowych oprogramowania (SBOM) z dodatkiem SPDX w witrynie Microsoft i Microsoft udostępnia jako open-source narzędzie do generowania rachunków materiałowych oprogramowania (SBOM).

inicjatywa "Integralność łańcucha dostaw, przejrzystość i zaufanie" (SCITT) jest zestawem standardów internetowych IETF do zarządzania zgodnością towarów i usług w łańcuchach dostaw. SCITT obsługuje ciągłą weryfikację towarów i usług, w których oceniane jest autentyczność jednostek, dowodów, zasad i artefaktów. Celem jest to, że działania jednostek mogą być autoryzowane, niepodważalne, niezmienne i podlegające inspekcji.

Książki

24 Śmiertelne grzechy zabezpieczeń oprogramowania: Wady programowania i Jak je naprawić michael Howard, David LeBlanc i John Viega

Pisanie Bezpiecznego Oprogramowania, Drugie Wydanie, Michael Howard i David LeBlanc

The Art of Software Security Assessment: Identyfikowanie i zapobieganie lukom w zabezpieczeniach oprogramowania, Mark Dowd, John McDonald i Justin Schuh

Bezpieczne Programowanie w C i C++ (Seria SEI w Inżynierii Oprogramowania) 2. wydanie, Robert C. Seacord

Programowanie modelu sterowników systemu Microsoft Windows (2.nd Edition), Walter Oney

tworzenie sterowników za pomocą programu Windows Driver Foundation (dokumentacja dla deweloperów), Penny Orwick i Guy Smith

Szkolenie

Szkolenie na potrzeby zajęć sterowników systemu Windows jest dostępne od dostawców, takich jak:

• OSR
• Winsider

Bezpieczne trenowanie kodu online jest dostępne z różnych źródeł. Na przykład ten kurs jest dostępny w witrynie coursera:

Identyfikowanie luk w zabezpieczeniach w programowaniu C/C++.

Program SAFECode oferuje również bezpłatne szkolenia:

SAFECode.org/training

Certyfikacja profesjonalna

CERT oferuje certyfikat profesjonalisty z zakresu bezpiecznego kodowania .

Podsumowanie kluczowych wniosków

Bezpieczeństwo kierowców to złożone przedsięwzięcie zawierające wiele elementów, ale oto kilka kluczowych kwestii, które należy wziąć pod uwagę:

• Sterowniki działają w jądrze systemu Windows, a wystąpienie problemu podczas wykonywania w jądrze naraża na niebezpieczeństwo cały system operacyjny. W związku z tym należy zwrócić szczególną uwagę na bezpieczeństwo kierowcy i projektowanie z myślą o bezpieczeństwie.

• Zastosuj zasadę najniższych uprawnień:

  a. Użyj ścisłego ciągu SDDL, aby ograniczyć dostęp do sterownika.

  b. Dodatkowo ogranicz poszczególne listy IOCTL.

• Utwórz model zagrożeń, aby zidentyfikować wektory ataków i rozważyć, czy wszystko może być jeszcze bardziej ograniczone.

• Należy zachować ostrożność w odniesieniu do wskaźników osadzonych przekazywanych z trybu użytkownika. Muszą one być sprawdzane, dostępne w ramach instrukcji try-except i są podatne na problemy związane z czasem sprawdzania i czasem użycia (ToCToU), chyba że wartość buforu zostanie przechwycona i porównana.

• Jeśli nie masz pewności, użyj METHOD_BUFFERED jako metody buforowania IOCTL.

• Użyj narzędzi do skanowania kodu, takich jak CodeQL, aby wyszukać znane luki w zabezpieczeniach kodu i skorygować wszelkie zidentyfikowane problemy.

• Poszukaj wiedzy recenzentów kodu, aby wyszukać problemy, które mogły zostać pominięte.

• Użyj weryfikatorów sterowników i przetestuj sterownik przy użyciu wielu danych wejściowych, w tym przypadków narożnych.