Сразу 28 дыр найдено в X.org

Специалист по безопасности Илья ван Спрундел (Ilja van Sprundel) из компании IOActive обнаружил большое количество проблем в том, как различные клиентские библиотеки X Window System обрабатывают ответ с сервера. Последние несколько недель Илья совместно со специалистами X.Org анализировал выявленные баги и помогал исправить их.

Большинство уязвимостей связано с тем, что клиентские библиотеки слепо доверяют корректности данных с сервера, не проверяя их на ошибки и потенциальную вредоносность. В большинстве случаев и клиент, и сервер принадлежат одному и тому же пользователю, так что здесь проблем не возникает. Но бывают ситуации, в которых привилегированный клиент подключается к непривилегированному серверу. Например, X-клиент setuid подключается к X-серверу Xvfb или Xephyr, который модифицирован злоумышленником так, что возвращает некорректные данные для эскалации привилегий.

Список уязвимых библиотек.

CVE-2013-1981: libX11 1.5.99.901 (1.6 RC1) и более ранние
Пораженная функция: XQueryFont(), _XF86BigfontQueryFont(), XListFontsWithInfo(), XGetMotionEvents(), XListHosts(),XGetModifierMapping(), XGetPointerMapping(), XGetKeyboardMapping(), XGetWindowProperty(), XGetImage()

* CVE-2013-1982: libXext 1.3.1 и более ранние
Пораженная функция: XcupGetReservedColormapEntries(), XcupStoreColors(), XdbeGetVisualInfo(), XeviGetVisualInfo(), XShapeGetRectangles(), XSyncListSystemCounters()

* CVE-2013-1983: libXfixes 5.0 и более ранние
Пораженная функция: XFixesGetCursorImage()

* CVE-2013-1984: libXi 1.7.1 и более ранние
Пораженная функция: XGetDeviceControl(), XGetFeedbackControl(), XGetDeviceDontPropagateList(), XGetDeviceMotionEvents(), XIGetProperty(), XIGetSelectedEvents(), XGetDeviceProperties(), XListInputDevices()

* CVE-2013-1985: libXinerama 1.1.2 и более ранние
Пораженная функция: XineramaQueryScreens()

* CVE-2013-2062: libXp 1.0.1 и более ранниеПораженная функция: XpGetAttributes(), XpGetOneAttribute(), XpGetPrinterList(), XpQueryScreens()

* CVE-2013-1986: libXrandr 1.4.0 и более ранние
Пораженная функция: XRRQueryOutputProperty(), XRRQueryProviderProperty()

* CVE-2013-1987: libXrender 0.9.7 и более ранние
Пораженная функция: XRenderQueryFilters(), XRenderQueryFormats(), XRenderQueryPictIndexValues()

* CVE-2013-1988: libXRes 1.0.6 и более ранние
Пораженная функция: XResQueryClients(), XResQueryClientResources()

* CVE-2013-2063: libXtst 1.2.1 и более ранние
Пораженная функция: XRecordGetContext()

* CVE-2013-1989: libXv 1.0.7 и более ранние
Пораженная функция: XvQueryPortAttributes(), XvListImageFormats(), XvCreateImage()

* CVE-2013-1990: libXvMC 1.0.7 и более ранние
Пораженная функция: XvMCListSurfaceTypes(), XvMCListSubpictureTypes()

* CVE-2013-1991: libXxf86dga 1.1.3 и более ранние
Пораженная функция: XDGAQueryModes(), XDGASetMode()

* CVE-2013-1992: libdmx 1.1.2 и более ранние
Пораженная функция: DMXGetScreenAttributes(), DMXGetWindowAttributes(), DMXGetInputAttributes()

* CVE-2013-2064: libxcb 1.9 и более ранние
Пораженная функция: read_packet()

* CVE-2013-1993: libGLX in Mesa 9.1.1 и более ранние
Пораженная функция: XF86DRIOpenConnection(), XF86DRIGetClientDriverName()

* CVE-2013-1994: libchromeXvMC & libchromeXvMCPro in openChrome 0.3.2 и более ранние
Пораженная функция: uniDRIOpenConnection(), uniDRIGetClientDriverName()

* CVE-2013-1995: libXi 1.7.1 и более ранние
Пораженная функция: XListInputDevices()

* CVE-2013-1996: libFS 1.0.4 и более ранние
Пораженная функция: FSOpenServer()

* CVE-2013-1997: libX11 1.5.99.901 (1.6 RC1) и более ранние
Пораженная функция: XAllocColorCells(), XkbReadGetDeviceInfoReply(), _XkbReadGeomShapes(), _XkbReadGetGeometryReply(), _XkbReadKeySyms(), _XkbReadKeyActions(), _XkbReadKeyBehaviors(), _XkbReadModifierMap(), _XkbReadExplicitComponents(), _XkbReadVirtualModMap(), _XkbReadGetNamesReply(), _XkbReadGetMapReply(), _XimXGetReadData(), XListFonts(), XListExtensions(), XGetFontPath()

