Comments 22
Интересно, статический анализ помог бы? Вроде ж open source, а такие ошибки пролазят и живут десятилетиями.
Когда есть альтернатива, натсоящий программист напишет заново. (/sarcasm)
Какой уровень нужен для запуска cppcheck?
Естественно, что лучше всего быть богатым и здоровым, но если уже так получилось, что написали на плюсах — не нужно засовывать голову в песок и оправдываться, что переписывать — лучший выход.
Так не работает.
Люди это не роботы, они хотят постоянно сократить путь: написать меньше кода; не запускать cppcheck; махнуть рукой на часть исправлений что предлагает cppcheck. К сожалению, координальное решение проблемы это именно не оставить шанса накосячить, а не ходить за всеми и перепроверять их работу — просто не эффективно.
написали на плюсахЕсли что, pppd на чистом C, причём походу старее C99.
static void
eap_request(esp, inp, id, len)
eap_state *esp;
u_char *inp;
int id;
int len;
{
Ого. Это же ещё K&R С — задолго до стандартизации. Можно вызывать eap_request с параметрами любых типов и будет только предупреждение. Или не будет. Этот код компилируется gcc без предупреждений.
#include <stdio.h>
int square(x)
int x;
{
return x*x;
}
struct foo {
void * ptr;
};
int main(int argc, char **argv)
{
struct foo s;
int sq = square(s);
printf("%d\n", sq);
}
Походу пора все переписывать на rust, чтобы уже закрыть вопросы с подобными проблемами
Rust не решит кардинально эту проблему. Судя по патчу исправляющему уязвимость,
основная проблема это арифметическое переполнение. Такого рода проблемы детектируются только в отладочной сборке программы на Rust. Так что смещение в буфере (или что там вычисляется) было одинаково с ошибкой вычислено в Rust и в C. Другой вопрос, что при обращению по этому смещению программа на Rust упала бы из-за panic, а не позволила бы использовать арифметическое переполнение для "получения root". То есть уязвимость была конечно намного менее неприятна — DDoS вместо root, но все равно бы была.
То есть уязвимость была конечно намного менее неприятна — DDoS вместо root, но все равно бы была.
Ну и в логах было бы: упали в такой-то строке с таким-то коллстеком.
Ну и в плюсах если упали можно увидеть лог и стек.
Если оно упало из-за UB, стектрейс может не иметь никакого отношения к источнику ошибки. Истории про поиск бага неделями не редкость.
Истории про поиск бага неделями не редкость.
Ну в случае с Rust было бы лучше, но не совсем. То есть ясно
что упали с "index out of bounds" и ясно про какой индекс и массив
идет речь, но если при расчете индекса использовалось с десяток арифметических
операций и каждый раз использовались какие-то сторонние данные,
то разобраться тоже будет не просто откуда у нас взялся такой странный индекс. То есть да, все будет на порядок проще и безопаснее, но все проблемы не исчезнут при переписывании как мановению волшебной палочки..
если при расчете индекса использовалось с десяток арифметических
операций и каждый раз использовались какие-то сторонние данные
Ещё есть checked_add, _sub, _mul и _div, которые так и просятся для обработки недоверенных данных, приходящих извне. А то, что Раст — не серебряная пуля, у меня почему-то удивления совсем не вызывает.
Найдена уязвимость в pppd, позволяющая удаленно выполнить код с правами root