Dlaczego strlcpy i strlcat są uważane za niebezpieczne?

Rozumiem to strlcpyi strlcatzostały zaprojektowane jako bezpieczne zamienniki dla strncpyi strncat. Jednak niektórzy ludzie nadal uważają, że są niepewni i po prostu powodują inny rodzaj problemu .

Czy ktoś może podać przykład, jak użycie strlcpyor strlcat(tj. Funkcji, która zawsze kończy swoje łańcuchy o wartości null) może prowadzić do problemów z bezpieczeństwem?

Ulrich Drepper i James Antill twierdzą, że to prawda, ale nigdy nie podawaj przykładów ani nie wyjaśniaj tej kwestii.

Po pierwsze, strlcpynigdy nie był pomyślany jako bezpieczna wersja strncpy(i strncpynigdy nie był pomyślany jako bezpieczna wersja strcpy). Te dwie funkcje są zupełnie niezwiązane. strncpyjest funkcją, która w ogóle nie ma związku z napisami C (tj. łańcuchami zakończonymi znakiem null). Fakt, że ma str...przedrostek w nazwie, jest tylko historyczną pomyłką. Historia i cel programu strncpysą dobrze znane i dobrze udokumentowane. Jest to funkcja stworzona do pracy z tak zwanymi łańcuchami o stałej szerokości (nie z łańcuchami C) używanymi w niektórych historycznych wersjach systemu plików Unix. Niektórzy programiści są dziś zdezorientowani przez jego nazwę i zakładają, że strncpyma ona w jakiś sposób służyć jako funkcja kopiowania łańcuchów C o ograniczonej długości („bezpieczne” rodzeństwostrcpy), co w rzeczywistości jest kompletnym nonsensem i prowadzi do złej praktyki programistycznej. Biblioteka standardowa C w swojej obecnej formie nie ma żadnej funkcji do kopiowania łańcuchów C o ograniczonej długości. To jest miejsce, w którym strlcpypasuje. strlcpyTo rzeczywiście prawdziwa funkcja kopiowania o ograniczonej długości, stworzona do pracy z napisami C. strlcpypoprawnie robi wszystko, co powinna robić funkcja kopiowania o ograniczonej długości. Jedyną krytyką, jaką można do niego skierować, jest to, że niestety nie jest to standard.

Po drugie, strncatz drugiej strony, jest to rzeczywiście funkcja, która działa ze stringami C i wykonuje konkatenację o ograniczonej długości (jest rzeczywiście „bezpiecznym” rodzeństwem strcat). Aby prawidłowo korzystać z tej funkcji programista musi zachować szczególną ostrożność, ponieważ parametr rozmiaru, który ta funkcja akceptuje, nie jest tak naprawdę wielkością bufora, który otrzymuje wynik, ale raczej rozmiarem jego pozostałej części (także jest liczony niejawnie). Może to być mylące, ponieważ aby powiązać ten rozmiar z rozmiarem bufora, programista musi pamiętać o wykonaniu dodatkowych obliczeń, które są często używane do krytykowania pliku strncat.strlcatzałatwia te kwestie, zmieniając interfejs tak, aby nie były potrzebne żadne dodatkowe obliczenia (przynajmniej w kodzie wywołującym). Ponownie, jedyną podstawą, na której można to krytykować, jest to, że funkcja nie jest standardowa. Ponadto funkcje z strcatgrupy są czymś, czego nie zobaczysz w profesjonalnym kodzie bardzo często ze względu na ograniczoną użyteczność samej idei konkatenacji ciągów opartej na ponownym skanowaniu.

Jeśli chodzi o to, jak te funkcje mogą prowadzić do problemów z bezpieczeństwem ... Po prostu nie mogą. Nie mogą prowadzić do problemów bezpieczeństwa w większym stopniu niż sam język C może „prowadzić do problemów bezpieczeństwa”. Widzisz, od dłuższego czasu panowało przekonanie, że język C ++ musi podążać w kierunku rozwijania się w dziwny smak Javy. Ten sentyment czasami przenika również do domeny języka C, co skutkuje raczej nieświadomą i wymuszoną krytyką cech języka C i funkcji standardowej biblioteki C. Podejrzewam, że w tym przypadku możemy mieć do czynienia z czymś takim, chociaż mam nadzieję, że tak naprawdę nie jest tak źle.

Krytyka Ulricha opiera się na idei, że obcięcie ciągu znaków, które nie zostało wykryte przez program, może prowadzić do problemów z bezpieczeństwem, z powodu nieprawidłowej logiki. Dlatego, aby być bezpiecznym, musisz sprawdzić, czy nie ma obcięcia. Aby to zrobić dla konkatenacji ciągów znaków, oznacza to, że wykonujesz sprawdzenie według następującego wzoru:

