Во всех поддерживаемых версиях FreeBSD 7.x и 8.x обнаружена уязвимость (http://security.freebsd.org/advisories/FreeBSD-SA-10:07.mbuf...), позволяющая локальному пользователю повысить свои привилегии в системе или вызвать повреждение содержимого любого файла. Ветка FreeBSD 6.x проблеме не подвержена.
Источником проблемы является ошибка в реализации технологии mbufs, используемой для организации промежуточного хранения данных в сетевой подсистеме и при межпроцессном взаимодействии. Mbuf определяет базовый буфер памяти, в котором небольшой блок данных может сохраняться напрямую или в виде ссылки на внешний буфер. Системный вызов sendfile для организации прямой передачи данных использует маппинг файла в цепочку mbuf-блоков, предусматривая возможность установки специального флага для обеспечения доступа к режиме только для чтения.
Ошибка связана с тем, что флаг read-only не наследуется при дублировании ссылки на mbuf-буфер. При вызове sendfile для передачи данных через loopback...URL: http://security.freebsd.org/advisories/FreeBSD-SA-10:07.mbuf...
Новость: http://www.opennet.ru/opennews/art.shtml?num=27287
похоже после семерки дырки с локальными "суперпользователями" стали традиционными
вообще-то обнаружили это не какие-то левые люди, а те, кто занимается уязвимостями в проекте freebsd. Обнаружили, тут же об этом сообщили пользователям, и уверен, что очень скоро подготовят патч для исправления уязвимости. А от ошибок в процессе разработки ПО никто не застрахован, каким бы Вы гением ни были.
Ах да, уже подготовили патчи
Ну а что, не одним же убунтуйцам лажаться? :)
Не моуг понять, о чём ты
Полагаю, что он имел ввиду это: http://www.opennet.ru/opennews/art.shtml?num=27239
дырок там наверняка не меньше, чем в оффтопике или линуксе. Просто в связи с меньшей популярностью этой ОС их не так интенсивно ищут.
Именно. Частота обнаружения дыр гораздо сильнее зависит от масштаба проекта и его аудитории, чем от других факторов. Разработчики - тоже люди, и они иногда ошибаются, будь то разработчики FreeBSD, linux или винды.Другой дело, что ошибки в малопопулярном проекте могут незамеченные жить годами, а в широко используемых системах их находят и фиксят очень быстро.
У таких людей как вы вероятность встретить дизнозавра на улице равно 50%. Ведь действительно, "или встретите, или нет" :)
Все гораздо проще.Количество дыр напрямую зависит от качества проектирования, а не от того, сколько людей ищут.
А качество проектирования начинает сильно падать именно с ростом популярности - из-за желания угодить всем. А также начинает резко падать качество самих тех, кто ищут.
Они начинают искать больше второстепенне баги, а не концептуальные ошибки, требуют большей стабильности пользовательского интерфейса, а не внутренней архитектуры. Требуют все больше жертвовать архитектурой ради всяких там оптимизаций, обратных совместимостей и разных второстепенных фич. В первую очередь сопротивляются любому рефакторингу, если это может повлечь изменения того, к чему привыкли, и временные нестабильности.
Так что все сходится. Количество багов увеличивается с ростом популярности.
>Количество дыр напрямую зависит от качества проектирования, а не от того, сколько людей ищут.Полностью поддерживаю!
Скорее - в популярных системах и чаще находят и используют во всю :)))
Согласен. Однако Windows не будем брать в расчет, так как там о багах знают, но исправляют почему-то долго
Потому что если будут исправлять часто - юзеров ребуты заколебут. В винде нельзя просто взять и заменить юзаемый бинарник (EXE или DLL). Потребуется ребут.
>Потому что если будут исправлять часто - юзеров ребуты заколебут. В винде
>нельзя просто взять и заменить юзаемый бинарник (EXE или DLL). Потребуется
>ребут.Начиная с Windows 2000 это уже не всегда так. А патчи наборами они выпускают для удобства администраторов, в крупных, а тем паче крупных распределённых сетях каждое массовое обновление требует большого внимания — проще сразу протестировать комплект, если всё работает, то и хорошо.
>Начиная с Windows 2000 это уже не всегда так.Практически всегда. MSI инсталлер и виндусьапдейтер традиционно просит ребут если файл который надо было обновить был залочен и перезаписать его без дополнительных фокусов - не удалось. Сделано все это довольно таки через зад и лично я не заметил каких-то принципиальных улучшений начиная с 2000. Все-равно каждая серия апдейтов требует ребут.
>А патчи наборами они выпускают для удобства администраторов,
Они по другому при всем желании не смогли бы - ребуты раз в два дня всех доканали бы. А ребут требуется даже при обнвлении IE, пардон, дыры в котором находят не то чтобы редко. Следствие интеграции браузера в систему(знаете иные браузеры патчинг которых требовал бы всю систему отребутить?). Часть либ в итоге держится сторонними программами и не может быть просто так перезаписана. Вот и городят черезпопные воркэраунды - переименовать проблемный файл, записать новый, в потом в ребут и стереть таки старую (переименованную) версию. В *никсах то же самое по смыслу получается сильно менее через задницу и без таких плясок с бубном. Строго говоря, есть 1 повод рестарта системы целиком: ядро обновили. Хотя вон авторы ksplice считают иначе и умудряются даже ядро запатчить без рестарта :)
>в крупных, а тем паче крупных распределённых сетях каждое массовое обновление
>требует большого внимания — проще сразу протестировать комплект,Если честно - не видел энтерпрайзов которые бы сильно морочались с тестированием пачек апдейтов на куче машин. Это очень затратно - все возможные конфиги в жизни не протестируешь. Поэтому так заморачиваются крайне редко.Может для пары особо ценных серверов каких-нибудь, и то не факт.
>если всё работает, то и хорошо.
Много вы контор видели где так делается? Я как-то не очень.
>>Начиная с Windows 2000 это уже не всегда так.
>
>Практически всегда. MSI инсталлер и виндусьапдейтер традиционно просит ребут если файл который
>надо было обновить был залочен и перезаписать его без дополнительных фокусов
>- не удалось. Сделано все это довольно таки через зад и
>лично я не заметил каких-то принципиальных улучшений начиная с 2000. Все-равно
>каждая серия апдейтов требует ребут.Я про появившийся в NT5 флаг FILE_SHARE_DELETE (см. MSDN: http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx - блин, как же неудобно заниматься этим тормознутым поиском после "man function"...). К сожалению, им мало кто пользуется...
>>А патчи наборами они выпускают для удобства администраторов,
>
>Они по другому при всем желании не смогли бы - ребуты раз
>в два дня всех доканали бы. А ребут требуется даже при
>обнвлении IE, пардон, дыры в котором находят не то чтобы редко.
>Следствие интеграции браузера в систему(знаете иные браузеры патчинг которых требовал бы
>всю систему отребутить?).Ну, сами по себе ребуты не доканывают, рабочие станции ведь обычно использутся с девяти до шести, плюс-минус сколько-то часов - вечером обновления перед выключением сами накатываются, и всё — в винде можно их из локального (в смысле, который в локальной сети) репозитория ставить. На серверах же IE можно не торопиться обновлять. :)
>Часть либ в итоге держится сторонними программами и
>не может быть просто так перезаписана. Вот и городят черезпопные воркэраунды
>- переименовать проблемный файл, записать новый, в потом в ребут и
>стереть таки старую (переименованную) версию.Как я догадываюсь, это одна из причин, по которым MS столь активно продвигает .NET — там эта проблема решена.
> В *никсах то же самое по
>смыслу получается сильно менее через задницу и без таких плясок с
>бубном. Строго говоря, есть 1 повод рестарта системы целиком: ядро обновили.
>Хотя вон авторы ksplice считают иначе и умудряются даже ядро запатчить
>без рестарта :)У NT и Linux сильно разная архитектура; в принципе, как я догадываюсь, в NT эту фичу даже проще было бы реализовать. Но не стали… Может, товарищ Трухин найдёт по этому поводу что сказать? Я-то лет пять уже не слежу за развитием темы. :)
>>в крупных, а тем паче крупных распределённых сетях каждое массовое обновление
>>требует большого внимания — проще сразу протестировать комплект,
>
>Если честно - не видел энтерпрайзов которые бы сильно морочались с тестированием
>пачек апдейтов на куче машин. Это очень затратно - все возможные
>конфиги в жизни не протестируешь. Поэтому так заморачиваются крайне редко.Может для
>пары особо ценных серверов каких-нибудь, и то не факт.Если в том энтерпрайзе зоопарк машин и конфигураций, то... сами себе злобные пингвины, конечно. Обычно всё же имеется один или несколько установочных наборов, и тестирование проводить вполне реально - на моей прошлой работе так и делали.
>>если всё работает, то и хорошо.
>
>Много вы контор видели где так делается? Я как-то не очень.Я тоже не очень. Что, правда, скорее следует списать на отсутствие культуры обслуживания (в широком смысле этого слова: как людей, так и техники) на территории бСССР. :(
Да да да.. Linux образец для подражания - и однажды загруженая библиотека магическим образом выгрузится из памяти.
Ну ты хоть бы такой бред не писал :)
Ну да - файлик будет создан новый и запись из каталога удалится, но
1) место никто не освободит пока последний процесс не закроет файл
2) из памяти никто не выгрузит пока не закрыли дискритор
3) учитывая фишки prelink - есть не нулевой шанс что загруженая библиотека будет наследоваться.То есть - что бы исправления реально применились надо закрыть все приложения которые эту библиотеку используют. ха-ха три раза если обновляется glibc - вот и нашелся второй повод для рестарта.
А если вдруг надо обновить библиотеки из kdelibs или gnome - или не дай бог что-то из xorg ?
это же тоже рестарт :)О сколько причин сделать рестарт нашлось.. вместо твоего одного.
Может стоит подумать чутку?
Мда, сразу видно оранжевого человека. Да, в юниксах библиотеки не выгружаются. Но, извини меня, здесь достаточно перезапустить сервисы, чтобы прочитать новые конфиги.> ха-ха три раза если обновляется glibc - вот и нашелся второй повод для рестарта.
Ну, как бы, такие обновления планируют, под них выделяется время в продакшне, предварительно проводятся обновления на тестовых машинах. Это в случае обновлений ядра и подобных glibc библиотек. А на десктопе своем перегружайтесть сколько хотите
> А если вдруг надо обновить библиотеки из kdelibs или gnome - или не дай бог что-то из xorg ?# init 3 && init 5
>Согласен. Однако Windows не будем брать в расчетНу конечно, я знал, что рано или поздно кто-нибудь подобный комментарий напишет :-D Ранее сказали, что дырок везде хватает и всё определяется популярностью ОС. Windows самая популярная OC, и, стало быть, дырки там ищут гораздо интенсивнее чем где-либо еще. Таким образом, меньше становится поводов после каждой обнаруженной в Windows уязвимости обливать её грязью и злорадствовать. А это уже не порядок! :-D Поэтому да, Windows в расчет мы "не будем брать".
>Windows самая популярная OC, и, стало быть, дырки там ищут
>гораздо интенсивнее чем где-либо еще.Это верно.
Но из этого не следует, что она не дырявая)
Там вполне может быть ещё много дырок самих по себе.
Как пример, можно вспомнить про дырку, связанную с *.ani указателями.
Эта дырка оказалась во всех версиях Windows.
Но "количество ещё неизвестных дыр" - это тоже демагогия - нет конкретики.В качестве конкретных вещей можно указать на такой момент.
Не всегда уязвимость связана с дыркой.
Как пример - куча вирусов.
Очень много вирусов использут вполне честные способы прописывания себя в системе.
В *nix против многих честных методов давно есть контрмеры.
Как пример - флаг noexec при монтировании раздела.
Если флешку, диск, или дискету монтировать с noexec, то вирус оттуда просто не сможет запуститься.
Есть ли такое в Windows - не знаю.
Если только с какими-нибудь ACL извратнуться)Ну и в Windows люди обожают работать из под админа, и отрубать окошко "требуется подтверждение", которое появилось в висте.
Так что дело не только в дырках ПО.
Дело ещё в дырках в головах разработчиков =)
Плюс дырки в головах проектировщиков.
Плюс дырки в головах пользователей, куда ж без них)
>Как пример - куча вирусов.Это не пример, уже миллион раз обсуждалось, что вирусы возможны под любой системой, это лишь вопрос актуальности и "прибыльности".
>Как пример - флаг noexec при монтировании раздела.
>Если флешку, диск, или дискету монтировать с noexec, то вирус оттуда просто не сможет >запуститься.
>Есть ли такое в Windows - не знаю.
>Если только с какими-нибудь ACL извратнуться)в windows такое есть давным-давно. можно запретить запуск программ со съемных носителей, можно вообще запретить запуск любых программ кроме тех, что находятся в этом каталоге, или в этом белом списке, или имеют такое имя файла или даже имеют такой вот хэш (против умников, умеющих переименовывать файлы). Все это нужно просто настроить, как и noexec, поэтому это проблема не windows, а основной её массы пользователей. Работа из-под админа - из той же оперы, хотя в Vista и тем более в seven это уже не так, в семёрке и ACL сделали вменяемый.
Судя по такой логике, в Apache должно быть ну просто дофига дырок (больше половины рынка всё-таки), а в QNX баги просто еще некому было найти.
>Судя по такой логике, в Apache должно быть ну просто дофига дырок
>(больше половины рынка всё-таки), а в QNX баги просто еще некому
>было найти.И? Посмотри сколько дырок находят в Апаче, сколько в QNX и сравни. Все сходится ;)
>>Судя по такой логике, в Apache должно быть ну просто дофига дырок
>>(больше половины рынка всё-таки), а в QNX баги просто еще некому
>>было найти.
>
>И? Посмотри сколько дырок находят в Апаче, сколько в QNX и сравни.
>Все сходится ;)Думайте, пожалуйста, головой, а не жопой. В апаче дырок меньше, чем в IIS, при большей, чем у IIS, популярности. Малое количество дырок в QNX - по другим причинам, нежели низкая популярность (популярность среди кого, хех?..).
>Думайте, пожалуйста, головой, а не жопой. В апаче дырок меньше, чем в
>IIS, при большей, чем у IIS, популярности.Ой, да ладно, Вы сравнивали? Апач сейчас жирный, неповоротливый и дырявый монстр, совсем не то легкое перышко, что у него в логотипе. Есть ссылки на свежую статистику - милости просим.
>Ой, да ладно, Вы сравнивали? Апач сейчас жирный, неповоротливый и дырявый монстр, совсем не то легкое перышко, что у него в логотипе. Есть ссылки на свежую статистику - милости просим.Да ладно! А что же он тогда работает быстрее "легчайшего" IIS? :-)
>Да ладно! А что же он тогда работает быстрее "легчайшего" IIS? :-)Если кому-то пришло в голову использовать IIS для какого-нибудь PHP, то он явно идиот. Область использования IIS - это большие ASP.NET/Sharepoint приложения. Неужто Апач быстрее IIS работает на ASP.NET приложениях? :-D И кто говорил про "легчайший IIS"? Была фраза про жирность апача, если Вы из этого делаете такие выводы, то у Вас проблемы с логикой ;)
>>Да ладно! А что же он тогда работает быстрее "легчайшего" IIS? :-)
>
>Если кому-то пришло в голову использовать IIS для какого-нибудь PHP, то он
>явно идиот. Область использования IIS - это большие ASP.NET/Sharepoint приложения. Неужто
>Апач быстрее IIS работает на ASP.NET приложениях? :-D И кто говорил
>про "легчайший IIS"? Была фраза про жирность апача, если Вы из
>этого делаете такие выводы, то у Вас проблемы с логикой ;)Нет, это проблемы не с логикой, а с образованием. Комментатор просто не знает, что существует что-то ещё кроме Apache и IIS, и поэтому вполне логично предположил, что если Apache так плох, то сравнивали его с IIS. ;)
Области использования IIS всего две:
1) там, где админ ниасилил что-то иное
2) там, где установленная проприетарщина требует IIS, и ничего кроме IIS
>>Думайте, пожалуйста, головой, а не жопой. В апаче дырок меньше, чем в
>>IIS, при большей, чем у IIS, популярности.
>
>Ой, да ладно, Вы сравнивали? Апач сейчас жирный, неповоротливый и дырявый монстр,
>совсем не то легкое перышко, что у него в логотипе.Интересная аргументация.
Хотя с nuclight только такие аргументы и остаются - в предметном споре сольете =)
В дистрибутивах с компилируемым софтом (Gentoo/FreeBSD) при установке апача можно явно указывать собираемый функционал.
Так же можно собрать апач по старинке: ./configure с кучей параметров, make, make install.
Хотя даже при бинарной сборке все тоже не так плохо - закомментировал лишние модули и нормалек.А вообще, имхо, чем больше проект, тем меньше шансов нарваться на дырку у обычного пользователя.
Так как основной функционал лучше вылизан.
С одной оговоркой - продуктов MS это не касается)
>>>Думайте, пожалуйста, головой, а не жопой. В апаче дырок меньше, чем в
>>>IIS, при большей, чем у IIS, популярности.
>>
>>Ой, да ладно, Вы сравнивали? Апач сейчас жирный, неповоротливый и дырявый монстр,
>>совсем не то легкое перышко, что у него в логотипе.
>
>Интересная аргументация.Боюсь, что в известной степени он прав. Не случайно многие администраторы Web-проектов до сих пор стараются использовать 1.3 (который сам по себе тоже не сахар). Ветка 2.x только-только стала действительно относительно стабильной. Но в реальности именно Apache HTTPd сервер сдаёт позиции. Зато обороты набирает Tomcat, да. :))
>[оверквотинг удален]
>>>Ой, да ладно, Вы сравнивали? Апач сейчас жирный, неповоротливый и дырявый монстр,
>>>совсем не то легкое перышко, что у него в логотипе.
>>
>>Интересная аргументация.
>
>Боюсь, что в известной степени он прав. Не случайно многие администраторы Web-проектов
>до сих пор стараются использовать 1.3 (который сам по себе тоже
>не сахар). Ветка 2.x только-только стала действительно относительно стабильной. Но в
>реальности именно Apache HTTPd сервер сдаёт позиции. Зато обороты набирает Tomcat,
>да. :))В современных мультфильмах ежы тоже сдают голой заднице! Что делать?
>[оверквотинг удален]
>>>
>>>Интересная аргументация.
>>
>>Боюсь, что в известной степени он прав. Не случайно многие администраторы Web-проектов
>>до сих пор стараются использовать 1.3 (который сам по себе тоже
>>не сахар). Ветка 2.x только-только стала действительно относительно стабильной. Но в
>>реальности именно Apache HTTPd сервер сдаёт позиции. Зато обороты набирает Tomcat,
>>да. :))
>
>В современных мультфильмах ежы тоже сдают голой заднице! Что делать?Арестовать 310dej и посадить на двадцать лет в карцер, так как это он во всём виноват.
>>Интересная аргументация.
>
>Боюсь, что в известной степени он прав.Ну это просто смотря с чем сравнивать.
Если с этим же продуктом, то есессно, что более старые версии полегче и пошустрее будут.
Хотя... це тоже смотря где - можно поиграться с разными worker'ами.
У 1.3 - это, вроде, только prefork.
У 2.х - их поболя, особенно с SMP и потоками.
Можно подобрать более оптимальный под какую то ситуацию.Но суть в чем.
Если сравнивать разные продукты одного функционала (т.е. не с nginx), то разница будет видна.
А если сравнивать с IIS... =)
Важно скорее не количество дырок, а скорость их закрытия.
Патч-то выпустили уже?
Фиг с ним с патчем, эксплойт есть?
))))
эксплоит простой - шлешь файл используя sendfile() через лупбэк. Если делать это долго то файл будет поврежден. Если это делать очень долго, возможно вечно то вместо мусора в файле возможно будет что то нужное для повышения привилегий.
>Патч-то выпустили уже?по ссылкам ходить не умеем?
freebsd-update fetch install
все исправляет
> freebsd-update fetch install
> все исправляетЗачем сразу так? Можно и просто ядро перебрать.
> > freebsd-update fetch install
>> все исправляет
>
>Зачем сразу так? Можно и просто ядро перебрать.Если GENERIC, то бинарным апдейтом будет быстрее.
вот оригинал статьи http://security.freebsd.org/advisories/FreeBSD-SA-10:07.mbuf..., там сразу и метода и патч, так что говорить Freebsd не популярна, или она умрет. Перейдите на другие форумы, или не позорьтесь своей глупостью перед другими повторяя чужие заблуждения.
вот только спрашивается почему баги начинаются только с 7.х?...
6.х последняя ветка пригодная для использования.P.S.
может сменился в упр. совете у них кто-то? )
>вот только спрашивается почему баги начинаются только с 7.х?...
>6.х последняя ветка пригодная для использования.Последняя была 4.x... Недаром именно на её основе Стрекоза была основана.
>P.S.
>может сменился в упр. совете у них кто-то? )Дык не раз уже, кажись.
Именно! Диллон потому и взял 4.8 за стартовую хотя были и более поздние уже на тот момент вроде. От 5.х он принципиально отказался
>Именно! Диллон потому и взял 4.8 за стартовую хотя были и более
>поздние уже на тот момент вроде. От 5.х он принципиально отказался
>Отказался не потому, что 5.х хуже, а потому что там начали улучать работу SMP. А у Дилона совсем иной подход, мало похожий на то что сделали во FreeBSD 5-6-7-8. Какой подход лучше покажет время.
> Какой подход лучше покажет время.Скорее - какой подход жизнеспособнее (в силу разных причин), вот betamax был технически лучше vhs, однако проиграл борьбу за домашний рынок.
betamax проиграл VHSу только из-за того, что вчс выбрали сами знаете кто.
>betamax проиграл VHSу только из-за того, что вчс выбрали сами знаете кто.
>Microsoft? o_O
>>betamax проиграл VHSу только из-за того, что вчс выбрали сами знаете кто.
>>
>
>Microsoft? o_OСудя по википедии - JVC, в 1976 году.
>betamax проиграл VHSу только из-за того, что вчс выбрали сами знаете кто.А теперь смешной вопрос: почему его выбрали?
> А теперь смешной вопрос: почему его выбрали?Дешевле в производстве был.
>> А теперь смешной вопрос: почему его выбрали?
>
>Дешевле в производстве был.Ффточку! А теперь финальный вопрос: будь производство дороже, было бы у него столько же шансов стать массовым? :)
Магнитооптика, например, тоже весьма любопытная штука, но компакт-диски в сочетании с винчестерами оказались всё же народнее.
> 6.х последняя ветка пригодная для использованияВ Линукс 1.3 доже давно не находили дырок. Похоже это тоже последняя пригодная для применения версия ядра, основаваясь на вашей логике.
Ничего подобного. Версия 6.0 - это 2005 год. А не 1995-й.
Насколько я помню, версия 6.0 стала революционной в том плане, что 5-й версией мало кто пользовался из-за того, что она стала хуже четвёртой. Шестая постепенно возвращалась к былой планке надёжности
Бред какой-то.
Просто FreeBSD 6 была следующей мажорной версией после 5-ки, в которая была координально перепилена в сравнении с предыдущими версиями.
А баг с mbuf-волне ожидаем, бо начиная с 7-ки был оптимизирован(местами переписан) сетевой стек.
По поводу быстрого залатывания дырок)))) Только что мне пришел ответ на баг-репорт, взгляните на даты)))Arrival-Date: Mon Feb 26 15:20:04 GMT 2007
Closed-Date:
Last-Modified: Wed Jul 14 06:25:00 UTC 2010
>По поводу быстрого залатывания дырок)))) Только что мне пришел ответ на баг-репорт,
>взгляните на даты)))
>
>Arrival-Date: Mon Feb 26 15:20:04 GMT 2007
>Closed-Date:
>Last-Modified: Wed Jul 14 06:25:00 UTC 2010Ссыль на баг?
>По поводу быстрого залатывания дырок)))) Только что мне пришел ответ на баг-репорт,
>взгляните на даты)))
>
>Arrival-Date: Mon Feb 26 15:20:04 GMT 2007
>Closed-Date:
>Last-Modified: Wed Jul 14 06:25:00 UTC 2010Sadly this is not telling us enough to get this going (at least it
is not telling me enough to get this rolling): can you have a look
at http://www.freebsd.org/doc/en/books/developers-handbook/kern...
and follow the instructions listed there? That way we have a better
and detailed view on what is going on.
In addition, are you perhaps able to confirm whether this is also
the case on 6.x?
Thanks!
remko
--
Kind regards,
Remko Lodder ** remko at elvandar.org
FreeBSD ** remko at FreeBSD.org
/* Quis custodiet ipsos custodes */
Оттуда?