В Xorg обнаружена пачка уязвимостей возрастом от 25 до 35 лет

Ничего, совет директоров быстро поправит :)

Часто говорят, что вейландом занимаются те же люди, что занимаются иксами. Стоит ли ждать через 15-25 лет обнародования пачки уязвимостей в Wayland? Его уже делают лет десять, как раз в сумме 25-35 получается.

Неуловимый Джо?

Это конечно удачный повод в очередной раз нагнать на вайланд, но на самом деле тут немного другое.

Уязвимости из 80-х годов это всё-таки ещё авторства настоящих его разработчиков. Ну, в те времена к безопасности вообще относились наплевательски, так что можно понять, хотя это и печально. Впрочем, см. мой коммент ниже - всё не так страшно как жёлтая пресса раздула.

Текущие же его мейнтейнеры тут не особо причём, ну кроме того факта что они забили на иксы и продвигают дурацкий вайланд.

Похоже, похороникс в терминах запутался — как в X.org может быть уязвимость от 1988 года, когда он сам появился в середине 2000х? Если ошибка в libX11, стало быть, не только Xorg подвержен, но и все X-серверы, этот libX11 используется.

все X-серверы

Все один штук

Это конечно плохо, но заголовок (и на форониксе тоже) жёлтый и вводящий в заблуждение. Уязвимости найдены не в Xorg а в клиентских библиотеках, причём: одна из них может случиться если уязвимая прога подключится к злонамеренному X-серверу (по-моему, единственный сценарий где это можно проэксплутировать - это для взлома suid-root гуи проги, а такие проги по-моему сами по себе большая дыра). Остальные - при открывании прогой злонамеренных картинок в формате xpm, а учитывая что в xpm сейчас хранят разве что встроенные ресурсы софта, то эти картинки в подавляющем большинстве случаев доверенные и источниками атак стать не могут. В любом случае, пострадает только запустивший прогу (и подсунувший ей плохую картинку) юзер, а не вся система.

Во-вторых, из текста не до конца понятно, что собственно произойдёт при эксплуатации. Часть из ошибок приведут просто к крашу, часть - к обработке не тех данных что надо и потенциально показу всё тому же юзеру какой-то своей внутренней информации. Может ли там быть RCE - кажется что нет, хотя я внимательно не смотрел.

Вот правильный источник: https://lists.x.org/archives/xorg/2023-October/061506.html

но и все X-серверы, этот libX11 используется.

То есть ни одного. libX11 используется только клиентами, как и libXpm.

А фороникс действительно запутался, см. мой коммент выше.

Все один штук

Из самых популярных, что не X.org, — Xvnc, который вместо экрана рисует окошки по сети. Не говоря уже о том, что с 1988 года еще есть куча устаревших, типа XFree86. Так что не один, далеко не один.

Так в Xorg или в libX11? То, что в libX11 говнокод - не новость

Точно. Спасибо. Меня год смутил, а о том, что это клиентская часть, забыл. Тем не менее, технически все равно получается, что от сервера не зависит.

И это наглядно показывает нам, что всеобщая истерия по поводу уязвляющих уязвимостей - полнейшая надувная херня. Дохрениллионы людей десятилениями используют уязвимую софтину, и хоть бы хрен.

1998 год — это код ещё XFree86 версии 3.3.3, может даже 3.3.2.

И да, и нет. Таки тулзы (ASAN, UBSAn, TSAN, Coverity, пивас, scan-build и прочее) сейчас сильно сильнее чем раньше. Человеческий фактор тот же, тулинг лучше.

Xorg же не с нуля написан, это форк XFree и сразу появился версии 6.7 емнип. В XFree всё лежало кучкой. В Xorg же как раз первым делом всё подробили на сервер, библиотеки и инструментарий в разные пакеты.

Нет, человеческий фактор другой. В 80-е про безопасность вообще мало думали и, возможно, даже не посчитали бы всё перечисленное проблемой - так, мелкий баг с крашем который никогда не случится.

Ну да, а сейчас в опенсорсе (да и в проприетарщине) сплошные безопастники код пишут, всё верно.

Нет. Хуже того, сейчас намного больше просто некомпетентных людей пишут код. Скажем так - тогда они хорошо умели реализовывать задуманную цель, но не знали, что надо следить за безопасностью. Сейчас про безопасность все знают, но делать её большинство не умеют по причине профнепригодности. Так что разница определённо есть, но неизвестно в какую сторону. Возможно, не стоит всё на одну линию с больше-меньше проецировать.

Прям можно делать опрос, кто моложе - пользователь Лора или баг в Xorg.

