Угрозы безопасности при использовании bar() и bar(void)

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

Если вызываемая подпрограмма не имеет такого параметра, она не получит значение из назначенного места. Тогда ничего больше не произойдет в отношении спора. Вызывающая подпрограмма может поместить значение в указанное место, но вызываемая подпрограмма не будет его использовать. Ничего не будет перегружено. Аргумент просто игнорируется и не имеет никакого эффекта.

В этой ситуации атака невозможна.

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

Аргументы передаются куда-то (регистр/стек/куча) в зависимости от ABI, но если вызываемый объект для примеров никогда не извлекает стек, то к аргументам не будет доступа. Переменная a выделяется при входе в функцию, поэтому после того, как аргументы были записаны в вызывающей стороне, перед вызовом, ее нельзя перезаписать.

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

Как ни странно, при проверке стека с помощью GDB (используя 'info Frame'), это не говорит о том, что строка была передана.

В языке C строки не передаются по значению, а только по указателю. Таким образом, вы передаете ссылку на строковый литерал. Строковый литерал будет храниться там, где реализация хранит константные данные (не в стеке).

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

bar((struct {char a[30];}){"hhhhhhhhhhhhhhhhhhhhhhhh"});

Он будет помещен в стек (с отключенной оптимизацией).

main:
        push    rbp
        mov     rbp, rsp
        sub     rsp, 32
        movabs  rax, 7523377975159973992
        mov     rdx, rax
        mov     QWORD PTR [rbp-32], rax
        mov     QWORD PTR [rbp-24], rdx
        movabs  rax, 7523377975159973992
        mov     edx, 26728
        mov     QWORD PTR [rbp-18], rax
        mov     QWORD PTR [rbp-10], rdx
        sub     rsp, 32
        mov     rcx, rsp
        mov     rax, QWORD PTR [rbp-32]
        mov     rdx, QWORD PTR [rbp-24]
        mov     QWORD PTR [rcx], rax
        mov     QWORD PTR [rcx+8], rdx
        mov     rax, QWORD PTR [rbp-18]
        mov     rdx, QWORD PTR [rbp-10]
        mov     QWORD PTR [rcx+14], rax
        mov     QWORD PTR [rcx+22], rdx
        mov     eax, 0
        call    bar
        add     rsp, 32
        mov     eax, 0
        leave
        ret

Но вызываемая функция создаст свой собственный фрейм стека - отдельный от "hhhhhhhhhhhhhhhhhhhhhhhh" функции.

bar:
        push    rbp
        mov     rbp, rsp
        sub     rsp, 16
        mov     DWORD PTR [rbp-4], 4
        mov     eax, DWORD PTR [rbp-4]
        mov     esi, eax
        mov     edi, OFFSET FLAT:.LC0
        mov     eax, 0
        call    printf
        nop
        leave
        ret

Поэтому ничего опасного не произойдет, поскольку оба кадра стека не перекрываются.

Давайте рассуждать об этом логически. Если у вас есть функция foo(), которая принимает любое количество параметров, есть два случая:

1. Реализация функции производилась с учетом этого факта и сознательного обращения к получаемым параметрам.
2. Реализация функции производилась без знания этого факта и, следовательно, без ссылки на возможно полученные параметры.

Таким образом, если вы напишете код, который злонамеренно вызывает функцию, то на основе вашего вызова функция все равно будет определена параметризованным образом, но переданные параметры будут либо ожидаемыми и приветствуемыми функцией, либо неожиданными и проигнорированными.

Таким образом, внутри функции нет реальной опасности.

За пределами функции существует небольшая «опасность», поскольку, таким образом, если вы скомпилируете два разных кода с определением foo() в обоих, а затем проведете их реверс-инжиниринг и соедините их вместе, вы можете получить противоречивые определения. Но если это произойдет, такую ​​проблему можно исправить, и хакерам не стоит утруждать себя созданием ошибки, которую можно легко исправить. Никакой кражи данных или даже повреждения данных не происходит.

Тем не менее, реальная опасность такой функции, как foo(), заключается в том, что она устарела, и некоторые компиляторы с какого-то момента могут отказаться ее разрешать.

РЕДАКТИРОВАТЬ

@Caulder сделал полезное замечание в разделе комментариев, заявив:

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