Доступен (http://lists.mindrot.org/pipermail/openssh-unix-announce/201...) релиз OpenSSH 5.9 (http://www.openssh.org/), открытой реализации клиента и сервера для работы по протоколам SSH (1.3, 1.5 и 2.0) и SFTP.
Из наиболее заметных улучшений можно отметить:
- Поддержка нового sandbox-режима "UsePrivilegeSeparation=sandbox", использующего rlimit и systrace для более жесткой изоляции кода, работающего на стадии до начала аутентификации (pre-auth privsep child). Если ранее, до начала аутентификации практиковался сброс прав до непривилегированного пользователя и помещение процесса в chroot-окружение /var/empty, то теперь появились механизмы, позволяющие воспрепятствовать выполнению системных вызовов к ядру и использованию сокетов. В случае проникновения через уязвимость в OpenSSH при использовании новой защиты злоумышленник не сможет эксплуатировать локальную уязвимость в ядре для повышения прав или провести атаку на другие хосты (создать сокет, запустить ...URL: http://lists.mindrot.org/pipermail/openssh-unix-announce/201...
Новость: http://www.opennet.me/opennews/art.shtml?num=31686
Жаль, что не добавили шифр Вернама. При современных дешёвых флешках и огромных дисках на сервере пора бы.
это тот, что еще называют одноразовым блокнотом?
а как обеспечить передачу ключа?
только при физическом доступе к серверу не годится - повторно использовать нельзя, необходимо дополнительно хранить на обеих сторонах информацию о том, какая часть ключа использована, передавать через то же защищенное соединение бессмысленно, даже со сжатием
IMHO, в чистом виде он практически неприменим вне зависимости от объемов носителей
>а как обеспечить передачу ключа?
>только при физическом доступе к серверу не годитсяБез доступа ни какой ключ не передать. Или нужен другой, заведомо надёжный канал.
И ещё, если у вас нет физического доступа, или ещё хуже - вам досталась собранная кем-то машина с уже установленной ОС, то и о надёжном шифровании можно не особо беспокоиться.>повторно использовать нельзя
Но большого объёма хватит надолго.
>необходимо дополнительно хранить на обеих сторонах информацию о том, какая часть ключа использована
Не просто хранить, а уничтожать. Зато видно, пользовались ли копией ключа в ваше отсутствие. И нельзя восстановить историю действий, даже имея запись трафика и вынудив вас выдать ключ.
>передавать через то же защищенное соединение бессмысленно, даже со сжатием
Сжатие вообще бессмысленно. А передача через старое защищённое (любым способом) соединение нового ключа - это плохо. Новый ключ будет скомпрометирован не позднее старого.
> Без доступа ни какой ключ не передать.Диффи-хеллман нервно покуривает в сторонке.
>в чистом виде он практически неприменим вне зависимости от объемов носителейА мужики то и не знают...
Какие мужики? Им кто-то всерьез пользуется?
Что-то все монструознее и монструознее. Эх, забыли они выкладки Берштейна, что безопасная программа должна быть маленькой и простой :(.В результате - в треде о взломе кернелорга была ссыль на форум где перец утверждал что ему вломили через 0day в openssh. С тех пор 0day в openssh никто вроде как не чинил. Все это как-то не внушает особого оптимизма.
Имхо, продукции OpenBSD вообще пока лучше не доверять. Они еще по итогам аудита IPSec не отчитались (когда непосредственные участники событий заявили о внедрении туда бэкдора по заказу американских спецслужб). Тогда все ограничилось отмазками "да мы этих ребят вообще в первый раз видим". А результаты аудита так и не огласили. То ли его так и не провели (потому что некому), то ли все-таки нашли что-то и теперь отмалчиваются.Я уж не говорю о том, что в их оси, которая позиционируется как супер-защищенная, нет даже элементарного мандатного контроля доступа.
Не о чем отчитываться, вот и не отчитались. "OpenBSD code audit uncovered bugs, but no evidece of backdoor." Отмазок "в первый раз видим", кстати, никогда не было. Сам придумал?
> Имхо, продукции OpenBSD вообще пока лучше не доверять.Пф-ф-ф, делов то... напиши свою реализацию SSH и пользуйся на здоровье.. а OpenBSD`шной ни-ни.. низя
а что такое 0day в openssh? Если гондурас тебя беспокоит, то нужно его просто почесать
> а что такое 0day в openssh?По мнению того перца - некая дырка про которую публично не известно но которая предположительно есть и позволяет взлом. Чисто теоретически это ничему не противоречит: сперва дыру находят, а только потом она становится общеизвестна. И тут все на усмотрение нашедшего и его моральных устоев. А они как известно бывают разными.
С учетом наворачивания г0вен и превращения шелла в какой-то странный швейцарский нож с 120 лезвиями - вероятность дыр все больше и больше растет в каждой версии.
>Если гондурас тебя беспокоит, то нужно его просто почесать
Боюсь я не очень понимаю данный сленг, но предположительно он не технический, а поэтому неинтересен в данном контексте. Могу лишь заметить что судя по новостям хакеры нынче регулярно норовят что-нибудь "почесать" и вообще, беспокоят.
>С учетом наворачивания г0вен и превращения шелла в какой-то странный швейцарский нож с 120 лезвиями - вероятность дыр все больше и больше растет в каждой версии.Ну, чисто теоретически... взрывное разрастание функциональности и превращение простой, но безопасной программы в развесистую блоатварь, крайне тяжелую для аудита - может вполне целенаправленно прикрывать внедрение бэкдоров. Тем более, что репутация у проекта подмочена.
Вывод: Идеальная по безопасности программа - размером в 1 бит! Да и то многовато...Как говорил когда-то С.Лем.
Для малых процессоров(имеется в виду с малым набором операций например RISC) нужно писать большую программу для выполнения одного и той же задачи, что и для больших процессоров (у которых есть расширения и куча операций на все случаи жизни:видеакселератор, аудиоакселератор...).
Отсюда вывод: чем больше мы делаем процессор, тем меньше программу надо писать. В идеале бесконечно большой процессор сможет выполнять задачи без программы и наоборот. Если написать бесконечно большую программу, то процессор не понадобится (эдакий вариант алгоритмического языка в конце 80-х в школах СССР ))) )...
В бесконечно большом процессоре, даже если забыть что он никуда не умещается, будет бесконечное количество багов :P. Хакеру не принципиально, будет ли проблема в программе или в самом процессоре. К тому же заменить программу - проще чем процессор. А у бесконечно большой программы есть одна проблема: она будет загружаться бесконечное время :P.
>>С учетом наворачивания г0вен и превращения шелла в какой-то странный швейцарский нож с 120 лезвиями - вероятность дыр все больше и больше растет в каждой версии.
> Ну, чисто теоретически... взрывное разрастание функциональности и превращение простой,
> но безопасной программы в развесистую блоатварь, крайне тяжелую для аудита -
> может вполне целенаправленно прикрывать внедрение бэкдоров. Тем более, что репутация у
> проекта подмочена.Аноним на Опеннете вещает великую правду об OpenSSH, выясненную безымянным "перцем" на не пойми каком форуме - правда, безо всякой конкретики, ну да это же мелочи.
> Что-то все монструознее и монструознее. Эх, забыли они выкладки Берштейна, что безопасная
> программа должна быть маленькой и простой :(.Вы исходники OpenSSH сначала посмотрите (а ещё лучше, сравните с чем-то аналогичным), а потом говорить об монструозности. Разработчики шагают в ногу со временем, только и всего. Описываемые изменения уложились в сравнительно небольшой объём кода.
> В результате - в треде о взломе кернелорга была ссыль на форум
> где перец утверждал что ему вломили через 0day в openssh.Угу. Конечно, проще предположить, что виноваты авторы программы, а не тот, кто за своими ключами не уследил.
> С тех пор 0day в openssh никто вроде как не чинил. Все
> это как-то не внушает особого оптимизма.Чтобы что-то починить, надо сначала это что-то сломать.
>Разработчики шагают в ногу со временем, только и всего.Ах вот как это называется. Значит, и разработчики всяких Nero Burning Rom тоже просто шагают в ногу со временем, превращая простую писалку дисков в ОС.
>Конечно, проще предположить, что виноваты авторы программы
Если авторы программы "идут в ногу со временем" - такое предположение напрашивается сразу.
>Чтобы что-то починить, надо сначала это что-то сломать.
"Все уже украдено до вас"(с)
>>Разработчики шагают в ногу со временем, только и всего.
> Ах вот как это называется. Значит, и разработчики всяких Nero Burning Rom
> тоже просто шагают в ногу со временем, превращая простую писалку дисков
> в ОС.А вы ничего не путаете? OpenSSH не проигрывает музыку, не записывает диски (в Ahead могут спать спокойно), не содержит браузер на Webkit и даже (о, ужас!) не умеет рисовать граффити ВКонтакте. Он выполняет свои функции - безопасное подключение к другим компьютерам и сетям. Какие конкретно части OpenSSH вы считаете неуместными?
>>Конечно, проще предположить, что виноваты авторы программы
> Если авторы программы "идут в ногу со временем" - такое предположение напрашивается
> сразу.Опять-таки, факты в студию. То, что само напрашивается, далеко не всегда соответствует истине.
>>Чтобы что-то починить, надо сначала это что-то сломать.
> "Все уже украдено до вас"(с)"Факты, сестра, факты"
> А вы ничего не путаете? OpenSSH не проигрывает музыку, не записывает диски
> (в Ahead могут спать спокойно), не содержит браузер на Webkit и
> даже (о, ужас!) не умеет рисовать граффити ВКонтакте.Вместо этого оно изображает впн (довольно паршиво), редиректит порты (почему это должен делать шелл?), выступает файлсервером (блин, это правда все еще шелл?) и что там я еще забыл?! А потом со всей этой фигней мы попытаемся взлететь...
>> А вы ничего не путаете? OpenSSH не проигрывает музыку, не записывает диски
>> (в Ahead могут спать спокойно), не содержит браузер на Webkit и
>> даже (о, ужас!) не умеет рисовать граффити ВКонтакте.
> Вместо этого оно изображает впн (довольно паршиво),Для решения на скорую руку (когда некогда поднимать IPSec/OpenVPN/etc.) вполне хватает. Впрочем, не суть.
> редиректит порты (почему это должен
> делать шелл?), выступает файлсервером (блин, это правда все еще шелл?) и
> что там я еще забыл?! А потом со всей этой фигней
> мы попытаемся взлететь...Во-первых, вы уж тогда придирайтесь не к OpenSSH, а к IETF. Которые под названием Secure Shell понимают как раз вышеперечисленное. ;)
Во-вторых, будьте внимательны: я специально написал, что обеспечивает безопасный доступ к другим компьютерам и сетям. С этим набором функций SSH-реализации (в первую очередь нынче это как раз OpenSSH) справляются, на большее не претендуют. Суть претензий слабо понятна, так как все приведённые аналогии, мягко говоря, притянуты за уши.
Кстати, никто не в курсе, почему из CUPS 1.4.8 выпилили поддержку GnuTLS и перешли на OpenSSL?
Ну, уж ты-то должен понимать: Эппле, GPLv3... Ага? ;->
Apple не любит GPL.
Предположим что ты прав. Но! :
CUPSTM is provided under the GNU General Public License ("GPL") and GNU Library General Public License ("LGPL"), Version 2, with exceptions for Apple operating systems and the OpenSSL toolkit. A copy of the exceptions and licenses follow this introduction.И .... ?
> И .... ?Эппле не разрабатывала и не выбирала лицензию для. Очень удачно купили фирму вместе продуктом и разработчиком, а _потом_ внизапна узнали о "неудобной" лицензии --- вот теперь елозят на гребешке. И очень, ооооочень "пужаются" LGPLv3. То есть GPLv2 они, конечно, тоже пужаются -- только деться никуда не могут.
Слабаки же.
> Эппле не разрабатывала
>елозят на гребешке. И очень, ооооочень "пужаются" LGPLv3.Хотя, возможно дело в несовместимости GPLv2(&LGPLv2) _ровно_ со стороны CUPS c LGPLv3+ со стороны GnuTLS
100 * Version 3.0.0 (released 2011-07-29)
124 ** libgnutls: license upgraded to LGPLv3> Слабаки же.
Женна - дизайнер.
Хп к88650дн - мак не рвбртвет, линух - отлияно.
вставить дрова из линуха в мак не удалась.
Купс.
бодяге уже год. Поддкржка в курсе.
У кого-то пятница начинается уже во вторник...
и к чему ты это написал?
или как обычно - если нечего сказать, то к орфографии прицепишься?
> бодяге уже год. Поддкржка в курсе.Да никто и не сомневался что у проприетарщиков техподдержка замечательная.
>И .... ?Ваш вопрос имел бы смысл, если бы Apple сама разрабатывала CUPS. Но она его купила уже готовым, так что изменить лицензию было уже нереально.
Наверняка, если бы существовали достойные аналоги под проприетарно-дружественными лицензиями (BSD-like, etc), купили бы их. Но таких, увы, не было и нет.
>если бы существовали аналоги под лицензиями BSD, купили бы их.Как? И зачем?
>Как?Точно так же, как купили CUPS.
>И зачем?
И ровно с теми же целями.
> Кстати, никто не в курсе, почему из CUPS 1.4.8 выпилили поддержку GnuTLS
> и перешли на OpenSSL?Казалось бы при чем здесь Луж^W SSL? :)
mindrot (домен по ссылке) - это что за министерство? :)
>В будущем планируется обеспечить поддержку таких механизмов, как CapsicumНе понял, это альтернативная реализация TrustedBSD или просто экстенсивное расширение POSIX capabilities?
> и изолированных пространств имен в Linux (pid/net namespaces).
LXC, конечно, хорошо, но оно ограничивает не перечень системных вызовов, а лишь область их действия. Имхо, все же не стоит забывать про SELinux, который может добавить как минимум еще один уровень защиты.
> LXC, конечно, хорошо, но оно ограничивает не перечень системных вызовов, а лишь
> область их действия.Лишь? Вот например rm -rf /* на моем сервере от рута - хреново. Для меня. А на чьем-то еще - пофигу. Для меня. А ведь это всего-то ограничение области действия системных вызовов :)
Проблема ограничения области действия в том, что теоретически возможен путь косвенного воздействия на объекты, находящиеся за пределами зоны ограничения. Особенно при отсутствии ограничений на syscalls.
> Проблема ограничения области действия в том, что теоретически возможен путь косвенного
> воздействия на объекты, находящиеся за пределами зоны ограничения. Особенно при отсутствии
> ограничений на syscalls.Практически однако я не слышал о, допустим, взломе хоть тех же openvz-контейнеров. Хотя это на каждом первом хостинге понатыкано уже немало лет.
> Практически однако я не слышал о, допустим, взломе хоть тех же
> openvz-контейнеров. Хотя это на каждом первом хостинге понатыкано уже немало лет.Многие ядерные (не юзерспейсные, это важно) дыры на local root позволяют обойти контейнерную изоляцию. Прецеденты были (например, кое-кого повскрывали в честь модуля tun). Видимо, те, на чей опыт вы опираетесь, являются неуловимыми Джо.
перехват системных вызовов от этого тоже не спасёт
> перехват системных вызовов от этого тоже не спасётЗависит от, имхо. Если проблемный сискол до ядра вообще не долетит - то почему бы и нет? :)
> Зависит от, имхо. Если проблемный сискол до ядра вообще не долетит -Долететь-то он, может, и долетит, но не туда, куда хотелось. Не в уязвимую мякотку, а в бессердечный код предварительной фильтрации. А дальше уже все, печалька.
потому что сисколов всего несколько десятков, большая часть всего функционала реализуется вообще через примерно десяток, нельзя практически ничего запретить без потери работоспособности. Нет такого сискола как 'поднять_себе_привелегии_до_рута_и_на.._админа'.Чтобы такой подход был действенным нужно анализировать протоколы следующего уровня (над сисколами) и заранее иметь базу возможных атак. Это может помочь только для совсем никак не поддерживаемых закрытых продуктов.
> потому что сисколов всего несколько десятков, большая часть всего функционала реализуется
> вообще через примерно десяток, нельзя практически ничего запретить без потери работоспособности.С вашей логикой, и POSIX capabilties должны быть абсолютно бесполезны. Однако они почему-то благополучно используются.
> нельзя практически ничего запретить без потери работоспособности.
Это особо порадовало.
Надо вообще всем программам рута дать, а то они наверняка из-за всяких ограничений работоспособность теряют.
posix caps'ы не решают проблем качества кода, а именно по этой причине в большинстве случаев удаётся поиметь локалхост, а не из-за проблем архитектуры. Это всего лишь ещё один механизм более гранулированной раздачи прав. И...> Однако они почему-то благополучно используются.
они просто благополучно существуют примерно как и SElinux и множество прочих решений. Есть то они есть, все такие замечательные, но никто особо не спешит ими пользоваться в широких масштабах. Почему так получается уже другой вопрос.
> вообще через примерно десяток, нельзя практически ничего запретить без потери работоспособности.Расскажите это парням с codepad.org. Они это не знают и поэтому у них работает запуск сишного кода напечатанного в браузере. И да, эти стремные типы зачем-то порезали сисколы. Наверное чтобы их виртуалку не хакали еще на подходах, так сказать :)))
> Нет такого сискола как 'поднять_себе_привелегии_до_рута_и_на.._админа'.Это вообще к чему? Лавры Капитана не дают покоя?
> Чтобы такой подход был действенным нужно анализировать протоколы следующего уровня (над
> сисколами)А что такое "протоколы следующего уровня"? Ну вот например форкнул я процесс. Что является "протоколом следующего уровня"?
> и заранее иметь базу возможных атак. Это может помочь только
> для совсем никак не поддерживаемых закрытых продуктов.А про эти можно только сказать что горбатого могила исправит.
> Они это не знают и поэтому у них работает запуск сишного кода напечатанного в браузере. И да, эти стремные типы зачем-то порезали сисколы.И как, много пользы получил выполнения кода в такой поеразнной виртуалке? Когда сделаешь на этом функционально богатое полезное приложение, тогда пиходи дальше писать ерунду.
> Нет такого сискола как 'поднять_себе_привелегии_до_рута_и_на.._админа'.setuid(0);
>перехват системных вызовов от этого тоже не спасётДа неужели? А как тогда, по-вашему, обычно эксплуатируются подобные дыры? Воздушно-капельным путем?
смотри комент выше
> Многие ядерные (не юзерспейсные, это важно) дыры на local root позволяют обойти
> контейнерную изоляцию. Прецеденты были (например, кое-кого повскрывали в честь модуля
> tun). Видимо, те, на чей опыт вы опираетесь, являются неуловимыми Джо.В принципе - да, это возможно. Если совсем ссыкотно - можно и более тяжеловесный виртуализатор использовать. Там даже проломленное ядро виртуалки - как бы не страшно. Правда скорость в отместку местами просядет, увы.
> Многие ядерные (не юзерспейсные, это важно) дыры на local rootВ смысле local kernel?
> В смысле local kernel?Нет, именно выполнение кода с повышенными привилегиями. У локальных досов своя специфика, которая требует отдельного обсуждения.
>> В смысле local kernel?
> Нет, именно выполнение кода с повышенными привилегиями. У локальных досов своя специфика,
> которая требует отдельного обсуждения.Не, ну dos всяко != kernel... была пара раз (припоминается коркомёт и будто ksplice), когда из тех же контейнеров вылазили прям в ядро.
local dos может быть и через ядро, примеров куча (почти каждую недели в линуксе такое находят).Это просто два разных критерия классификации уязвимости - тип уязвимости (дос, исполнение кода с повышенными привилегиями, etc) и классу уязвимого кода (ядро или юзерспейс).
Я говорил конкретно про исполнение кода с повышенными привилегиями за счет уязвимостей ядра.
>Не понял, это альтернативная реализация TrustedBSD или просто экстенсивное расширение POSIX capabilities?Хз, я не фанат безопасности, погляди: http://www.cl.cam.ac.uk/research/security/capsicum/
Судя по тамошнему куцему описанию, это такое недоLXC.
Когда очепятки пальцев можно будет как ключ юзать?
> Когда очепятки пальцев можно будет как ключ юзать?Думаю что никогда - надежность этого метода применительно к доступу к удаленным серверам получается крайне хилая. К тому же не понятно что делать если хаксор угнал снимки пальцев и подсовывает их внаглую как якобы картинку со сканера.
Отпечатки как картинки хранят только труодлфагименты.
В системах биометриии они пересчитываются в хэш.
>В системах биометриии они пересчитываются в хэш.Перед этим необходимо довольно трудоемкое преобразование. Потому что хэшировать обычный снимок - заведомый идиотизм. Простая аналогия: если сфоткать одного и того же человека два раза подряд с перерывом в полсекунды, даже если и он, и фотограф постараются не двигаться - все равно с вероятностью 99% даст различные хеши фоток. Для использования в биометрии, снимки нужно обработать и выделить некий каркас, нечувствительный к случайным помехам.
> В системах биометриии они пересчитываются в хэш.И что помешает хаксору высылать этот же хеш "как будто бы только что со сканера"? Кроме того, учитывая дубовое разрешение сканера и огрубления из-за допусков на неточности (иначе сам владелец хрен проавторизуется из-за несовпадений) - есть опасения что сие могут попросту сбрутфорсить.
> В системах биометриии они пересчитываются в хэш.Да похрен. Пароль в случае кражи хотя-бы сменить можно. А что делать если сопрут хэш?
>> Когда очепятки пальцев можно будет как ключ юзать?
> Думаю что никогда - надежность этого метода применительно к доступу к удаленным
> серверам получается крайне хилая. К тому же не понятно что делать
> если хаксор угнал снимки пальцев и подсовывает их внаглую как якобы
> картинку со сканера.Угнать можно и закрытый ключ, если получится. Здесь разница лишь в распространенности. Руками вы касаетесь за множество вещей. Отпечатки можно снять, просто забрав после ваш стакан в кафе. Закрытый же ключ лежит в одном месте и менее легкодоступен, чем отпечатки.
А генерировать закрытый ключ с отпечатков или с /dev/random - разницы нет, все равно серверы получат только открытый, поэтому уровень защиты В СЕТИ одинаковый.