Комментарии 5
И, само собой вспоминается анекдот —
Мужик ждёт в роддоме, пока жена рожает. Выходит акушерка:
— Поздравляю, у вас мальчик!
Через минуту возвращается:
— У вас второй мальчик!
Потом третий, четвёртый, пятый, шестой, седьмой…
Обалдевший отец не выдерживает и заглядывает в операционную. Там совершенно измученный врач мечется по комнате и отчаянно орёт:
— СВЕТ! ГАСИТЕ СВЕТ! ОНИ ПОЛЗУТ НА СВЕТ!!!
В каком-то maillist’е увидел упоминание ядерного ключа init_on_free=1 в качестве механизма прижатия утечек через освобождаемую память. У вас это установлено или реализовано?
да, у меня часто включён почти полный набор рантайм-hardening механизмов памяти, рекомендуемых Linux Kernel Self-Protection Project (KSPP). Но когда я попросил ChatGPT проанализировать эффекты от них применительно именно к этой CVE и exploit'у, то он сообщил, помимо прочего, что…
Самый интересный случай — init_on_free:
31 октября на oss-security предложили init_on_free=1 как дополнительную mitigation этой CVE. Но 2 ноября инженер CIQ Sultan Alsawaf разобрал предложение и возразил:
(отдельная хохма, что это тоже не его анализ, как таковой — "… I had Claude Mythos analyze the code and Anthropic's exploit description [1], and this is what it found: …")
по-моему он кстати неправ. Разговор о том, что память выделяется где-то в одном месте, указатель дается во владение двум потокам, один из них вызывает kfree() а второй имеет окно чтобы потом оттуда что-то читать. Вот при init_on_free=1 этот самый kfree() должен отрабатывать как freeAndNil() (т.е. занулять синхронно память заранее известной длины), в этом случае память таки становится freed несмотря на “потерянный” живой указатель на неё. Откуда там взялось, что в это место падает дополнительный allocation, который внезапно пытается быть out-of-bounds read? Тогда бы ошибка в коде была именно OOB read вместо UAF.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пока-пока, mitigations=off Давно работаю с Linux, но почти в то же время познакомился и с FreeBSD, где make buildworld...