В корректирующих выпусках X.Org Server 1.17.1 (http://lists.x.org/archives/xorg-announce/2015-February/0025...) и 1.16.4 (http://lists.x.org/archives/xorg-announce/2015-February/0025...) устранена уязвимость (http://seclists.org/oss-sec/2015/q1/506) (CVE-2015-0255), которая может привести к утечке содержимого памяти сервера. Клиент, имеющий доступ к X-серверу, отправив специально оформленный запрос XkbSetGeometry, может инициировать утечку данных через буферы XKB. Размер порции данных ограничен 64Кб, но через запрос строк по цепочке можно получить больше информации. Проблема присутствует начиная с выпуска X11R6.1, представленного в марте 1996 года.
Кроме того, уязвимость (https://www.cups.org/str.php?L4551) устранена (http://seclists.org/oss-sec/2015/q1/503) в корректирующем выпуске свободной системы печати CUPS 2.0.2 (https://www.cups.org/). Проблема вызвана переполнением буфера в функции cupsRasterReadPixels и может быть эксплуатирована через отправку на печать сжатых растровых данных, снабжённых специально оформленным заголовком страницы.URL: http://seclists.org/oss-sec/2015/q1/506
Новость: https://www.opennet.ru/opennews/art.shtml?num=41654
> Клиент, имеющий доступ к X-серверу, отправив специально оформленный запрос XkbSetGeometry, может инициировать утечку данных через буферы XKB.Интересно, а кто-нибудь из местной публики использует Xorg для соединений от недоверенных клиентов?
Только для локальной сети.
Запуск скупэ из чрута.
> Запуск скупэ из чрута.В свое время браузер от своего юзера запускал. Извращение еще то.
А как насчёт через dial-up 33.6 kbps по протоколу NX, когда он ещё свободен был, весь рабочий стол кдешный? Не сахар конечно, но работать можно, если сильно нужно. А по локалке 100 Mbps можно и без сжатия комфортно.
> В свое время браузер от своего юзера запускал. Извращение еще то.http://ftp.altlinux.org/pub/people/ldv/hasher/thesis-2005.html -- и проще, и лучше.
Это его в альте предполагается использовать завместо docker? Слудбы в нем можно запускать? Или, если требуется сохранять данные в контейнере, то хашер не подходит?
> Это его в альте предполагается использовать завместо docker?Вообще-то в альте hasher доступен с 2003 года -- а предлагалось использовать для запуска приложений, как видим по дате в ссылке, почти десятилетие тому.
> Службы в нем можно запускать?
Не пробовал, для них обычно оказываются практичней VE.
$ hsh --initroot $TMP/hasher
$ hsh-install $TMP/hasher vixie-cron
$ hsh-run --rooter $TMP/hasher service crond start
Starting crond service: <78>Feb 11 15:56:09 crond[14832]: (CRON) STARTUP (V5.0)
<29>Feb 11 15:56:09 crond: crond startup succeeded
[ DONE ]Здесь фоновый процесс запустился, hsh-run не вернулся; при ^C был прибит и запущенный им crond.
С nginx без укрутки лимитов (или поднятия для hasher-priv) не вышло:
/etc/init.d/nginx: line 24: ulimit: open files: cannot modify limit: Operation not permitted
Вердикт -- при желании приспособить, наверное, можно, но с учётом ровно для того и предназначенных OpenVZ и LXC не видно смысла.
> Или, если требуется сохранять данные в контейнере, то хашер не подходит?
Он работает с чрутами -- на какой ФС разместите, там и будут сохраняться (или не сохраняться).
По сути решаются две задачи -- наполнение чрута (разворачивание приложения с зависимостями) и изоляция выполняемого кода с исключением атак на псевдопользователя, от которого возможно манипулировать "рутовым" содержимым чрута, и на вызывающего пользователя (который hsh-run запускал).
Кстати, слышал про порты hasher на fedora и вроде бы на debian.
> Вердикт -- при желании приспособить, наверное, можно, но с учётом ровно для того и предназначенных OpenVZ и LXC не видно смысла.Да-да, одиночные сервисы в OpenVZ совать.. Ну посуйте - за одно поймете насколько это не весело, и сколько проблем у OpenVZ в этом случае.
hint. один процесс читающий диру и влетевший в какой либо из лимитов (cpu, io) тормозит все остальные операции в этой директории потому как удерживает i_mutex. И это by design. причем пытаются вставлять точки "сна" при вызове journal_start_handle. А так - да, попробуйте - потом расскажете.
> Да-да, одиночные сервисы в OpenVZ совать.. Ну посуйте - за одно поймете
> насколько это не весело, и сколько проблем у OpenVZ в этом случае.Во-первых, малыми группами и применял. Во-вторых, в том же Clustrx был реализован подход вплоть до одиночных сервисов -- правда, на базе LXC.
> hint. один процесс читающий диру и влетевший в какой либо из лимитов
> (cpu, io) тормозит все остальные операции в этой директории потому как
> удерживает i_mutex. И это by design. причем пытаются вставлять точки "сна"
> при вызове journal_start_handle. А так - да, попробуйте - потом расскажете.За хинт спасибо, на крохоборские муки не налетал.
PS: переслал знакомым ovz-шникам, вдруг польза какая получится.
Админы народ ленивый и консервативный, имея сервак и сотню сервисов хорошо работающих, не будут багтрекеры этих продуктов парсить ежедневно. А вот опеннет читают за чаем(новости, новинки, срачи в коментариях), узнают про уязвимости на которые нужно обратить внимание и задумываются об apt-get upgrade.
Но от части да, ваше негодование понятно и от части солидарен с вами.
> утечку данных ... Размер порции данных ограничен 64Кб, но через запрос строк по цепочке можно получить больше информации
> Проблема присутствует начиная с выпуска X11R6.1, представленного в марте 1996 года.Утечка неопределённого количества данных из памяти сервера порциями по 64 КБ... Прообраз Heartbleed?
+ next = wire + XkbPaddedSize(len + 2);
+
+ /* Check we're still within the size of the request */
+ if (client->req_len < bytes_to_int32(next - (char *) client->requestBuffer))
+ return BadValue;
+
+ *str = malloc(len + 1);
+ if (!*str)
+ return BadAlloc;
+
+ memcpy(*str, &wire[2], len);
+ *(*str + len) = '\0';
+ *wire_inout = next;
+ return Success;
}Довольно редкостная функция, им чо жалко calloc() иль malloc+memset сделать?
Так нет, надо выпендриться, посчитать длину и вписать туды нолик *(*str + len) = '\0';
> Проблема присутствует начиная с выпуска X11R6.1, представленного в марте 1996 года.Для того времени это нормальная практика, если бы каждая софтина каждый кусок памяти чистила до и после на тогдашних процах общий уровень производительности был бы на порядок ниже.
установка диапазона памяти в число - одна инструкция процессора уже более 30 лет и не может быть накладной априори :)
А загрузка Линукса - другая.
линукс вроде как кроссплатформенный, так что возникает вопрос какого процессора.Вообще, 20 лет прошло с тех пор, кто знает откуда этот код был скопирован и почему было написано именно так, вполне вероятно, что автор и не помыслял о том, что эта память будет отдана процессу другого юзера, спецификации tcp/ip тоже состоят из "багов" которые можно использовать во зле, но так или иначе это фиксится.
процессор - исполнитель, главное, что написал кодер и как это транслировал компилятор :)
Есть такое выражение - короля делает свита, так и любой код делает контекст в котором он используется,и если изначально программист задумал и написал прогу таким образом, что все данные проходят из вне через проверку, а внутри уже бегают по функциям без проверок, то другой может сделать дописку которая позволяет данным попасть в, или уйти из проги без проверок, ну так программист то первоначальный не виноват, и компилятор не виноват.
> Довольно редкостная функция, им чо жалко calloc() иль malloc+memset сделать?
> Так нет, надо выпендриться, посчитать длину и вписать туды нолик *(*str +
> len) = '\0';да да. Так видимо думали красавцы в ядре - которые постоянно обнуляли по 100 байт при создании иноды.
А в результате memset занимал очень интересный процент при некоторых workload..
X.Org - слишком устаревший, слишком захламлённый и слишком небезопасный.
Пора уже везде заменить это на нормальный современный графический сервер. А лучше на облака.
Да, именно, графические облака.
а лучше сразу на лошадок. графических белогривых лошадок.
> а лучше сразу на лошадок. графических белогривых лошадок.Сферических и в вакууме.
> а лучше сразу на лошадок. графических белогривых лошадок.слишком тяжёлые, лучше пони
>X.Org - слишком устаревший, слишком захламлённый и слишком небезопасный.
>Пора уже везде заменить это на нормальный современный графический сервер. А лучше на облака.
>Да, именно, графические облака.Для таких как ты есть microsoft - потребляй их продукты и услуги. Мне не понятно что ты тут забыл вообще и для чего ты это пишешь. Очевидно же что думающие люди сделают как надо, а не будут слушать бредни всяких горлопанов.
Вместо того, чтобы попытаться понять как это должно выглядеть в реале и как это сделать, вы хаяте и стебётесь. Вполне обычное поведение для приматов.
> X.Org - слишком устаревший, слишком захламлённый и слишком небезопасный.Вы Xorg с какой целью используете? Чем конкретно он вас не устраивает?
> Пора уже везде заменить это на нормальный современный графический сервер. А лучше на облака.
> Да, именно, графические облака.*убрал эмоциональный текст*
Зачем?
P.S.: Если у вас слабенький ноут, и вы хотите задействовать другой компьютер для игрушек (вдруг ностальгия замучала или хотите в 0ad сыграть), то лично в моём случае неплохо подошёл virtualgl. Да-да, именно с применением этого «устаревшего» Xorg.
А в моём подойдут графические облака.
странно - в GLSA тишина