Zrozumienie niebezpiecznych danych wywołań funkcji w analizie oprogramowania

Analiza oprogramowania identyfikuje potencjalnie niebezpieczne wywołania funkcji w obsługiwanych plikach wykonywalnych wyodrębnionych z obrazów firmware. Wyniki te mogą pomóc znaleźć wzorce implementacyjne wymagające dodatkowej kontroli bezpieczeństwa oraz priorytetyzować pliki binarne w oparciu o ich potencjalną ekspozycję.

Ten artykuł wyjaśnia niebezpieczne sygnały wywołań funkcji, które można zobaczyć w wynikach analizy oprogramowania. Opisuje obsługiwane pliki, ograniczenia zasięgu oraz sposób oceny wyników w kontekście pliku wykonywalnego i urządzenia.

Note

Obecność niebezpiecznego wywołania funkcji niekoniecznie oznacza, że plik wykonywalny lub urządzenie jest podatne na ataki. Rzeczywiste ryzyko zależy od sposobu używania funkcji, tego, czy nieufne dane wejściowe mogą do niej dotrzeć, oraz od tego, jak plik wykonywalny jest ujawniony i chroniony.

Sygnały wywołań funkcji niebezpiecznych w analizie oprogramowania

Analiza Unsafe Function Calls wykonuje analizę statyczną obsługiwanych plików wykonywalnych w formacie Executable and Linkable Format (ELF). Identyfikuje odwołania do funkcji, które mogą przyczyniać się do problemów z bezpieczeństwem, gdy są używane bez odpowiedniej weryfikacji danych wejściowych, sprawdzania granic, walidacji rozmiaru bufora lub innych bezpiecznych kontrol kodowania.

Niektóre funkcje obsługi pamięci mogą przyczyniać się do przepełnienia bufora lub innych warunków uszkodzenia pamięci, jeśli są używane nieprawidłowo. W zależności od dotkniętej ścieżki kodu i dostępnych środków łagodzących, atakujący może wykorzystać te warunki do zakłócenia działania urządzenia lub wykonania nieautoryzowanego kodu.

Każdy wynik stanowi sygnał, a nie określenie podatności. Oceń sygnały razem i w kontekście roli pliku wykonywalnego w firmware.

Potencjalnie niebezpieczne funkcje

Niektóre funkcje biblioteczne mogą być ryzykowne, ponieważ nie egzekwują z natury rozmiaru ani wiarygodności przetwarzanych danych. Na przykład funkcje takie jak strcpy i strcat mogą przyczyniać się do warunków przepełnienia bufora, jeśli program kopiuje zbyt duże lub niezaufane dane wejściowe do bufora docelowego.

Zgłoszone odniesienie wskazuje, że analiza oprogramowania układowego zidentyfikowała śledzoną funkcję w pliku wykonywalnym. Nie dowodzi, że funkcja jest używana nieprawidłowo. Funkcja ta może być stosowana z zabezpieczeniami, takimi jak sprawdzanie długości wejścia, zapewnienie wystarczającej przestrzeni docelowej lub ograniczenie danych wejściowych do zaufanych danych.

Podczas modyfikowania kodu źródłowego używaj funkcji obsługi ciągów znaków, które akceptują rozmiar docelowego bufora i weryfikują długości wejściowe przed kopiowaniem lub łączeniem danych. Upewnij się, że wynik jest zakończony zerowo i obsługuj skracanie lub błędy. Funkcje ograniczone, takie jak strncpy i strncat mogą zmniejszyć ryzyko w porównaniu z nieograniczonymi alternatywami, ale muszą być nadal stosowane przy prawidłowych obliczeniach rozmiaru bufora.

Zestaw śledzonych funkcji może się zmieniać wraz z ewolucją tej cechy. Interpretuj nazwę funkcji i liczenie jako punkt wyjścia do przeglądu kodu, a nie jako pełny inwentarz wszystkich ryzyk bezpieczeństwa pamięci lub wykonywania poleceń.

Informacje o połączeniach sieciowych

Analiza oprogramowania układowego wskazuje również, kiedy w analizowanym pliku wykonywalnym są identyfikowane wywołania funkcji związanych z siecią. Wykorzystaj ten sygnał, aby pomóc w priorytetyzacji plików wykonywalnych do dalszej weryfikacji. Nie określa, czy plik wykonywalny akceptuje połączenia zdalne, komunikuje się poza urządzeniem lub jest dostępny w środowisku wdrożonym.

Przy ustalaniu priorytetyzacji wyników, rozważ najpierw przejrzenie plików wykonywalnych zawierających zarówno niebezpieczne wywołania funkcji, jak i wywołania sieciowe. Te pliki wykonywalne mogą przetwarzać dane otrzymane z sieci i wymagają wcześniejszego sprawdzenia.

Ścieżka wykonywalna i liczba wywołań

Wyniki są powiązane ze ścieżką wykonywalną wyodrębnioną z obrazu firmware. Liczba wywołań funkcji wskazuje, ile odniesień do śledzonej funkcji zostało zidentyfikowanych dla tego pliku wykonywalnego. Wyższa liczba może wskazywać na więcej miejsc do przeglądu, ale sama w sobie nie oznacza większej powagi czy podatności na eksploatację.