if (destlen + sourcelen > dest_maxlen)
{
    /* Bug out */
}

Teraz strlcatsprawnie robi to sprawdzenie, czy programista pamięta o sprawdzeniu wyniku - abyś mógł bezpiecznie z niego korzystać:

if (strlcat(dest, source, dest_bufferlen) >= dest_bufferlen)
{
    /* Bug out */
}

Ulrich chodzi o to, że skoro musisz mieć destleni sourcelenwokół (lub przeliczyć je, co strlcatskutecznie robi), równie dobrze możesz po prostu użyć bardziej wydajnego memcpy:

if (destlen + sourcelen > dest_maxlen)
{
    goto error_out;
}
memcpy(dest + destlen, source, sourcelen + 1);
destlen += sourcelen;

(W powyższym kodzie dest_maxlenjest to maksymalna długość łańcucha, który może być przechowywany dest- o jeden mniej niż rozmiar destbufora. dest_bufferlenTo pełny rozmiar dest buffer).

Kiedy ludzie mówią „ strcpy()jest niebezpieczny, użyj strncpy()zamiast tego” (lub podobne stwierdzenia dotyczące strcat()itp., Ale zamierzam się strcpy()tutaj skupić), mają na myśli, że nie ma żadnych ograniczeń strcpy(). Dlatego zbyt długi ciąg spowoduje przepełnienie bufora. Mają rację. Użycie strncpy()w tym przypadku zapobiegnie przepełnieniu bufora.

Wydaje mi się, że to strncpy()naprawdę nie naprawia błędów: rozwiązuje problem, którego dobry programista może łatwo uniknąć.

Jako programista C musisz znać rozmiar docelowy, zanim zaczniesz kopiować łańcuchy. Takie jest założenie strncpy()i strlcpy()ostatnie parametry: dostarczasz im ten rozmiar. Możesz również poznać rozmiar źródła przed skopiowaniem ciągów. Następnie, jeśli miejsce docelowe nie jest wystarczająco duże, nie dzwoństrcpy() . Albo zmień przydział bufora, albo zrób coś innego.

Dlaczego mi się nie podoba strncpy()?

• strncpy() w większości przypadków jest złym rozwiązaniem: Twój ciąg zostanie obcięty bez powiadomienia - wolałbym napisać dodatkowy kod, aby rozwiązać ten problem samodzielnie, a następnie podjąć działania, które chcę wykonać, zamiast pozwolić, aby jakaś funkcja zdecydowała o tym ja o tym, co robić.
• strncpy()jest bardzo nieefektywny. Zapisuje do każdego bajtu w buforze docelowym. Nie potrzebujesz tych tysięcy '\0'na końcu celu.
• Nie zapisuje zakończenia, '\0'jeśli miejsce docelowe nie jest wystarczająco duże. Więc i tak musisz to zrobić sam. Złożoność tego nie jest warta zachodu.

Teraz dochodzimy do strlcpy(). Zmiany w stosunku strncpy()do tego poprawiają, ale nie jestem pewien, czy specyficzne zachowanie strl*uzasadnia ich istnienie: są one zbyt szczegółowe. Nadal musisz znać rozmiar docelowy. Jest bardziej wydajna niż strncpy()dlatego, że niekoniecznie zapisuje do każdego bajtu w miejscu docelowym. Ale to rozwiązuje problem, który można rozwiązać wykonując: *((char *)mempcpy(dst, src, n)) = 0;.

Nie sądzę, żeby ktokolwiek to powiedział strlcpy()lub strlcat()mógł prowadzić do problemów z bezpieczeństwem, co oni (i ja) mówią, że mogą powodować błędy, na przykład, gdy spodziewasz się, że zamiast jego części zostanie napisany pełny ciąg.

Głównym problemem jest tutaj: ile bajtów skopiować? Programista musi o tym wiedzieć, a jeśli tego nie zrobi, strncpy()albo strlcpy()nie będzie go uratować.

strlcpy()i strlcat()nie są standardowe, ani ISO C, ani POSIX. Dlatego ich użycie w programach przenośnych jest niemożliwe. W rzeczywistości strlcat()ma dwa różne warianty: implementacja Solaris różni się od innych dla przypadków skrajnych o długości 0. To sprawia, że ​​jest jeszcze mniej użyteczna niż w innym przypadku.

