Серьезная уязвимость в ядре Linux >= 2.6.39

Вчера заметил новость про уязвимость в ядрах linux начиная с версии 2.6.39. С такими ядрами у меня только две машинки, на которые доступ имею только я. В принципе для эксплуатации этой уязвимости нужно иметь локальный доступ, а из сетевых сервисов на этих машинках только SSH, поэтому я успокоился.

Утром обнаружил дополнения к новости, где говорилось, что уязвимы ядра 2.6.32-220.el6 в последних RHEL/CentOS. А вот это уже много хуже. У меня как минимум 2 сервера, где стоит последний CentOS и может быть уязвимое ядро. В качестве проверки на уязвимость я взял исходник, который редхатовцы предложили в своей security advisory.

На потенциально уязвимых серверах скомпилировал и выполнил тестовый пример.

# wget 'https://bugzilla.redhat.com/attachment.cgi?id=556461' -O cve-2012-0056.c 
# gcc -o cve-2012-0056 cve-2012-0056.c
# ./cve-2012-0056
vulnerable

Проверка показала, что один из серверов уязвим. Второй сервер не был затронут, т.к. openvz ядро для centos6 собрано на основе ванильного 2.6.32, а не ядра RHEL.

На уязвимом сервере стоял последний CentOS. Первым делом проверил, есть ли апдейт для ядра.

# yum check-update

Пусто... блин для RHEL уже есть новое ядро, а centos не чешется его пересобрать. Последнее время мне все меньше нравится centos из-за их тормозов с выпуском релиза, но это отдельная тема.

В advisory у redhat есть описание, как временно закрыть уязвимость через systemtap. Про systemtap я только слышал, что он приблизительный аналог DTrace (OpenSolaris), а последний очень крут (по слухам). Тут нашелся более детальный гайд, как с помощью systemtap решить проблему. Если кратко, то:

# yum update kernel kernel-firmware
# reboot
# yum install gcc yum-utils systemtap kernel-headers kernel-devel
# wget http://debuginfo.centos.org/6/x86_64/kernel-debuginfo-common-x86_64-`uname -r`.rpm
# wget http://debuginfo.centos.org/6/x86_64/kernel-debuginfo-`uname -r`.rpm
# rpm -Uvh kernel-debuginfo-common-x86_64-`uname -r`.rpm kernel-debuginfo-`uname -r`.rpm
# cat > /root/CVE-2011-0056.stp <<EOF
probe kernel.function("mem_write@fs/proc/base.c").call {
$count = 0
}
EOF

Проверяем, включен ли ASLR (должно выдать 2 или 1)

# cat /proc/sys/kernel/randomize_va_space
2

если нет, то добавляем в /etc/sysctl.conf

kernel.randomize_va_space=2

и применяем изменения

sysctl -p 

Теперь можно запускать systemtap

# stap -g /root/CVE-2011-0056.stp

Если ошибок нет, то жмем Ctrl+C и добавляем в /etc/rc.local

/usr/bin/nohup /usr/bin/stap -g /root/CVE-2011-0056.stp &

не забыв запустить stap в фоне. Остается проверить, осталась ли ошибка

# ./cve-2012-0056
not vulnerable