Ten sam plik wykonywalny może pojawiać się w wielu wyodrębnionych lokalizacjach, a różne pliki wykonywalne mogą zawierać odwołania do tej samej funkcji. Użyj ścieżki ekstraktora i wersji firmware, aby zidentyfikować właściwy komponent źródłowy lub artefakt dostawcy.

Obsługiwane pliki i zakres

Analiza niebezpiecznych wywołań funkcji jest dostępna w wersji podglądowej i ma zastosowanie do obsługiwanych plików wykonywalnych ELF działających w przestrzeni użytkownika, wyodrębnionych z obrazów oprogramowania układowego opartego na systemie Linux.

Pliki modułu jądra Linux (.ko) nie są uwzględnione, ponieważ podgląd jest ograniczony do analizy pliku wykonywalnego w przestrzeni użytkownika.

Wersja zapoznawcza obsługuje następujące architektury procesorów:

• AMD64 lub x86-64
• ARM64 lub AArch64
• ARM32
• MIPS32 (big- i little-endian)

Wymagania binarne

Plik wykonywalny musi przechowywać informacje umożliwiające analizie oprogramowania układowego w identyfikacji funkcji, których używa. Statycznie powiązany lub usunięty binarny system może nie dawać wyników, gdy nazwy funkcji lub inne wymagane informacje nie są dostępne.

Obraz oprogramowania układowego może pomyślnie przeprowadzić inne analizy, nie generując żadnych wyników dotyczących niebezpiecznych wywołań funkcji. Każdy analizator oprogramowania ma własne wymagania dotyczące plików, architektury i metadanych.

Wspólne używanie danych wywołań funkcji z niebezpiecznymi funkcjami

Każdy sygnał daje inną perspektywę na potencjalne ryzyko:

Sygnał	Co Ci pomaga zrozumieć
Ścieżka wykonywalna	Który wyodrębniony plik wykonywalny zawiera zidentyfikowane wywołania.
Liczba niebezpiecznych wywołań funkcji	Całkowita liczba niebezpiecznych wywołań funkcji zidentyfikowanych w pliku wykonywalnym.
Liczba wywołań sieciowych	Czy zachowania związane z siecią mogą uzasadniać priorytetyzację pliku wykonywalnego do dalszej weryfikacji. Liczba nie potwierdza możliwości zdalnego dostępu.
Liczba połączeń <function name>	Ile odniesień do wymienionej funkcji zostało zidentyfikowanych w pliku wykonywalnym. Użyj liczenia specyficznego dla funkcji, aby skupić się na dalszym przeglądzie odpowiednich mechanizmów bezpieczeństwa, takich jak rozmiarowanie bufora, walidacja wejściowa, obsługa stringów formatu, uprawnienia do pamięci czy walidacja poleceń.

Dla następujących funkcji podane są liczniki specyficzne dla funkcji:

• strcpy
• strcat
• printf
• fprintf
• sprintf
• system
• mmap
• popen

Zamiast polegać na jednym polu, oceń te sygnały razem, aby zrozumieć, które pliki wykonywalne wymagają najszybszej weryfikacji.

Istotne zagadnienia

Interpretacja wyników zerowych i pustych

Wyniki mogą pokazywać zerową liczbę plików wykonywalnych lub całkowicie pomijać plik wykonywalny. Wartość 0 oznacza, że plik wykonywalny został przeanalizowany, ale analiza nie zidentyfikowała żadnych śledzonych wywołań dla tego pola.

Jeśli plik wykonywalny nie pojawi się w wynikach, nie zakładaj, że nie zawiera żadnych niebezpiecznych wywołań funkcji. Analiza firmware mogła nie być w stanie przeanalizować pliku wykonywalnego, ponieważ używa on nieobsługiwanej architektury lub nie zawiera informacji potrzebnych do identyfikacji referencji do funkcji.

Pusta lista wyników oznacza, że dla obrazu oprogramowania układowego nie są dostępne żadne wyniki dotyczące niebezpiecznych wywołań funkcji. To nie znaczy, że firmware nie zawiera niebezpiecznych wywołań funkcji.

Nie mogą pojawić się wyniki, gdy:

• Nie wyodrębniono żadnych plików wykonywalnych ELF z przestrzeni użytkownika.
• Wyodrębnione pliki wykonywalne korzystają z nieobsługiwanych architektur.
• Statyczny lub odcięty binarny system nie zawiera wystarczającej ilości informacji identyfikacyjnych.
• Rozpakowany plik jest wyłączonym modułem jądra Linuksa.
• Obraz oprogramowania układowego został przeanalizowany przed udostępnieniem analizy niebezpiecznych wywołań funkcji.
• Ekstrakcja lub analiza nie zakończyła się sukcesem.

Note

Pusty wynik nie potwierdza, że oprogramowanie nie zawiera żadnych niebezpiecznych wywołań funkcji. Aby otrzymać aktualną analizę obrazu oprogramowania układowego, który został przetworzony przed udostępnieniem podglądu funkcji Unsafe Function Calls, prześlij ponownie obraz oprogramowania układowego.

Aby dowiedzieć się, jak przesłać obraz i zobaczyć jego wyniki, zobacz Analizuj obraz firmware za pomocą usługi analizy firmware. Aby ocenić powiązane zabezpieczenia kompilatorów i linkerów, sprawdź zakładkę Binary Hardening dla tego samego pliku wykonywalnego.