Если в двух словах: усиление #XOnly / #ASLR / pinsyscalls(2)
В момент выполнения эксплойта в "мертвой" части стека могут остаться адреса из libc.so и/или ld.so. Что-то вроде printf -> fprintf -> __vfprintf. С этим сложно будет работать, но это может дать зацепку атакующему.
Соответственно, на x86 платформе для libc, libcrypto, ld.so, исполняемых файлов ssh и ядра вместо:
Hacker News
continue callq somethingбудет генерироваться код:
callq something
movq $0, -8(%rsp)Для других аппаратных платформ реализация будет другой, для некоторых зачистка адреса будет происходить на вызываемой стороне.
Остается проблема оставления в стеке значений переменных, указывающих на адреса в libc.so и/или ld.so (например: указатель на функцию).
#OpenBSD: Testing wanted: execute-only on amd64
Theo de Raadt (deraadt@) предлагает к тестированию режим #xonly для архитектуры amd64. xonly это следующий шаг после W^X, когда секция кода становится доступна только на исполнение (то есть становится недоступна даже на чтение).
xonly уже работает для ряда архитектур: arm64, riscv64, ... Теперь приходит время внедрения этой функциональности для архитектуры amd64. Для тестирования режима xonly CPU должен поддерживать функцию PKU (Memory Protection Keys for User-mode pages).
Пока xonly для архитектуры amd64 представлена в виде kernel diff, который нужно приметить исходным текстам и собрать своё ядро. deraadt@ призывает тех, кто самостоятельно способен собрать ядро с примененным патчем, протестировать работу приложений в этом режиме. При тестировании стоит удостовериться, что ktrace -di в конце выдает SIGSEGV и включить фрагмет с SIGSEGV в результаты тестирования.
Предполагаются проблемы в портах, где встречаются ассемблерные файла, в которых данные только для чтения располагаются в секции .text, а не в .rodata.
Peter N. M. Hansteen