Все один штук

Xenocara, Reflection X, XFree86, MKS X и другие. В любом случае уязвимость не в X11 (иксы — просто протокол), а в тулките libX11.

Что то слишком много стали новых уязвимостей находить. Такое ощущение, что они чатгпт к этому прикрутили.

Xenocara, Reflection X, XFree86, MKS X и другие

И другие дохлые ты забыл дописать.

В живых сейчас по сути лишь три X11 сервера:

• XWayland
• X.Org
• XQuartz

Все они используют кодовую базу X.Org и все сегодня обозначены как deprecated и legacy.

Сейчас про безопасность все знают, но делать её большинство не умеют по причине профнепригодности.

Ну, а что хотите? Многие говнокодеры приходят после онлайн-курсов «войди в айти за 6 месяцев и зарабатывай 1000000000000000000000$ в секунду».

Xenocara поправит?

XFree86 тоже брал кучу из X11R5/X11R6.

В 80-е про безопасность вообще мало думали

Именно. Потому что систем было меньше, и гораздо меньше народа их использовало. Очень многие предположения о сценарии использования и добропорядочности пользователей принимались как должное, что сейчас считается ошибкой с т.з. кибербезопасности. И поэтому куча не только всевозможных переполнений буферов, но и command Injection, атаки на базовые сетевые протоколы. Всё это залатали со временем, во всяком случае, наиболее явные уязвимости, которые проще всего было эксплуатировать, закрыли.

И это наглядно показывает нам, что всеобщая истерия по поводу уязвляющих уязвимостей - полнейшая надувная херня.

Музыка? Да говно это, вся музыка! Я же слышал «Сектор Газа». Всё говно.

исчерпание стека в коде функции PutSubImage() от февраля 1988 года

Небось закладка осталась ещё от хакеров-коммунистов, чтобы следить за проклятыми буржуями.

Ну, в те времена к безопасности вообще относились наплевательски

Где там наплевательское отношение к безопасности? Выход за границы, исчерпание стека, целочисленное переполнение — это типичный букет ошибок сишников. Именно ошибок, совершаемых программистами из-за бедных возможностей языка, который всё сваливает на человека.

Тридцать лет прошло, а ничего не изменилось. Если я усну и проснусь через сто лет и меня спросят на чём сейчас горят сишники, я отвечу: выход за границы массивов, использование памяти после освобождения, целочисленное переполнение.

Там всё это происходит не само по себе, а при некорректном вводе или злонамеренном сервере который шлёт битые пакеты. В те времена считалось, что раз юзер дал программе файл, но юзер сам и отвечает за его содержание, подсунул мусор - получил мусор (краш итд) на выходе. Понимание, что подсунуть может не сам юзер, а какой-то третий человек, обманувший юзера, и что эту ситуацию надо решать на уровне софта, пришло позже.

языка, который всё сваливает на человека

Не «сваливает на человека» а «не устраивает самодеятельность». Что программист закодил - то и будет, ни меньше, ни больше. Лишние непрошенные проверки, тратящие такты процессора, для языков 60-х были бы однозначно минусом. В 80-х это стало чуть менее актуально, но, с одной стороны, память о 60-х в головах в т.ч. компиляторописателей ещё была яркой, а с другой - непрошенные проверки до сих пор (т.е. в 2023) в некоторых местах нежелательны.

Тут уже пробегал firkax, который утверждал, что нынешние разработчики xorg – паразиты, а изначально написали XFree86 великие ДИДЫ?

Часто говорят, что вейландом занимаются те же люди, что занимаются иксами. Стоит ли ждать через 15-25 лет обнародования пачки уязвимостей в Wayland?

Ну, в реализации списков из sway отсутствует проверка результата realloc(), например. Другое дело, что вайланд живой, в отличии от. И подобные вещи в вяленом будут исправлять активней

Все сколь-нибудь серьёзные реализации X сервера основаны на одной и той же кодовой базе. Так что уместно говорить что реализация по сути одна с несколькими форками без принципиальных изменений.

«не устраивает самодеятельность»

Так про любой язык сказать можно.

Он не просто брал, он форк X11R5/X11R6.

почему это https://www.opennet.ru/opennews/art.shtml?num=59867 ещё не обсуждали? дыра в glibc.

Ну и чего теперь, на Ржавом переписать?

Толи дело фанаты нескучных язычков, пришёл на работу и за неделю готов идеальный код по любой задаче. :) Как-то так получается в реальности, что весь мирный продакшен пишется либо вот так, либо никак.

