Ciekawe, czy w oryginalnych narzędziach coreutils zdarzają się jeszcze jakieś podatności.
Rozumiem implementację jakichś kodeków czy parserów w rust, bo tam łatwo jest popełnić błąd, ale takicksumalbosortma chyba niskie ryzyko wystąpienia krytycznej dziury?Proszę bardzo https://nvd.nist.gov/vuln/detail/CVE-2025-5278
Ale fakt, że w coreutils raczej jest mało błędów bezpieczeństwa. W tym roku to jest jedyny błąd (jak do tej pory), poprzedni był w 2024 (też jeden), a jeszcze poprzedni był dopiero w 2017 roku. W busybox też zdarzają się błędy w ich implementacja tar, awk itp.
Inna sprawa, że znalezienie błędu to jedno, a drugie to praktyczne wykorzystanie w ataku. Możliwe, że żadne z poleceń coreutils, nie będzie wykorzystywane przez jakąś usługę sieciową wystawioną na zewnątrz i nawet nie masz jak sprowokować tego błędu. A nawet jeżeli ci się uda, to możesz rozbić się o jedno z zabezpieczeń kompilatora (np stack canaries albo fortify source). Twórcy glibc nawet powiedzieli, że nie planują dodać tych nowych bezpiecznych funkcji z C11, ponieważ fortify source już daje podobny poziom ochrony (https://sourceware.org/glibc/wiki/FAQ#Why_no_strlcpy_.2F_strlcat.3F ).
Czy
sudosię liczy?
Były całkiem ładne komentarze ze strony osoby która to koordynuje w kanonikal. Pisał, że własnie dlatego nie wprowadzili tego do LTS. Współpracują z twórcami, płacą im za wdrażanie odpowiednich poprawek. Do czasu wydania LTS powinni się z tym uporać. Ludzie twierdzą, że bez wdrożenia pewnie nawet by się nie zetknęli z niektórymi problemami i nie mieli tyle doświadczeń do poprawy.
