уязвимость glibc fnmatch: как выявить уязвимость?

Question

Я должен проверить уязвимость в одной из наших 64-разрядных систем, на которой выполняется glibc-2.9.

http://scarybeastsecurity.blogspot.in/2011/02/i-got-accidental-code-execution-via.html

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

Answer 1

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

$ bc 
z=1073741796 
z+28 
1073741824 
(z+28)*4 
4294967296 
2^32 
4294967296 
quit 
$ 

Таким образом, один из способов описания числа входа (ULONG_MAX - 112)/4.

Аналога номер для 64-битной машины является 4611686018427387876:

$ bc 
x=2^64 
x 
18446744073709551616 
y=x/4 
y 
4611686018427387904 
y-28 
4611686018427387876 
quit 
$ 

Впрочем, есть шанс этой работы, вы должны были бы изменить заявленный код, чтобы использовать strtroull() или что-то подобное; atoi() обычно ограничивается 32-разрядными целыми числами и не будет использоваться для 64-разрядных чисел выше. Кодекс также содержит:

num_as = atoi(argv[1]); 
if (num_as < 5) { 
    errx(1, "Need 5."); 
} 
p = malloc(num_as); 

Где num_as является size_t и p является char *. Таким образом, вы должны были бы иметь malloc() гигантское пространство (почти 4 EiB). Для этого большинству людей не хватает виртуальной памяти на своих машинах, даже с дисковым пространством для поддержки. Теперь, может быть, может быть, Linux может позволить вам перехватить (и пусть позже нападет OOM Killer), но скорее произойдет сбой malloc().

Были и другие функции, которые были релевантными и влияли на 32-битные системы таким образом, что они не могут повлиять на 64-битные системы (пока).

Если у вас есть шанс воспроизвести его на 64-битной машине, вам, вероятно, придется выполнить 32-битную компиляцию. Затем, если ветер позади вас, и у вас есть соответствующие старые версии соответствующего программного обеспечения, возможно, вы можете воспроизвести его.

Answer 2

Если вы работаете на 64-битной машине, исходные обстоятельства ошибки не применяются. Как вы можете видеть в блоге Криса, он использует 32-битную систему Ubuntu 9.04. Эксплоит полагается на то, что указатель стека обернется вокруг 32-разрядного адресного пространства, что приведет к повреждению стека.

Я быстро попробовал 64-битную систему с glibc 2.5, но видел сбои malloc() вместо сбоев.

$ ./a.out 3000000000 
a.out: malloc() failed. 

Вы спрашивали, как определить случайное выполнение кода; с игрушечной программой здесь, которая не несет в себе эксплойта/полезную нагрузку, мы ожидаем увидеть либо SIGSEGV, SIGILL, либо SIGBUS, поскольку ЦП попытался «выполнить» нежелательные части стека, показав соответствующую ошибку сообщение из оболочки.