Уязвимостта BIND позволява на всеки сървър да се срива как и защо работи
Замислихме се да създадем правила (NAD) за откриване на експлоатация на тези уязвимости по мрежата - за да направим това, трябваше да се задълбочим в BIND кода и да напишем собствените си експлойти. Нашият анализ ще ви помогне да разберете как работи всичко в такъв популярен DNS сървър, както и да разберете за грешките, направени от разработчиците на проекта, и възможните решения на тези проблеми.
Какъв е проблемът
Рекурсивните сървъри с поддръжка на DNSSEC са изложени на най-голям риск, така че по-нататък ще се съсредоточим върху случая на рекурсивна заявка.
Описанието на кръпката гласи, че определена комбинация от DNSSEC записи в отговор на рекурсивна заявка може да доведе до отказ на услуга от сървъра или по-прост начин до срив. Освен това разработчиците добавят, че такава комбинация от полета не се среща при нормален DNS трафик.
За по-нататъшно разбиране на проблема е необходимо да се проучи публично достъпната корекция за тази CVE. Пачът поправя само няколко реда код в един от модулите, отговорни за обработката на DNS отговорите.
Както виждаме, пластирът поправя логическа грешка в състоянието
Изпълнението и на трите израза стана задължително за промяна на променливата have_answer на true. Това е необходимо, за да се определи дали пакетът съдържа отговор на нашето искане:
По този начин става очевидно, че експлоатацията на уязвимостта става чрез непълно изпълнение на условието от кръпката. Нека се опитаме да разберем каква комбинация от записи в пакета е необходима за работа.
Писане на подвизи
Можете да стигнете до клона с уязвимия код чрез следното кратко състояние
Намерената променлива е зададена в пет блока код от една и съща функция, които обработват различни варианти на отговори, като пренасочване на имена със записи CNAME или DNAME, отговор на ВСЯКА заявка и т.н.: