Остальные три уязвимости могут привести к утечке содержимого памяти сервера или к аварийному завершению работы. Данные три уязвимости эксплуатируются через использование на стороне клиента иного порядка следования байтов, чем на сервере. В связи с этим в новом выпуске предложена возможность для блокировки подключения клиентов с систем, имеющих иной порядок байтов. Для отключения можно использовать параметр конфигурации «AllowByteSwappedClients» или опцию командной строки «+byteswappedclients».
Изменение значения по умолчанию позволяет защититься от возможно ещё не выявленных уязвимостей, манипулирующих порядком следования байтов. Суть таких уязвимостей в том, что изменение порядка следования байтов для значений с размером приводит к их неверной интерпретации и чтению или записи в память заведомо большего размера, чем вмещает в себя выделенный буфер.
По умолчанию пока сохраняется поддержка клиентов с другим порядком следования байт, несмотря на то, что на практике преобразование порядка байтов последнее время используется крайне редко, так как рабочие станции на которых запускается X-сервер, как правило, оснащены процессорами с порядком байтов little-endian (от младшего к старшему байту) и подключение к ним X-клиентов с порядком big-endian, таких как платформа s390x (IBM zSystems), является большой редкостью.
Выявленные проблемы:
- CVE-2024-31080, CVE-2024-31081, CVE-2024-31082 — чтение данных из области вне буфера через манипуляции с функциями ProcXIGetSelectedEvents, ProcXIPassiveGrabDevice и ProcAppleDRICreatePixmap, которые используют поле с размером без учёта порядка байтов в значении, переданном клиентом. Соответственно, при различиях в порядке следования байтов у клиента и сервера, функции возвращают клиенту больше данных. Первые две проблемы проявляются начиная с выпуска xorg-server-1.7.0 (2009 год), а третья — с xorg-server-1.15.0 (2012 год).
- CVE-2024-31083 — обращение к уже освобождённой памяти (User-after-free) в функции ProcRenderAddGlyphs, которая вызывает функцию AllocateGlyph() для сохранения новых глифов, переданных клиентом.
Функция AllocateGlyph() возвращает новый глиф с нулевым счётчиком ссылок (refcount=0), а повторное указание глифа не приводит к увеличению счётчика ссылок, из-за чего массив glyph_new может включать несколько записей, указывающий на один глиф без счётчика ссылок. При освобождении функцией ProcRenderAddGlyphs() памяти, выделенной для глифа, в массиве остаётся и может быть использован лишний экземпляр указателя на глиф, память для которого уже освобождена. Проблема проявляется в X.Org Server и не затрагивает xwayland.
Источник: http://www.opennet.ru/opennews/art.shtml?num=60927