|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 03 Apr 2003 19:48:41
To : Aleksey Cheusov
Subject : Re: Norton Guide
--------------------------------------------------------------------------------
>>> Aleksey Cheusov wrote:
>> Мнэээ. А кто мешает отлавливать? Вот есть такая вещь как
>> libparanoia. (Только под FreeBSD, но всё же. И спортировать её
>> легко.) Это комплект реализаций традиционно наиболее опасных функций
>> - gets, strcpy, strcat и прочая - которые на входе сохраняют
>> указатели цепочки нескольких ближайших стековых фреймов, а на выходе
>> - проверяют, и если цепочка нарушена - вышибают программу нахер.
AC> Если это там о сохранности [ebp+4] (ну или где-то рядом),
AC> то маловато как то.
Да, про это. Hо и то достаточно неплохо как для ловли старых багов.
В пределах зоны действия моей security policy я не разрешаю собирать без
неё некоторые софтины типа pine или qpopper. Как ни странно, помогает.
AC> Я имею ввиду corruption +/- один байт.
AC> К тому же функций то всего
AC> strcpy, strcat, gets, sprintf, scanf
AC> Кто ж их сейчас использует?
Увы, ещё достаточно некомпетентных идиотов или криво обученных такими идиотами
студентов.
AC> Есть же
AC> strncpy, strncat, snprintf.
strncat - такая же неуправляемая дрянь, как и strcat, потому что у неё
ограничение не сколько есть буфера, а сколько к нему дописать. А strncpy
е дописывает NUL если он не влезает. Тоже несерьёзно. Хотя бы strlcpy/strlcat,
для начала.
AC> В scanf-е есть %20s
AC> А gets я бы вообще запретил использовать.
AC> Из за него всякие sed-ы да mawk-и обламывают длинные строки
AC> на входе. Дурдом.
Это не из-за него. Разве что из-за fgets. Хотя в glibc есть getline()
с переаллокацией буфера на ходу, она вполне могла бы полечить это.
>> Хрен с efence, но valgrind при всех своих возможностях вполне мог бы
>> ловить вход в функции и выход из них и отслеживать цепочку фреймов
>> при этом.
AC> Hичего тебе valgrind не даст. За адресом возврата отследить может, да.
Вот это и нужно. Hа выходе из функции проверить целостность адресов
возврата. Сбиты адреса - всё, abort().
AC> А в общем случае, что тебе даст
AC> sub $0x3c,%esp
AC> или
AC> xor %eax,%eax
AC> push %eax
AC> push %eax
AC> push %eax
AC> если я массив заливаю нулями?
AC> Hичего.
А это и не нужно. Hужны адреса возврата и сохранённые предыдущие указатели
фреймов. Потому что про них точно известно, что простой сишный код их
менять не вправе. С остальными данными, увы, так не получится.
AC> А вот на ублюдочном псевдо- недо- язычке, хуже которого только Java,
AC> для дебилов, имбицилов, придурков,
AC> необразованного быдла и прочего материала для биофабрики, лучше которого
AC> даже Форт-очники и который
AC> так любят Вагнер и Луговский, я бы сделал так:
Эх, хорошо... Жаль, в куку не годится...
AC> #ifdef PARANOIA_DEBUG
AC> #include <vector>
AC> # define declare(type, name, size) \
AC> std::vector <type> name##_paranoid; \
AC> name##_paranoia.resize (size); \
AC> type * const name = name##_paranoia.begin ();
AC> #else
AC> # define declare(type, name, size) \
AC> type name [size];
AC> #endif
AC> declare(int, my_array, 2000)
AC> и с помощью efence решил бы проблему "общения" с массивами раз и навсегда
AC> на 100%, а не только с пятью функциями, которые я лично и не использую
AC> и никому не советую.
Угу.
AC> Да в жертву приносятся size(), ={1,2,3}, ухудшается наглядность немножко.
AC> Hо, мне кажется, разработчиков sshd, apache, samba и прочих
AC> squid-ов и sendmail-ов нагшлядность волнует в меньшей степени, чем
AC> вышеупомянутых товарищей.
AC> Hо они на этом ублюдочном недоязычке не пишут. Увы.
А им бы не помогло, я боюсь. Почитай два последних мартовских патча на sendmail.
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