* CVE-2013-1998: libXi 1.7.1 и более ранние
Пораженная функция: XGetDeviceButtonMapping(), _XIPassiveGrabDevice(), XQueryDeviceState()

* CVE-2013-2066: libXv 1.0.7 и более ранние
Пораженная функция: XvQueryPortAttributes()

* CVE-2013-1999: libXvMC 1.0.7 и более ранние
Пораженная функция: XvMCGetDRInfo()

* CVE-2013-2000: libXxf86dga 1.1.3 и более ранние
Пораженная функция: XDGAQueryModes(), XDGASetMode()

* CVE-2013-2001: libXxf86vm 1.1.2 и более ранние
Пораженная функция: XF86VidModeGetGammaRamp()

* CVE-2013-2002: libXt 1.1.3 и более ранние
Пораженная функция: _XtResourceConfigurationEH()

* CVE-2013-1981: libX11 1.5.99.901 (1.6 RC1) и более ранние
Пораженная функция: LoadColornameDB(), XrmGetFileDatabase(), _XimParseStringFile(), TransFileName()

* CVE-2013-2003: libXcursor 1.1.13 и более ранние
Пораженная функция: _XcursorFileHeaderCreate()

Патчи и исправленные версии публикуются здесь.

field_vote: 
Ваша оценка: Нет Средняя: 4 (2 оценки)

Комментарии

На первый взгляд, кажется, что новость огорчающая. На самом деле, новость классная! Ведь спецы стали заранее, до массовых эпидемий, находить потенциально опасные места и их устранять.

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

Да, это действительно довольно хорошая новость для пользователей иксов. А ваш комментарий поднимает довольно интересный вопрос: как именно измерять уязвимость ОС?

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

Критерий "по количеству эксплоитов" же слишком сильно зависит от популярности и выгодности взлома конкретной ОС.

Измерять уязвимость ОС по времени на исправление ошибок? К сожалению, во многих случаях и этот метод недействителен, т.к. отчёты об уязвимостях в некоторых случаях выходят уже после их исправления.

>> Вот какова вероятность, что злоумышленники смогут модифицировать ПО, к которому юзер вдруг захочет подключиться, да еще и под рутом?

Злоумышленник поднимает собственный X-сервер с модифицированным ПО на своей машине. Юзер к этому серверу подключается, и злоумышленник получает права рута. Так что уязвимость опаснее, чем вы думаете (хотя сам сценарий пользователя, использующего иксы по сети, невероятно редок).

Измерять уязвимость ОС по времени на исправление ошибок? К сожалению, во многих случаях и этот метод недействителен, т.к. отчёты об уязвимостях в некоторых случаях выходят уже после их исправления.

Ну, это проблема сбора данных, а не самого метода. Сам-то метод "--- единственно верный. А со сбором данных нам поможет наука.

ваш комментарий поднимает довольно интересный вопрос: как именно измерять уязвимость ОС?

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

Но можно ввести интегральную оценку, которая будет рассчитываться на основе ряда показателей. Например:
1) количество случившихся инцидентов с ПО (тут уже можно делать замеры в штуках);
2) уровень опасности инцидента (например, высокий, средний, низкий);
3) время реакции разработчиков (тоже количественная мера);
4) экспертная оценка качества исходников (высокое, среднее, низкое, индусыписали).
5) экспертная оценка архитектуры ПО (насколько само строение программы помогает или препятствует злоумышленнику производить что-то нехорошее). Тут, наверное, следует пояснить. Например, архитектура микрософтовской технологии Component Object Model является изначально опаснейшим говном, ибо «инфраструктура remoting (удаленного вызова методов) использует бинарный формат запросов и ответов, являясь расширением DCE RPC. Это приводит к возникновению огромной "поверхности уязвимости" с точки зрения безопасности, и не раз приводило к крупным эпидемиям вредоносного ПО (MSBlaster)».
6) и т.д.

Собственно, большинство контор свои исследования дырявости программ так и готовит.

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

Изучите, пожалуйста, понятие отказа.

Но можно ввести интегральную оценку, которая будет рассчитываться на основе ряда показателей.

А можно посчитать интенсивности отказа и восстановления на основании данных эксплуатации. По ним же можно рассчитать риск.

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

Теперь понятно чего Debian захотел обновить иксы...

Комментировать

Filtered HTML

  • Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.
  • Доступны HTML теги: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <strike> <code> <h2> <h3> <h4> <h5> <del> <img>
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и параграфы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и параграфы переносятся автоматически.