Хинты для пар аргументов buf и len

[nataraj-hates-MS-for-stealing-github]

Начали прогонять FUTAG на большом объеме целей и сразу споткнулись на функциях в которые передаются парой буфер и его размер. Для кода на C это штатное явление.

Автоматически выявить в аргументах пару буфер и его длинну явно будет затруднительно. А вот глазами это обычно сделать не сложно.

Чтобы раз и навсегда для таких функций исключить false-positive связанный с переполнением буфера, есть идея перед генерацией целей сообщать футагу файл с хинтами, подсказывающего ему для каждой фунцуии какие из аргументов являются парой buf и len. И тогда бы футаг мог бы устанавливать len в соотвествии с фактическим размером буфера и таким образом избегать излишний ложных срабатываний.

[nataraj-hates-MS-for-stealing-github]

В коментарии приглашается @CourteousSleet....

[CourteousSleet]

Поддерживаю запрос

[thientc]

Согласен, это будет полезная фича!

[CourteousSleet]

Я тут заметил, что похоже FUTAG умеет определять, какие должны быть аргументы?

//GEN_CSTRING1                                                                                                                                                                                     
char * rstr_salt = (char *) malloc((dyn_cstring_size[1] + 1)* sizeof(char));
memset(rstr_salt, 0, dyn_cstring_size[1] + 1);
memcpy(rstr_salt, futag_pos, dyn_cstring_size[1]);
futag_pos += dyn_cstring_size[1];
const char * str_salt = rstr_salt;
   
//GEN_SIZE
 int sz_saltlen = (int) dyn_cstring_size[1];

В нашем случае функция принимает str_salt - buf и sz_saltlen - len. И как я проверил в дебаге, они всегда соответствовали друг другу, что понятно, раз они используют dyn_cstring_size[1]. Но в документации я не видел описание такого функционала. Если это всегда работает безотказно, то это очень удобно.

[thientc]

По анализу (ну, который я провел) в большинстве случаев, buf и len идут по парам, и сначала идет char*, const char *, ... , потом будет size_t, int, ... Futag зафиксирует эти случаи и передает строку и ее длину. Вт, 24 окт. 2023 г. в 10:00, Ian ***@***.***>:

…

Я тут заметил, что похоже FUTAG умеет определять, какие должны быть аргументы? //GEN_CSTRING1 char * rstr_salt = (char *) malloc((dyn_cstring_size[1] + 1)* sizeof(char)); memset(rstr_salt, 0, dyn_cstring_size[1] + 1); memcpy(rstr_salt, futag_pos, dyn_cstring_size[1]); futag_pos += dyn_cstring_size[1]; const char * str_salt = rstr_salt; //GEN_SIZE int sz_saltlen = (int) dyn_cstring_size[1]; В нашем случае функция принимает str_salt - buf и sz_saltlen - len. И как я проверил в дебаге, они всегда соответствовали друг другу, что понятно, раз они используют dyn_cstring_size[1]. Но в документации я не видел описание такого функционала. Если это всегда работает безотказно, то это очень удобно. — Reply to this email directly, view it on GitHub <#86 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADA7KV7HHGKWLAFBQ2FO53LYA5RPTAVCNFSM6AAAAAA6LZCK6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWGYZTMNJUHE> . You are receiving this because you commented.Message ID: ***@***.***>

[nataraj-hates-MS-for-stealing-github]

Ага... Вот оно как... Наверное это не плохой метод.

А это отражено в документации? Если нет, то надо бы отразить, а то мы всю голову себе сломали...

И отдельный вопрос, а что будет если эта эвристика ложно сработает? У нас есть шанс об этом узнать?

[thientc]

Знаем только после генерации. Поэтому хинт - хорошее предложение.
Придется подумать как это будет. Хинт по названию переменных (buf, len, buffer, length...) или по последовательности типов.

Кстати, при аварийному завершению всегда надо проверить по какой причине. Futag умеет автоматический выгрузить крэш в GDB и генерирует трассу, записывает значения и т.д.

[CourteousSleet]

А какой метод это делает?

[thientc]

Задавайте gdb=True в инициализации модуля fuzzer.

Кстати, выложу здесь причины ложных срабатываний:

[nataraj-hates-MS-for-stealing-github]

Придется подумать как это будет. Хинт по названию переменных (buf, len, buffer, length...) или по последовательности типов.

Тут с моей точки зрения нужно явное указание пар Функция A аргументы a1 и a2 -- пара буфер-длинна. аргументы a3 и a4 -- независимые, и их автоматическое объединение в пару надо отключить...

Раз есть автоматика находящая пары, значит должна быть возможность отключать ее для конкретных случаев, когда она не уместна...

[nataraj-hates-MS-for-stealing-github]

К стати, для той функции из за которой все началось по результатам переполнение оказалось совершенно по другой причине: она предполагала результирующий буфер фиксированной длинны, и падала когда передавали указатель указывающий на что-то более короткое...

Это наверное тоже в тему хинтов... Чтобы не цель выключать, а генерацию поправить...

[thientc]

Ребята, я вернулся на родину, пока не могу активно заниматься Futag-ом. Попробуйте все функции, параметры Futag-а и если будет возможность, опишите пожалуйста конкретно что надо делать. Спасибо!

[nataraj-hates-MS-for-stealing-github]

Конкретно: принимать футагом перед генерацией целей некоторый hint-файл в текстовом формате (json? yaml?), который бы менял поведение futag'а при автоопределении стратегии создания оберток для аргументов.

В хинт файле указывается имя файла исходных текстов, имя функции, а дальше для каждого аргумента (или пары аргументов )можно было бы указать следующее:

1. Пара аргументов char * a1, unsigned int a2, являются парой буфер, длинна, даже если не срабатывает автодетектор таких пар
2. Пара аргуметнов char * str, size_t item_count не являются парой буфер длинна, даже если детектор говорит иначе
3. Аргумент char * buf -- является буфером фиксированной длинны (размер буфера явно указывается в hint-файле), футаг не создает аргумент указывающий на область памяти меньшей чем указано в хинт-файле...

Возможно в будущем появятся какие-то еще кейсы. Это пока то на что мы наткнулись и что в процессе стало очевидно...