Myślę, że Ulrich i inni uważają, że da to fałszywe poczucie bezpieczeństwa. Przypadkowe obcięcie ciągów może mieć wpływ na bezpieczeństwo innych części kodu (na przykład, jeśli ścieżka systemu plików zostanie obcięta, program może nie wykonywać operacji na zamierzonym pliku).

Istnieją dwa „problemy” związane z używaniem funkcji strl:

1. Musisz sprawdzić zwracane wartości, aby uniknąć obcięcia.

Autorzy szkiców standardu c1x i Drepper twierdzą, że programiści nie sprawdzą zwracanej wartości. Drepper mówi, że powinniśmy w jakiś sposób znać długość i używać memcpy i całkowicie unikać funkcji łańcuchowych. Komitet standardów twierdzi, że bezpieczny strcpy powinien zwracać wartość niezerową po obcięciu, chyba że _TRUNCATEflaga stanowi inaczej . Chodzi o to, że ludzie częściej używają if (strncpy_s (...)).

2. Nie można używać na elementach innych niż stringi.

Niektórzy uważają, że funkcje łańcuchowe nigdy nie powinny się zawieszać, nawet po podaniu fałszywych danych. Wpływa to na standardowe funkcje, takie jak strlen, które w normalnych warunkach ulegają awarii. Nowy standard będzie zawierał wiele takich funkcji. Testy mają oczywiście spadek wydajności.

Zaletą proponowanych funkcji standardowych jest to, że możesz wiedzieć, ile danych przegapiłeś dzięki funkcjom strl .

Nie sądzę strlcpyi uważam, że strlcatjest to niebezpieczne, a przynajmniej nie jest to powód, dla którego nie są one zawarte w glibc - w końcu glibc zawiera strncpy, a nawet strcpy.

Krytyka, jaką otrzymali, była taka, że ​​są rzekomo nieskuteczni, a nie niepewni .

Według dokumentu Secure Portability autorstwa Damiena Millera:

Strlcpy i strlcat API poprawnie sprawdzają granice bufora docelowego, kończą nul we wszystkich przypadkach i zwracają długość ciągu źródłowego, umożliwiając wykrycie obcięcia. To API zostało przyjęte przez większość nowoczesnych systemów operacyjnych i wiele samodzielnych pakietów oprogramowania, w tym OpenBSD (skąd pochodzi), Sun Solaris, FreeBSD, NetBSD, jądro Linuksa, rsync i projekt GNOME. Godnym uwagi wyjątkiem jest standardowa biblioteka GNU C, glibc [12], której opiekun stanowczo odmawia włączenia tych ulepszonych API, nazywając je „strasznie nieefektywnymi bzdurami BSD”[4], pomimo wcześniejszych dowodów na to, że są one szybsze w większości przypadków niż API, które zastępują [13]. W rezultacie ponad 100 pakietów oprogramowania obecnych w drzewie portów OpenBSD utrzymuje własne zamienniki strlcpy i / lub strlcat lub równoważne API - nie jest to idealny stan rzeczy.

Dlatego nie są dostępne w glibc, ale nie jest prawdą, że nie są dostępne w systemie Linux. Są dostępne w systemie Linux w libbsd:

• https://libbsd.freedesktop.org/

Są spakowane w Debianie i Ubuntu oraz innych dystrybucjach. Możesz też po prostu pobrać kopię i użyć w swoim projekcie - jest krótki i na licencji:

• http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/strlcpy.c?rev=1.11

Bezpieczeństwo nie jest wartością logiczną. Funkcje C nie są całkowicie „bezpieczne” lub „niepewne”, „bezpieczne” lub „niebezpieczne”. W przypadku nieprawidłowego użycia prosta operacja przypisania w C może być „niepewna”. strlcpy () i strlcat () mogą być używane bezpiecznie (bezpiecznie) tak samo, jak strcpy () i strcat () mogą być bezpiecznie używane, gdy programista zapewnia niezbędne gwarancje prawidłowego użycia.

Głównym punktem z wszystkich tych funkcji ciągów C, standard i nie-tak-standard, to poziom, do którego one bezpieczne / bezpieczne użytkowanie łatwa . strcpy () i strcat () nie są trywialne w bezpiecznym użyciu; dowodzi tego liczba razy, kiedy programiści C popełnili błąd przez lata i pojawiły się paskudne luki i exploity. strlcpy () i strlcat () oraz strncpy () i strncat (), strncpy_s () i strncat_s (), są nieco łatwiejsze w użyciu, ale nadal nie są trywialne. Czy są niebezpieczne / niepewne? Nie więcej niż memcpy (), gdy jest używane nieprawidłowo.