Здравствуйте, скажите пожалуйста, такой вопрос, вот я смотрю такую тему как "Переполнение буфера" и в 99.9% случаев приводят winapi'ную подпрограмму strcpy и вот хочу спросить, больше не существует мест уязвимых под переполнение буфера, а если есть то какие наиболее известные подходы их нахождения?

| Сообщение посчитали полезным:

ssize_t read(int fd, void *buf, size_t count); при count > sizebuf
char *gets(char *s);
char *fgets(char *s, int size, FILE *stream);
int sprintf(char *str, const char *format, ...);

-----
127.0.0.1, sweet 127.0.0.1

| Сообщение посчитали полезным:

В Android была ржака.
Целочисленное переполнение в new.
Если буфера мало, его что угодно переполнит.

| Сообщение посчитали полезным:

alex-rudenkiy пишет:
Здравствуйте, скажите пожалуйста, такой вопрос, вот я смотрю такую тему как "Переполнение буфера" и в 99.9% случаев приводят winapi'ную подпрограмму strcpy и вот хочу спросить, больше не существует мест уязвимых под переполнение буфера, а если есть то какие наиболее известные подходы их нахождения?

Любая функция которая работает с буфером теоретически может быть причиной переполнения если буфер неправильно выделен.

-----
http://ntinfo.biz

| Сообщение посчитали полезным: sefkrd

alex-rudenkiy

Это лишь самый простой пример, строковая линейная запись в буфер. Или вам обучалки нужны на ядерных функциях, в которых чёрт ноги поломает

Добавлено спустя 17 минут
> есть то какие наиболее известные подходы их нахождения?

Этим вопросом не только вы интересуетесь

Это называется OP-атаками. Обьектом таких атак являются алгоритмические ошибки. Проверки статического буфера сам компилер выполняет. Ошибки в алгоритмах находятся только по крэшам или человеческим анализом кода. Инструмента нет, это очень сложная и не решённая задача.

-----
vx

| Сообщение посчитали полезным:

alex-rudenkiy пишет:
приводят winapi'ную подпрограмму strcpy

winapi'ную?..

alex-rudenkiy пишет:
больше не существует мест уязвимых под переполнение буфера, а если есть то какие наиболее известные подходы их нахождения?

Стресс-тестирование.
А наиболее частая и неприятная ошибка - это т.н. "+/-1", когда для завершающего ноля строки места не хватает.
Приводит к случайной порче данных, расположенных следом за переполненной строкой.

difexacaw пишет:
Проверки статического буфера сам компилер выполняет.

В большинстве случаев такие проверки выполнить невозможно.
Например:




| Сообщение посчитали полезным:

OKOB пишет:
char *gets(char *s);

Вы уверены?
Я проверил, переполнения нет, по крайне мере не один из регистров не изменился на "616161616161"

4b2c_01.04.2018_EXELAB.rU.tgz - 2018-04-01_22-39-01.png

| Сообщение посчитали полезным:

alex-rudenkiy пишет:
не один из регистров не изменился на "616161616161"

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

-----
127.0.0.1, sweet 127.0.0.1

| Сообщение посчитали полезным:

OKOB пишет:
во-первых, уверены, что переполнили буфер?

Точно, массив char s[5], а значений гораздо больше

Добавлено спустя 17 минут
OKOB пишет:
во-вторых, какая связь между переполнением буфера и попаданием этих значений в регистры?

Сори за мега глупый вопрос, но как выполнить return адреса который идёт после мусора в буффере?

Добавлено спустя 20 минут
alex-rudenkiy пишет:
Сори за мега глупый вопрос, но как выполнить return адреса который идёт после мусора в буффере?

Уже понял, спасибо

| Сообщение посчитали полезным:

alex-rudenkiy

> Сори за мега глупый вопрос, но как выполнить return адреса который идёт после мусора в буффере?


Исполняемый контекст переписывается в буфере. Есть разные вариации, самый простой - при входе в функцию сохраняется адрес возврата, в той же области памяти, что и уязвимый буфер. Это пространство стека, в котором находятся переменные и атакуемая область. Это классическая ROP атака. Система это блокирует несколькими путями - отслеживает изменение маркеров перед областью с выполняемым контекстом, использует теневой стек для проверки и есчо некоторые методы.

-----
vx

| Сообщение посчитали полезным:

alex-rudenkiy пишет:
Вы уверены?
Я проверил, переполнения нет, по крайне мере не один из регистров не изменился на "616161616161"

Переполнение есть. Программа падает, если введено больше 5 символов. (А их должно быть максимум 4).
f0ca_02.04.2018_EXELAB.rU.tgz - gets4.exe

Кстати, в WinApi нет таких функций в принципе, об этом подумали в микрософте.
Это стандартная си-функция, поэтому ещё переспросил в предыдущем посте:

dosprog пишет:
winapi'ную?..




| Сообщение посчитали полезным:

Любая функция которая пишет в память или работает с указателями может быть потенциально опасной, любая функция которая пишет в буфер может быть опасной. Даже функции с валидацией размера буфера может быть опасной, в некоторых случаях и при некоторых оптимизациях компилятор может выкинуть проверку.

