CVE-2022-35737, an arbitrary code execution vulnerability in SQLite, affects all versions released in the past 22 years.
https://blog.trailofbits.com/2022/10/25/sqlite-vulnerability-july-2022-library-api/
@1a2b3c4d5e: to dość ogólne słowo, może być taki prosty fuzzer co tylko losowe parametry podaje i on nie znajdzie, ale można bardziej zaawansowanego napisać, który będzie generował losowe programy przy zastosowaniu biblioteki i je kompilował, a dodatkowo fuzzował do nich parametry.
Losowe to też nie jest dobre słowo bo te programy mogą mutować, losowość nie była by zbyt efektywna 99,999% przypadków byłby po prostu crash związany z błędami syntaxu.
@Wypierdzistyy: losowość nie była by zbyt efektywna 99,999% przypadków byłby po prostu crash związany z błędami syntaxu.
czyli byłaby efektywna? przecież odnalezienie crasha jest chyba pożądane
@a14122011: Z tego, co zrozumiałem z blogposta - aby wywołać ten błąd, należy jako jeden z parametrów podatnej funkcji podać string o długości powyżej 1GB. Zapewne przy fuzzowaniu większość ludzi ustawiłaby maksymalny rozmiar inputu dużo niżej.
@Sensacyjny Sebastian: Zapewne przy fuzzowaniu większość ludzi ustawiłaby maksymalny rozmiar inputu dużo niżej.
tylko czy to nie niszczy sensu fuzzingu?
string o długości powyżej 1GB
Kto w ogóle zezwala na takie coś na wejściu, żeby potem wysłać to do bazy danych?
@KamilAdam: nie pisz tak bo zaraz przyjdą i cię zwyzywają, a i tak nie podadzą alternatywnego rozwiązania, ja powiem tak wolę inżynierię czyli najpierw tworzysz coś żeby to działało i potem udoskonalasz produkt, jak wszystko.
@Wypierdzistyy: Przecież rozwiązaniem jest trzymanie tego w plikach a nie bazie
@Wypierdzistyy: Napisałeś, że nie podadzą alternatywnego rozwiązania i do tego się odniosłem
@anonimowy: sorry pijany jestem, wychodzi podobnie jedynie są lepsze algorytmy w szeregowaniu danych i dostępie do nich. Plik się kojarzy z danymi bez żadnych algorytmów takich surowych, a też można z algorytmem zapisywać w jakiś sprytny sposób.
czy fuzzing nie powinien tego wyłapać?