Несколько недавно обнаруженных уязвимостей:
- В новых версиях мультимедиа пакета FFmpeg 0.7.7 и 0.8.6 (http://ffmpeg.org/#pr7dot8and8dot7) устранено несколько уязвимостей (http://secunia.com/advisories/46888/), которые могут привести к выполнению кода злоумышленника из-за переполнения буфера в функциях обработки форматов QDM2, VP3, VP5, VP6 и AV. Напомним, что в октябре в FFmpeg были выявлены 32 уязвимости (https://www.opennet.ru/opennews/art.shtml?num=31951), а в ноябре - 37 (https://www.opennet.ru/opennews/art.shtml?num=32282).
- В http-сервере nginx 1.0.10 (http://www.nginx.org) устранена уязвимость (http://www.openwall.com/lists/oss-security/2011/11/17/8), вызванная возможностью выхода за границы буфера в функции "ngx_resolver_copy()" в процессе обработки ответов от DNS-сервера. Уязвимость проявляется только при активации в настройках директивы resolver (http://nginx.org/ru/docs/http/ngx_http_core_module.html#reso...), которая не используется по умолчанию. Атака на nginx, кот...URL:
Новость: https://www.opennet.ru/opennews/art.shtml?num=32386
Чего-то дырок в FFmpeg много за последнее время обнаружилось. Не подскажет ли аудитория, как mplayer линковать динамически к ffmpeg?
Для MPlayer FFmpeg не нужен.
> Для MPlayer FFmpeg не нужeн.Только вот без ffmpeg'а он не будет играть почти ничего. И станет не нужeн уже сам mplayer. А зачем нужен плеер который ничего проигрывать не может?
>> Для MPlayer FFmpeg не нужeн.
> Только вот без ffmpeg'а он не будет играть почти ничего.У меня Mplayer собран без FFmpeg и играет практически все форматы.
% pkg_info -r mplayer-1.0.r20110329_3
Information for mplayer-1.0.r20110329_3:Depends on:
Dependency: xineramaproto-1.2.1
Dependency: xf86vidmodeproto-2.3.1
Dependency: xf86dgaproto-2.1
Dependency: xextproto-7.2.0
Dependency: videoproto-2.3.1
Dependency: renderproto-0.11.1
Dependency: randrproto-1.3.2
Dependency: kbproto-1.0.5
Dependency: inputproto-2.0.2
Dependency: fixesproto-5.0
Dependency: dri2proto-2.3
Dependency: damageproto-1.2.1
Dependency: compositeproto-0.4.2
Dependency: font-util-1.2.0
Dependency: encodings-1.0.4,1
Dependency: expat-2.0.1_2
Dependency: cups-client-1.5.0
Dependency: libvpx-0.9.7
Dependency: hicolor-icon-theme-0.12
Dependency: python27-2.7.2_3
Dependency: perl-5.12.4_3
Dependency: png-1.4.8
Dependency: jpeg-8_3
Dependency: jbigkit-1.6
Dependency: tiff-4.0.0_2
Dependency: openjpeg-1.3_2
Dependency: pkg-config-0.25_1
Dependency: xproto-7.0.22
Dependency: rtmpdump-2.3_1
Dependency: pixman-0.22.2
Dependency: libfontenc-1.1.0
Dependency: libXdmcp-1.1.0
Dependency: libXau-1.0.6
Dependency: libICE-1.0.7,1
Dependency: libSM-1.2.0,1
Dependency: freetype2-2.4.7
Dependency: mkfontscale-1.0.9
Dependency: mkfontdir-1.0.6
Dependency: fontconfig-2.8.0_1,1
Dependency: font-misc-meltho-1.0.3
Dependency: font-misc-ethiopic-1.0.3
Dependency: font-bh-ttf-1.0.3
Dependency: bitstream-vera-1.10_5
Dependency: xorg-fonts-truetype-7.5.1
Dependency: pcre-8.20
Dependency: orc-0.4.14_1
Dependency: schroedinger-1.0.10
Dependency: libpthread-stubs-0.3_3
Dependency: libxcb-1.7
Dependency: xcb-util-0.3.6_1
Dependency: libdrm-2.4.17_1
Dependency: libX11-1.4.4,1
Dependency: libungif-4.1.4_5
Dependency: libXt-1.0.9
Dependency: libXrender-0.9.6
Dependency: libXft-2.1.14
Dependency: libXfixes-5.0
Dependency: libXext-1.3.0_1,1
Dependency: libXxf86vm-1.1.1
Dependency: libXxf86dga-1.1.2
Dependency: libXv-1.0.6,1
Dependency: libXvMC-1.0.6
Dependency: libXrandr-1.3.2
Dependency: libXmu-1.1.0,1
Dependency: libXinerama-1.1.1,1
Dependency: libXi-1.4.3,1
Dependency: libXdamage-1.1.3
Dependency: libXcursor-1.1.12
Dependency: libXcomposite-0.4.3,1
Dependency: libGL-7.6.1
Dependency: libGLU-7.6.1
Dependency: libglut-7.6.1
Dependency: jasper-1.900.1_9
Dependency: libffi-3.0.9
Dependency: icu-4.8.1.1
Dependency: p5-Unicode-String-2.09
Dependency: p5-Unicode-Map8-0.13
Dependency: libiconv-1.13.1_1
Dependency: libxml2-2.7.8_1
Dependency: gettext-0.18.1.1
Dependency: recode-3.6_8
Dependency: popt-1.16
Dependency: glib-2.28.8_2
Dependency: gamin-0.1.10_4
Dependency: gio-fam-backend-2.28.8
Dependency: shared-mime-info-0.90
Dependency: gdk-pixbuf-2.23.5_1
Dependency: cairo-1.10.2_2,1
Dependency: gobject-introspection-0.10.8
Dependency: pango-1.28.4
Dependency: fribidi-0.19.2_1
Dependency: enca-1.13
Dependency: libass-0.10.0
Dependency: opencore-amr-0.1.2
Dependency: libogg-1.2.2,4
Dependency: speex-1.2.r1_3,1
Dependency: libvorbis-1.3.2,3
Dependency: libtheora-1.1.1_2
Dependency: libmad-0.15.1b_2
Dependency: libcddb-1.3.2_1
Dependency: gsm-1.0.13
Dependency: cdparanoia-3.9.8_9
Dependency: libcdio-0.82_2
Dependency: atk-2.0.1
Dependency: gtk-update-icon-cache-2.24.6
Dependency: gtk-2.24.6% cat /var/db/ports/mplayer/options
# This file is auto-generated by 'make config'.
# No user-servicable parts inside!
# Options for mplayer-1.0.r20110329_3
_OPTIONS_READ=mplayer-1.0.r20110329_3
WITHOUT_DEBUG=true
WITHOUT_BLURAY=true
WITH_RTCPU=true
WITH_OCFLAGS=true
WITH_IPV6=true
WITH_X11=true
WITH_X11XV=true
WITH_X11DGA=true
WITH_X11GL=true
WITHOUT_X11XIN=true
WITH_X11VM=true
WITH_X11XVMC=true
WITHOUT_VDPAU=true
WITH_GUI=true
WITHOUT_SDL=true
WITHOUT_SKINS=true
WITHOUT_RTC=true
WITHOUT_ARTS=true
WITHOUT_ESOUND=true
WITHOUT_JACK=true
WITHOUT_NAS=true
WITHOUT_OPENAL=true
WITHOUT_PULSE=true
WITH_LIBUNGIF=true
WITH_OPENJPEG=true
WITHOUT_MNG=true
WITHOUT_AALIB=true
WITHOUT_LIBCACA=true
WITHOUT_SVGALIB=true
WITHOUT_LIBDV=true
WITH_MAD=true
WITH_AMR_NB=true
WITH_AMR_WB=true
WITH_GSM=true
WITHOUT_LADSPA=true
WITH_SPEEX=true
WITH_THEORA=true
WITH_VPX=true
WITH_SCHROEDINGER=true
WITH_ASS=true
WITH_WIN32=true
WITHOUT_REALPLAYER=true
WITHOUT_LIVEMEDIA=true
WITHOUT_SMB=true
WITHOUT_FRIBIDI=true
WITHOUT_LIRC=true
WITH_LIBCDIO=true
WITHOUT_CDPARANOIA=true
WITHOUT_LIBLZO=true
WITHOUT_JOYSTICK=true
WITHOUT_V4L=true
WITH_LIBRTMP=true> И станет не нужeн уже сам mplayer. А зачем нужен плеер который ничего
> проигрывать не может?У вас он может ничего не может, поскольку родители блобов для вашего линукса не догадались отключить FFmpeg. ;)
А что вы с мплеером сделали чтобы у него _такой_ список зависимостей отмахал? Вот например, зачем вашему мплееру перл, питон и гткшные либы?
> А что вы с мплеером сделали чтобы у него _такой_ список зависимостей
> отмахал? Вот например, зачем вашему мплееру перл, питон и гткшные либы?За это отвечает опция "WITH_X11=true" ("Enable X11 support for mplayer's video output").
В условиях сборки Makefile для неё уготованы следующие опции сборки:
USE_GNOME+= gtk20
CONFIGURE_ARGS+= --enable-guiPerl и Python идут уже как зависимости Gtk2.
Оба не нужны, когда есть mplayer2 и libav, которые, кстати, линкуются динамически по умолчанию.
ffmpeg использует libav
Очень смешно, учитывая что libav и ffmpeg - по сути 2 названия одного и того же.
Различия уже достаточно существенны.
> Различия уже достаточно существенны.Во первых, нельзя ли примеры таких уж прямо фундаментальных отличий? Ну, что-нибудь самое крутое?
Во вторых, вы уверены что у них такой уж разный код для кучки немолодых кодеков? Скорее всего львиная доля кода была написана когда это еще было ffmpeg.
Это легко проверить загрузив оба репозитория. Никто не говорит о наличии прям фундаментальных различий, лишь о том, что сейчас делать merge уже очень трудно. Чем-то напоминает историю OO и LibreOffice. И чем дальше, тем различия будут существенней.И вообще, я не совсем понимаю формулировки «фундаментальный» в контексте ПО. Это типа должно означать, что поменялись какие-то базовые алгоритмы? Типа рендеринг h264 переписали по новой, или что?
> фундаментальных различий, лишь о том, что сейчас делать merge уже очень трудно.В плане секурити фиксов это более-менее пофиг - их можно и просто спортировать влобовую. Не понятно мне тут скорее чем вызван совет использовать libav. А советчики хотя-бы проверяли как там дела с этими уязвимостями? Или есть какие-то еще внятные аргументы "за"? Мне действительно интересно, может вы мониторили отличия достаточно внимательно?
> Чем-то напоминает историю OO и LibreOffice. И чем дальше, тем
> различия будут существенней.Ну с этими то все понятно - оракл просрал полимеры, т.к. не умеет рулить открытыми сообществами и обозлили большую часть разработчиков. В результате проект перетек под новое имя по сути. С libav и ffmpeg все менее очевидно. Насколько там большинство перебежало в libav - не понятно. В результате живут себе 2 проекта. Фабрис помнится клялся что все существенные изменения из libav будут попадать в ffmpeg и когда я смотрел - вроде не врал.
> И вообще, я не совсем понимаю формулировки «фундаментальный» в контексте ПО.
> Это типа должно означать, что поменялись какие-то базовые алгоритмы? Типа рендеринг
> h264 переписали по новой, или что?Например новый кодек засунули. Или хотя-бы существенные оптимизации сделали. Иначе не понятно чем шило лучше мыла.
Я вообще пользуюсь везде ffmpeg, libav ставил посмотреть месяца 2–3 назад. Они там тогда переименовали программы и добавили avconv. Совместимость в общем с ffmpeg осталась.Насчет того, что libav лучше, то я такого никогда не говорил, хотя бы потому что сам в это не верю. В самом лучшем случае они на уровне, хотя мне кажется ffmpeg развивается куда более динамично. Насчет качества кода — судить не берусь, скил в C/C++ не настолько высок.
Опция configure --disable-ffmpeg_a вроде. Только с багрепортами потом к авторам не обращаться, это официально не поддерживается и крайне не рекомендуется; это до сих пор не убрали только потому, что без этой возможности сильно плакали дистростроители. Есть известные баги, появляющиеся при такой динамической сборке.
> Опция configure --disable-ffmpeg_a вроде. Только с багрепортами потом к авторам не обращаться,
> это официально не поддерживается и крайне не рекомендуется; это до сих
> пор не убрали только потому, что без этой возможности сильно плакали
> дистростроители. Есть известные баги, появляющиеся при такой динамической сборке.Понятно. Ладно, можно и пережить.
>В дисплейном менеджере LightDM, используемом в Ubuntu 11.10, обнаружена уязвимость, позволяющая локальному пользователю повысить свои привилегии в системе. Проблема связана с тем, что файл с пользовательскими настройками "~/.dmrc" обрабатывается процессом с правами root, что может быть использовано для чтения произвольного файла в системе через установку на него символической ссылки (например, можно прочитать хэши паролей из /etc/shadow).И снова примитивнейшие ошибки, символические ссылки точно убьют *NIX. Их механизм до сих пор не меняется, да и X с правами root не починят никогда...
> И снова примитивнейшие ошибки, символические ссылки точно убьют *NIX.Тем временем в шиндошсе нашли MS11-083, посмешнее симлинков галимых: из сети - прямо в ядро! В макосятине тоже дыр навалом. Что предлагаете использовать? Unix V6, который только на виртуалочке запускается?
>> И снова примитивнейшие ошибки, символические ссылки точно убьют *NIX.
> Тем временем в шиндошсе нашли MS11-083, посмешнее симлинков галимых: из сети -
> прямо в ядро! В макосятине тоже дыр навалом. Что предлагаете использовать?
> Unix V6, который только на виртуалочке запускается?Уже было недавно предложение разработчиков Фидоры сделать из неё UnixV6, начав с сливания всех бинарей в одну папку.
> Уже было недавно предложение разработчиков Фидоры сделать из неё UnixV6, начав с
> сливания всех бинарей в одну папку.Ага, ведь раскидывать бинарники по куче каталогов - это так виндово.
И снова путают символические ссылки, X и LightDM! Ваша путаница до сих пор не меняется. Надо починить анализатор русского языка, и всё будет в порядке!
> И снова примитивнейшие ошибки, символические ссылки точно убьют *NIX.Собственно, эта классическая юниксовая дыра закрывается довольно просто (https://www.opennet.ru/opennews/art.shtml?num=27488). Главное, чтобы за техническую реализацию взялись не ребята из Каноникал, а кто-нибудь с более прямыми руками - тогда, глядишь, и в ядро пройдет.
Если кто и убъёт *NIX, то тупые пользователи (в их числе админы и программисты). Отсутствие мозгов не компенсируешь "изменением механизма". Не умеешь пользоваться компьютером - сиди за печатной машинкой.
А для параноиков уже и так давно существует ACL и проч.
> А для параноиков уже и так давно существует ACL и проч.Для труЪ-параноиков скорее нужны полновесные виртуализаторы типа xen/kvm. Так что прошибание ядра у гуеста не ставит под удар хост, который вообще по сетке не обязан быть доступен. Что заметно усложняет атаку. А хост может тем не менее втихарика мониторить виртуалочки.
У Ъ-параноиков как раз печатные машинки и дома без окон.
и стены мягкие, да?
>> А для параноиков уже и так давно существует ACL и проч.
> Для труЪ-параноиков скорее нужны полновесные виртуализаторы типа xen/kvm. Так что прошибание
> ядра у гуеста не ставит под удар хост, который вообще по
> сетке не обязан быть доступен. Что заметно усложняет атаку. А хост
> может тем не менее втихарика мониторить виртуалочки.Ъ^2 используют SELinux/grsec/AppArmor + xen/kvm. Вот это Ъ.
AppArmor во многих случаях легко обойти. А вот GRSecurity - действительно, непробиваемая защита: ядро падает в панику по поводу и без, враг точно не пройдет.
> AppArmor во многих случаях легко обойти. А вот GRSecurity - действительно, непробиваемая
> защита: ядро падает в панику по поводу и без, враг точно
> не пройдет.Чем-то приходится всегда жертвовать.
> Ъ^2 используют SELinux/grsec/AppArmor + xen/kvm. Вот это Ъ.Из первых трех какой-то реальный смысл имеет разве что grsec. Остальные двое предоставят возможность побегать с лыжными палками. В ластах. По асфальту.
Любой уважающий себя сплойт их сносит первым делом. Если уж хочется позащищаться от взломщика ядром системы которую он пытается распетрушить, кардинальнее и проще можно делать в стиле гуглохромиума, т.е. clone() в отдельный временный контейнер LXC, где вообще пусто. Там по определению гадить нельзя и ломать нечего: загон пустой. То же самое по смыслу, только без двух часов бега в ластах с лыжными палками по асфальту.