| Сообщение посчитали полезным: difexacaw

shellstorm

Верно, но даже функция с абсолютно корректной валидацией всех параметров может быть уязвимой, при асинхронном использовании входных параметров(RC-атаки). Для этого нужен второй поток, это локально не важно, но имеет значение в целом.

-----
vx

| Сообщение посчитали полезным:

В любом случае, найти такие ошибки можно [практически] только тестированием.
Кстати, нормальные тестировщики это не прыщавые девочки-подростки с зарплатой 350 уёв,
а пожилые прошаренные дядьки с зарплатой на порядок большей.
Но их мало.

| Сообщение посчитали полезным:

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

Сам язык с\с++ с рантаймом не является безопасным, поэтому проблемы могут вылезти где угодно, плата за нулевую стоимость функций, то есть отсутствие избыточных проверок из за которых проседает скорость и увеличивается размер. RC-атаки это отдельный класс и существует даже в относительно безопасных языках.

| Сообщение посчитали полезным:

dosprog

Кстати, в WinApi нет таких функций в принципе, об этом подумали в микрософте.

--> А они есть<--

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

dosprog пишет:
Кстати, в WinApi нет таких функций в принципе, об этом подумали в микрософте.
Это стандартная си-функция, поэтому ещё переспросил в предыдущем посте:
Ну как-бы любая API функция, которая возвращает данные переменной длинны, сотни их.
GetModuleFileName, RegQueryValue, ...

| Сообщение посчитали полезным:

kunix
Эти все запрашивают размер буфера. Единственное, как здесь можно переполнить буфер - это если рукожоп не уследит и передаст длину unicode-строки вместо ее размера.

| Сообщение посчитали полезным: dosprog

ARCHANGEL пишет:
--> А они есть<--

Типа да

Warning Do not use. Consider using StringCchCopy instead. See Remarks.



| Сообщение посчитали полезным:

dosprog

Ну так и в линуксах не говорят: "юзайте их почаще". Но вы не признаетесь, что провтыкали АПИ?

-----
Stuck to the plan, always think that we would stand up, never ran.

| Сообщение посчитали полезным:

ARCHANGEL пишет:
Но вы не признаетесь, что провтыкали АПИ?

Да в виндоусе полно всякого напихано, для собственных нужд,
многое раньше было вообще недокументировано, пипл даже книги писал на эту тему.

В частности, lstrcpy() экспортируется kernel32'ом, а есть одноимённая стандартная си-функция в рантайм-библиотеке msvc, которой и рекомендуют(не-рекомендуют) пользоваться.

А так в kernel32.dll есть и [упрощённая] sprintf(), которой микрософтовцы часто пользуются,
но пользователям такие вещи делать не рекомендуют.

Никогда мне не нравилось выдёргивание служебных api из kernel32,
пользовался либо стандартным рантаймом msvc, либо собственными функциями, типа lstrcpy().
[...]



| Сообщение посчитали полезным:

dosprog пишет:
но пользователям такие вещи делать не рекомендуют
Интересно, почему? Вот не используем RTC по некоторым причинам, а sprintf() необходима, что тогда делать? Самому писать? Они это рекомендуют? )

-----
IZ.RU

| Сообщение посчитали полезным:

)) Кто в состоянии написать sprintf() самостоятельно, тому те рекомендации и не нужны.
И потом, можно же импортировать её и из msvcrt.dll
А так вообще, самые фэншуйные для микрософта пользователи пишут приложения на VB и на .NET.

В принципе, kernel32.dll это системная библиотека и в другой системе, теоретически, её может вообще не оказаться, теоретически. Или она может как-то там не так работать и не то экспортировать. Теоретически.

Обо всяких микрософтовских рекомендациях -
есть такой Шульман, написал в своё время бестселлер "Неофициальная Windows 95", так он рекомендует считать, что в микрософте руководствуются поговоркой "dont listen what we talk, see what we do."

| Сообщение посчитали полезным:

dosprog пишет:
теоретически, её может вообще не оказаться
Кто-нибудь уже наблюдал такое чудо? )

-----
IZ.RU

| Сообщение посчитали полезным:

Ну, в очередной Windows205х вполне может такое случиться, когда они решат разом похоронить всё 32-битное.
Но тогда, правда, уже и старинные рантайм-библиотеки подсовывать уже не поможет


.. впрочем, если подытожить, - то и в msvc всякие вызовы WinAPI линкуются с прямыми вызовами kernel32.dll,
так что все эти рассуждения насчёт "не пользоваться kernel32'ом напрямую" явно зыбки
и может даже ни о чём..

| Сообщение посчитали полезным:

Ядерная sprintf() не поддерживает float, double и, возможно, некоторые расширенные параметры форматирования. Но если от нее нужно только %s, %ls, %d, %u, %x, то вполне можно пользоваться.

| Сообщение посчитали полезным:

rmn пишет:
Ядерная sprintf() не поддерживает float, double и, возможно, некоторые расширенные параметры форматирования.

Не возможно, а точно не поддерживает.
Её возможностей хватает, чтобы выводить системную информацию в целых числах и строках,
а всякие изыски вроде "%*.*f" она не воспринимает.




| Сообщение посчитали полезным: