СVE-2024-38063 или RCE в TCP/IP

[sect adept]

Всем привет. Знающие, подскажите как дела обстоят с POC'ом для данной уязвимости. Как я понял, в сети все POC'и производят DoS целевой машины, и нет никакой речи об RCE.
Читал про данную CVE через гугл переводчик, но мало чего понял из-за кривого транслейта. На сколько я понял, ошибка состоит при проверке фрагментации пакетов IPv6, и если отправлять множество пакетов (зафлудить), то есть шанс на выполнение твоего пэйлоада из-за переполнения буфера. Но из-за такого флуда, я понимаю, досится целевая машина, потому что не хватает памяти?

Наткнулся на один POC (тык), откуда возникло несколько вопросов:
1. Строка

second = IPv6(hlim=64+i, dst=ipv6) / IPv6ExtHdrFragment(id=frag_id, m=1, offset=0) / shellcode

Почему именно сюда автор пытается передать shellcode?
2. Зачем автор использует несколько видов флуда: ICMP и SYN?
3. Ну и сообственно главный вопрос:
Как думаете, кто-нибудь юзает приватный эксплойт, который способен произвести RCE на целевой машине? Зачем тогда писать про возможность RCE, если по факту все POC'и только досят целевую машину, и шанс заабузить RCE крайне мал по отношению к DoS.

Если все-таки реально воспроизвести RCE атаку, то какие шаги посоветуете предпринять или лучше не стоит тратить время?

 

[varwar]

Но из-за такого флуда, я понимаю, досится целевая машина, потому что не хватает памяти?

Досится, потому что уязвимость в драйвере и скорее всего там page fault происходит при перезаписи небольшого чанка пула.

Если все-таки реально воспроизвести RCE атаку

Попробуй, только подумай как ты будешь получать Arbitrary Read примитив для эксплуатации, без которого Arbitrary Write получить, вероятно, не получится. Был бы сразу контроль RIP, то это уже другой разговор. Т.е. нужна минимум еще одна уязвимость в цепочке.

только досят целевую машину, и шанс заабузить RCE крайне мал по отношению к DoS.

Поэтому предпочтительнее для RCE уязвимости в юзер компонентах и с контролем RIP, но это бриллиант. Все переполнения в драйверах - это де-факто нестабильный кал.

 

[sect adept]

Досится, потому что уязвимость в драйвере и скорее всего там page fault происходит при перезаписи небольшого чанка пула.


Попробуй, только подумай как ты будешь получать Arbitrary Read примитив для эксплуатации, без которого Arbitrary Write получить, вероятно, не получится. Был бы сразу контроль RIP, то это уже другой разговор. Т.е. нужна минимум еще одна уязвимость в цепочке.


Поэтому предпочтительнее для RCE уязвимости в юзер компонентах и с контролем RIP, но это бриллиант. Все переполнения в драйверах - это де-факто нестабильный кал.

Благодарю за ответ!
P.S. Лайки закончились( а так однозначно + за ответ

 

[melat0nin]

досится целевая машина, потому что не хватает памяти?

Потому что при флуде пакетов со временем происходит обращение к невалидному объекту в памяти => CPU генерит #PF => система валится в багчек. Очевидно, что этот объект из-за KASLR будет каждый раз в разных местах, то же самое будет и с обращениями - они будут абсолютно рандомными. Собсна, для того, чтоб не падать - нужно знать заранее расположение объекта в памяти, а значит, нужно смешно насрать объектами. Тут две проблемы:
1. Надо знать, чем засрать пулы памяти. В слепую срать объектами конкретно в этой баге - сомнительная затея и вряд ли рабочая.
2. Надо каким-то образом ликнуть объекты, чтоб понять, чем засирать пулы.
Из второго пункта идёт ещё одна проблема: без понятия как получить эти гипотетические объекты из драйевра, затык уже будет даже в "локальном" получении адресов, не говоря уж о удалённом.

Многоуважаемый varwar прав: эта бага не может существовать как какой-то единый сплоент, собсна она и не может существовать как истинный Zero Click. Эта бага должна чейнится как минимимум с Information Disclosure багой в этом же tcpip драйвере. Вот тебе и подсказка, куда рулить далее.

 

[V3ct0r]

Я тоже присматриваюсь к этой уязвимости. Свежая Information Disclosure есть для TCP/IP: CVE-2024-38064

 

[varwar]

Я тоже присматриваюсь к этой уязвимости. Свежая Information Disclosure есть для TCP/IP: CVE-2024-38064

Дерзайте. Последняя новость говорит, что даже спустя почти 5 месяцев после патча можно петушить пабликом. Что в общем-то не противоречит данным Mandiant.
Хотя я это связываю больше с тем, что модуль 6 декабря добавили в Metasploit ну и понеслось.

CVE-2024-38064

Use of Uninitialized Resource

Не факт, что утечку этих неинициализированных данных можно докрутить до обхода KASLR. Но нужно смотреть, конечно.

 

[SlEpOy_SnIpEr]

модуль 6 декабря добавили в Metasploit

RCE или LPE?

 

[varwar]

RCE или LPE?

LPE. Это я так, отвлекся от темы.