Всë перечисленное легко отлавливается статическими анализаторами. Вопрос скорее почему этими анализаторами не пользуются.

Ничего из этого не отлавливается статическими анализаторами, потому что зависит от данных в рантайме.

Какими именно анализаторами вы пользовались и что из этого: «выход за границы, исчерпание стека, целочисленное переполнение» у вас и в каком анализаторе не выскочило хотя бы как предупреждение?

выход за границы

Индекс, по которому выполняется доступ в массив, вычисляется в рантайме.

исчерпание стека

Рекурсия.

целочисленное переполнение

Целочисленное переполнение возникает когда результат операции превышает максимальное значение типа. Как ты это проверишь анализатором, если значения приходят во время исполнения, а не константы?

Вы решили поиграть в капитана? Или нагуглили и себе для памяти написали?
Что вы писали на си и какими статическими анализаторами пользовались? Это очень простые вопросы подразумевающие очень простые ответы.

Ты не маневрируй кормой. Сам влез со статическим анализом для переполнения, а теперь что-то требуешь от меня. Рассказывай как ты будешь без libastral детектить эти ошибки или сливайся.

Врёти, в сишном коде уязвимостей не бывает.

Сейчас про безопасность все знают, но делать её большинство не умеют по причине профнепригодности.

Хах, в амазоне не умеют разрабатывать распределенные системы, а ты нам рассказываешь, что обвиняешь какое-то там «большинство» в какой-то «профнепригодности». Бизнесу не нужна ни безопасность, ни надежность, ни распределенность — ему нужны деньги, желательно больше, желательно еще больше денег, а те люди, которые думают про «деньги-деньги-деньги», подозрительно часто не умеют ничего другого. Люди не сильно отличалась «тогда» и «сейчас», просто декорации поменялись.

Очень многие предположения о сценарии использования и добропорядочности пользователей принимались как должное, что сейчас считается ошибкой с т.з. кибербезопасности. И поэтому куча не только всевозможных переполнений буферов, но и command Injection, атаки на базовые сетевые протоколы.

Ты не прав, потому что случайное повреждение данных в БД к безопасности не относится, но последствия может иметь катастрофические, учитывая плохую устойчивость старого софта к отказам. Но, да, если раньше можно было делать вид, что «да это в операционной системе проблема, просто восстановим БД», то нынче вся БД утекает к хакерам и отвертеться не получается. Хотя, многим пофигу и утечки БД, у меня вот акк ВК «ушел в зрительный» зал при утечке оттуда базы пользователей с паролями в plain text — вот тебе и «безопасность».

Бизнесу не нужна ни безопасность, ни надежность, ни распределенность

Верно, но иксы всё-таки не бизнесмены лично писали, а программисты (хоть, возможно, и нанятые бизнесменами). В те времена сложнее было нанять «абы кого лишь бы подешевле».

Напомню, что VK писали на PHP.

А вокруг этого недоязычка сложилось коммьюнити низкоквалифицированных программистов, которые хранят пароли в Plain Text или не солят хеши.

Так что чего удивительного в этом?

У меня как-то странно иногда (1-2 раза в месяц, на Trinity DE, что вероятно не суть проблемы) вырубает клаву в Xorg tty7. Впечатление, что не самопроизвольно, а под внешним воздействием. Возможно Xorg так реагирует на какую-то комбинацию нажатий клавиш, вбрасываемую таргетированными радиопомехами. Возможно что-то похожее на SysRq ?

Причем индикатор активности клавы (widget KDE) все же видит нажатия и даже может переключать мышкой состояние capslock (это видно по реакции соответствующего caps локу светодиоду на клаве) при нажатии на соответствующий индикатор, но при этом ни одна графическая программа не реагирует на нажатия клавиш, даже capslock НЕ переключается с клавы, а только кликом мышки по индикатору на панели KDE.

Сделал на десктопе запускалку переключалки в chvt 1, и вот только что при очередном таком отключении убедился, что в ядерной консоли клава по-прежнему прекрасно работает.

kbd_mode -C /dev/tty7
The keyboard is in some unknown mode

Попытка переключить ее в режим scancode не помогает, наверно и не должен помочь?

Как выяснилось и при нормальной работе Trinity (после перезапуска Xorg), по-прежнему «The keyboard is in some unknown mode», но при этом нормально набирается текст (вот как раз это сообщение).

Пожалуйста, подкиньте какие-нибудь идеи, как можно выводить клаву tty7 (в Xorg) из ступора после переключения в работающий tty1. Хотя бы способы диагностики и обнаружения причин этой неведомой хрени.