татко Крокодил

И малко технически неща.

Вчера подкарахме ipv6 в initlab с тунел през Hurricane electric. Имат приятна функционалност, например делегиране на reverse DNS за адресите. Вече може да се стига до cassie по v6, има AAAA запис.
Целта на упражнението беше в общи линии да се пробва как работи. Следва да се види колко security и други проблема ще бъдат открити. Доколкото разбрах, преди е имало такова нещо, но след като са сменили малко хардуер, не е било пуснато пак. На нас ни се наложи за малко да ритнем router-а там (един неприятен airport extreme), защото никой не му помнеше паролата, но иначе подкарването се оказа сравнително лесно. Един ден ще го сменим…
(reverse DNS зоните на v6 са творение на сатаната – 8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.a.c.1.5.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa. )

Вкарах и втората си машина в pool.ntp.org и пуснах малко статистика за ползването им (marla и tyler). Гледам, че evolink announce-ват някакви v6 адреси, може да добавя marla с такъв адрес в pool-а по някое време (предпочитам да не го правя с тунел, ntp-то е доста чувствително към латентност).

Един приятел днес ми прати следния линк с DoS в apache2 – накратко, ако се направи един request към вас с range request, който да е достатъчно голям (в случая – списък от парчета 5-9,5-13,5-17 и т.н.) и имате mod_deflate, то apache ще се опита да го сглоби и компресира, съответно ще изяде невероятно количество памет и може да срине машината. Оказа се, че на 64bit-ов debian дори махането на модула не помогна особено и в момента ползвам един крив workaround, LimitRequestFieldSize с ниска стойност, за да не могат да минават подобни заявки. При другите две неща, при които тествах (32bit debian и 64bit gentoo) проблемът си заминава с махването на модула.
(понякога се налага да се пипне заявката в примерния exploit да сочи към статичен файл, с динамични не става)
Писах на разни хора, които би трябвало да имат интерес от тия проблеми, те би трябвало да открият аз какво съм пропуснал и защо точно тоя debian-ски apache2 продължава да се чупи.
Update: Получих следното като друго временно решение (което основно бори конкретния PoC exploit, не решава генерално проблема. Може обаче па да се ban-нат генерално range request-ите…):

iptables -N KILLAPACHE
iptables -F KILLAPACHE
iptables -A KILLAPACHE -m limit --limit 1/min -j LOG --log-prefix "killapache: " --log-level 7
iptables -A KILLAPACHE -j DROP
iptables -I INPUT -p tcp --dport 80 -m string --algo kmp --from 58 --string "Range:bytes=0-" -j KILLAPACHE


Update:Официална информация по въпроса.

(и за тези, на които гадостите от по-горе не стигат – 20110819, 20110820 и 20110821)

Tags: initLab, проблеми

This entry was posted on Sunday, August 21st, 2011 at 21:46 and is filed under General. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.