The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз OpenSSH 5.9

06.09.2011 15:36

Доступен релиз OpenSSH 5.9, открытой реализации клиента и сервера для работы по протоколам SSH (1.3, 1.5 и 2.0) и SFTP.

Из наиболее заметных улучшений можно отметить:

  • Поддержка нового sandbox-режима "UsePrivilegeSeparation=sandbox", использующего rlimit и systrace для более жесткой изоляции кода, работающего на стадии до начала аутентификации (pre-auth privsep child). Если ранее, до начала аутентификации практиковался сброс прав до непривилегированного пользователя и помещение процесса в chroot-окружение /var/empty, то теперь появились механизмы, позволяющие воспрепятствовать выполнению системных вызовов к ядру и использованию сокетов. В случае проникновения через уязвимость в OpenSSH при использовании новой защиты злоумышленник не сможет эксплуатировать локальную уязвимость в ядре для повышения прав или провести атаку на другие хосты (создать сокет, запустить прокси и т.п.).

    В различных системах для работы нового sandbox-режима используются различные механизмы. Например, в OpenBSD для ограничения числа допустимых системных вызовов задействована система systrace. Для Mac OS X и Darwin подготовлен модуль seatbelt, который использует подсистему sandbox для задания политики ограничения доступа к файловой системе и сетевым ресурсам. Для других систем возможно использование механизма setrlimit для установки в ноль лимитов на число файловых дескрипторов/сокетов, число процессов и размер создаваемого файла. В будущем планируется обеспечить поддержку таких механизмов, как Capsicum и изолированных пространств имен в Linux (pid/net namespaces).

  • Добавлены основанные на хэше SHA256 новые HMAC-режимы проверки целостности: hmac-sha2-256, hmac-sha2-256-96, hmac-sha2-512 и hmac-sha2-512-96;
  • Изменен метод ведения лога процессами в режиме изоляции привилегий, которые теперь не требуют наличия /dev/log в chroot, а передают сообщения через сокет, который обрабатывает основной master-процесс;
  • В директивах AuthorizedKeysFile, UserKnownHostsFile и GlobalKnownHostsFile теперь можно указывать одновременно несколько путей, разделенных пробелом. Поддержка недокументированных опций AuthorizedKeysFile2 и GlobalKnownHostsFile2 прекращена - файлы authorized_keys2 и known_hosts2 теперь указываются через базовые опции;
  • В директиве ControlPath на имя хоста назначения теперь можно ссылаться через "%L";
  • В директиве "Host" добавлена поддержка операций отрицания, например: "Host *.example.org !c.example.org" примет "a.example.org" и "b.example.org", но отвергнет "c.example.org";
  • В ssh_config добавлена поддержка опции RequestTTY, которая позволяет контролировать привязку к TTY по аналогии с опциями командной строки "-t/-tt/-T";
  • В sshd реализация аутентификации GSSAPI теперь определяет, когда случаи сбоя на стороне сервера приводят к сбою аутентификации и не учитывает данные сбои при расчете лимита MaxAuthTries;
  • В ssh-keygen добавлена опция "-A", при указании которой автоматически будут созданы все типы недостающих ключей с параметрами по умолчанию и пустым паролем. Опцию удобно использовать в скриптах инициализации системы;
  • Возможность прекращения мультиплексирования соединений с сервером без обрыва уже установленных соединений ("ssh -O stop ...");
  • В ssh-add добавлена возможность приема ключей из стандартного ввода ("ssh-add - < /path/to/key");
  • В Portable OpenSSH устранены проблемы со сборкой кода, обеспечивающего поддержку SELinux; удалена поддержка ssh-rand-helper (случайные числа запрашиваются из OpenSSL или через PRNGd/EGD); обновлены .spec-файлы и скрипты инициализации для Linux; устранены проблемы со сборкой для платформ, без поддержки dlopen().


  1. Главная ссылка к новости (http://lists.mindrot.org/piper...)
  2. OpenNews: Пример анализа потенциально серьезной уязвимости в OpenSSH
  3. OpenNews: Для OpenSSH реализована поддержка дополнительной изоляции
  4. OpenNews: Вышло обновление OpenSSH 5.8 с исправлением недоработки, связанной с безопасностью
  5. OpenNews: Релиз OpenSSH 5.7
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/31686-openssh
Ключевые слова: openssh
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (66) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 16:28, 06/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Жаль, что не добавили шифр Вернама. При современных дешёвых флешках и огромных дисках на сервере пора бы.
     
     
  • 2.12, Aquarius (ok), 17:48, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    это тот, что еще называют одноразовым блокнотом?
    а как обеспечить передачу ключа?
    только при физическом доступе к серверу не годится - повторно использовать нельзя, необходимо дополнительно хранить на обеих сторонах информацию о том, какая часть ключа использована, передавать через то же защищенное соединение бессмысленно, даже со сжатием
    IMHO, в чистом виде он практически неприменим вне зависимости от объемов носителей
     
     
  • 3.39, Аноним (-), 08:41, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Без доступа ни какой ключ не передать Или нужен другой, заведомо надёжный канал... большой текст свёрнут, показать
     
     
  • 4.67, Аноним (-), 00:21, 09/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Без доступа ни какой ключ не передать.

    Диффи-хеллман нервно покуривает в сторонке.

     
  • 3.40, user (??), 08:47, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >в чистом виде он практически неприменим вне зависимости от объемов носителей

    А мужики то и не знают...

     
     
  • 4.49, Аноним (-), 12:39, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Какие мужики? Им кто-то всерьез пользуется?
     

  • 1.2, Аноним (-), 16:35, 06/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что-то все монструознее и монструознее. Эх, забыли они выкладки Берштейна, что безопасная программа должна быть маленькой и простой :(.

    В результате - в треде о взломе кернелорга была ссыль на форум где перец утверждал что ему вломили через 0day в openssh. С тех пор 0day в openssh никто вроде как не чинил. Все это как-то не внушает особого оптимизма.

     
     
  • 2.3, Аноним (-), 16:41, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Имхо, продукции OpenBSD вообще пока лучше не доверять. Они еще по итогам аудита IPSec не отчитались (когда непосредственные участники событий заявили о внедрении туда бэкдора по заказу американских спецслужб). Тогда все ограничилось отмазками "да мы этих ребят вообще в первый раз видим". А результаты аудита так и не огласили. То ли его так и не провели (потому что некому), то ли все-таки нашли что-то и теперь отмалчиваются.

    Я уж не говорю о том, что в их оси, которая позиционируется как супер-защищенная, нет даже элементарного мандатного контроля доступа.

     
     
  • 3.10, Аноним (-), 17:20, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не о чем отчитываться, вот и не отчитались. "OpenBSD code audit uncovered bugs, but no evidece of backdoor." Отмазок "в первый раз видим", кстати, никогда не было. Сам придумал?
     
  • 3.55, Аноним (-), 15:41, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Имхо, продукции OpenBSD вообще пока лучше не доверять.

    Пф-ф-ф, делов то... напиши свою реализацию SSH и пользуйся на здоровье.. а OpenBSD'шной ни-ни.. низя

     
  • 2.9, all_glory_to_the_hypnotoad (ok), 17:02, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    а что такое 0day в openssh? Если гондурас тебя беспокоит, то нужно его просто почесать
     
     
  • 3.15, Аноним (-), 18:12, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +5 +/
    По мнению того перца - некая дырка про которую публично не известно но которая п... большой текст свёрнут, показать
     
     
  • 4.21, Аноним (-), 21:34, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >С учетом наворачивания г0вен и превращения шелла в какой-то странный швейцарский нож с 120 лезвиями - вероятность дыр все больше и больше растет в каждой версии.

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

     
     
  • 5.50, Харитон (?), 13:13, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вывод: Идеальная по безопасности программа - размером в 1 бит! Да и то многовато...

    Как говорил когда-то С.Лем.
    Для малых процессоров(имеется в виду с малым набором операций например RISC) нужно писать большую программу для выполнения одного и той же задачи, что и для больших процессоров (у которых есть расширения и куча операций на все случаи жизни:видеакселератор, аудиоакселератор...).
    Отсюда вывод: чем больше мы делаем процессор, тем меньше программу надо писать. В идеале бесконечно большой процессор сможет выполнять задачи без программы и наоборот. Если написать бесконечно большую программу, то процессор не понадобится (эдакий вариант алгоритмического языка в конце 80-х в школах СССР ))) )...


     
     
  • 6.59, Аноним (-), 18:57, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В бесконечно большом процессоре, даже если забыть что он никуда не умещается, будет бесконечное количество багов :P. Хакеру не принципиально, будет ли проблема в программе или в самом процессоре. К тому же заменить программу - проще чем процессор. А у бесконечно большой программы есть одна проблема: она будет загружаться бесконечное время :P.
     
  • 5.61, PereresusNeVlezaetBuggy (ok), 21:44, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >>С учетом наворачивания г0вен и превращения шелла в какой-то странный швейцарский нож с 120 лезвиями - вероятность дыр все больше и больше растет в каждой версии.
    > Ну, чисто теоретически... взрывное разрастание функциональности и превращение простой,
    > но безопасной программы в развесистую блоатварь, крайне тяжелую для аудита -
    > может вполне целенаправленно прикрывать внедрение бэкдоров. Тем более, что репутация у
    > проекта подмочена.

    Аноним на Опеннете вещает великую правду об OpenSSH, выясненную безымянным "перцем" на не пойми каком форуме - правда, безо всякой конкретики, ну да это же мелочи.

     
  • 2.60, PereresusNeVlezaetBuggy (ok), 21:43, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Что-то все монструознее и монструознее. Эх, забыли они выкладки Берштейна, что безопасная
    > программа должна быть маленькой и простой :(.

    Вы исходники OpenSSH сначала посмотрите (а ещё лучше, сравните с чем-то аналогичным), а потом говорить об монструозности. Разработчики шагают в ногу со временем, только и всего. Описываемые изменения уложились в сравнительно небольшой объём кода.

    > В результате - в треде о взломе кернелорга была ссыль на форум
    > где перец утверждал что ему вломили через 0day в openssh.

    Угу. Конечно, проще предположить, что виноваты авторы программы, а не тот, кто за своими ключами не уследил.

    > С тех пор 0day в openssh никто вроде как не чинил. Все
    > это как-то не внушает особого оптимизма.

    Чтобы что-то починить, надо сначала это что-то сломать.

     
     
  • 3.65, Аноним (-), 01:00, 08/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Разработчики шагают в ногу со временем, только и всего.

    Ах вот как это называется. Значит, и разработчики всяких Nero Burning Rom тоже просто шагают в ногу со временем, превращая простую писалку дисков в ОС.

    >Конечно, проще предположить, что виноваты авторы программы

    Если авторы программы "идут в ногу со временем" - такое предположение напрашивается сразу.

    >Чтобы что-то починить, надо сначала это что-то сломать.

    "Все уже украдено до вас"(с)

     
     
  • 4.66, PereresusNeVlezaetBuggy (ok), 02:54, 08/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>Разработчики шагают в ногу со временем, только и всего.
    > Ах вот как это называется. Значит, и разработчики всяких Nero Burning Rom
    > тоже просто шагают в ногу со временем, превращая простую писалку дисков
    > в ОС.

    А вы ничего не путаете? OpenSSH не проигрывает музыку, не записывает диски (в Ahead могут спать спокойно), не содержит браузер на Webkit и даже (о, ужас!) не умеет рисовать граффити ВКонтакте. Он выполняет свои функции - безопасное подключение к другим компьютерам и сетям. Какие конкретно части OpenSSH вы считаете неуместными?

    >>Конечно, проще предположить, что виноваты авторы программы
    > Если авторы программы "идут в ногу со временем" - такое предположение напрашивается
    > сразу.

    Опять-таки, факты в студию. То, что само напрашивается, далеко не всегда соответствует истине.

    >>Чтобы что-то починить, надо сначала это что-то сломать.
    > "Все уже украдено до вас"(с)

    "Факты, сестра, факты"

     
     
  • 5.68, Аноним (-), 00:24, 09/09/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А вы ничего не путаете? OpenSSH не проигрывает музыку, не записывает диски
    > (в Ahead могут спать спокойно), не содержит браузер на Webkit и
    > даже (о, ужас!) не умеет рисовать граффити ВКонтакте.

    Вместо этого оно изображает впн (довольно паршиво), редиректит порты (почему это должен делать шелл?), выступает файлсервером (блин, это правда все еще шелл?) и что там я еще забыл?! А потом со всей этой фигней  мы попытаемся взлететь...

     
     
  • 6.69, PereresusNeVlezaetBuggy (ok), 01:43, 09/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> А вы ничего не путаете? OpenSSH не проигрывает музыку, не записывает диски
    >> (в Ahead могут спать спокойно), не содержит браузер на Webkit и
    >> даже (о, ужас!) не умеет рисовать граффити ВКонтакте.
    > Вместо этого оно изображает впн (довольно паршиво),

    Для решения на скорую руку (когда некогда поднимать IPSec/OpenVPN/etc.) вполне хватает. Впрочем, не суть.

    > редиректит порты (почему это должен
    > делать шелл?), выступает файлсервером (блин, это правда все еще шелл?) и
    > что там я еще забыл?! А потом со всей этой фигней
    >  мы попытаемся взлететь...

    Во-первых, вы уж тогда придирайтесь не к OpenSSH, а к IETF. Которые под названием Secure Shell понимают как раз вышеперечисленное. ;)

    Во-вторых, будьте внимательны: я специально написал, что обеспечивает безопасный доступ к другим компьютерам и сетям. С этим набором функций SSH-реализации (в первую очередь нынче это как раз OpenSSH) справляются, на большее не претендуют. Суть претензий слабо понятна, так как все приведённые аналогии, мягко говоря, притянуты за уши.

     

  • 1.4, iZEN (ok), 16:43, 06/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кстати, никто не в курсе, почему из CUPS 1.4.8 выпилили поддержку GnuTLS и перешли на OpenSSL?
     
     
  • 2.7, Andrey Mitrofanov (?), 16:45, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну, уж ты-то должен понимать: Эппле, GPLv3... Ага? ;->
     
  • 2.8, Аноним (-), 16:46, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Apple не любит GPL.
     
     
  • 3.11, Anonymouse (?), 17:41, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Предположим что ты прав. Но! :
    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.

    И .... ?

     
     
  • 4.13, Andrey Mitrofanov (?), 17:54, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И .... ?

    Эппле не разрабатывала и не выбирала лицензию для. Очень удачно купили фирму вместе продуктом и разработчиком, а _потом_ внизапна узнали о "неудобной" лицензии --- вот теперь елозят на гребешке. И очень, ооооочень "пужаются" LGPLv3. То есть GPLv2 они, конечно, тоже пужаются -- только деться никуда не могут.

    Слабаки же.

     
     
  • 5.14, Andrey Mitrofanov (?), 18:02, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Эппле не разрабатывала
    >елозят на гребешке. И очень, ооооочень "пужаются" LGPLv3.

    Хотя, возможно дело в несовместимости GPLv2(&LGPLv2) _ровно_ со стороны CUPS c LGPLv3+ со стороны GnuTLS

    100 * Version 3.0.0 (released 2011-07-29)
    124 ** libgnutls: license upgraded to LGPLv3

    > Слабаки же.

     
  • 5.26, ананим (?), 23:37, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Женна - дизайнер.
    Хп к88650дн - мак не рвбртвет, линух - отлияно.
    вставить дрова из линуха в мак не удалась.
    Купс.
    бодяге уже год. Поддкржка в курсе.
     
     
  • 6.28, Аноним (-), 00:10, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У кого-то пятница начинается уже во вторник...
     
     
  • 7.71, ананим (?), 18:29, 11/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    и к чему ты это написал?
    или как обычно - если нечего сказать, то к орфографии прицепишься?
     
  • 6.30, Аноним (-), 00:33, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > бодяге уже год. Поддкржка в курсе.

    Да никто и не сомневался что у проприетарщиков техподдержка замечательная.

     
  • 4.17, Аноним (-), 19:33, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >И .... ?

    Ваш вопрос имел бы смысл, если бы Apple сама разрабатывала CUPS. Но она его купила уже готовым, так что изменить лицензию было уже нереально.

    Наверняка, если бы существовали достойные аналоги под проприетарно-дружественными лицензиями (BSD-like, etc), купили бы их. Но таких, увы, не было и нет.

     
     
  • 5.41, Аноним (-), 08:49, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >если бы существовали аналоги под лицензиями BSD, купили бы их.

    Как? И зачем?

     
     
  • 6.44, Аноним (-), 11:38, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Как?

    Точно так же, как купили CUPS.

    >И зачем?

    И ровно с теми же целями.

     
  • 2.16, Аноним (-), 18:12, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Кстати, никто не в курсе, почему из CUPS 1.4.8 выпилили поддержку GnuTLS
    > и перешли на OpenSSL?

    Казалось бы при чем здесь Луж^W SSL? :)

     

  • 1.5, Аноним (-), 16:43, 06/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    mindrot (домен по ссылке) - это что за министерство? :)
     
  • 1.6, Аноним (-), 16:45, 06/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >В будущем планируется обеспечить поддержку таких механизмов, как Capsicum

    Не понял, это альтернативная реализация TrustedBSD или просто экстенсивное расширение POSIX capabilities?

    > и изолированных пространств имен в Linux (pid/net namespaces).

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

     
     
  • 2.18, Аноним (-), 20:08, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > LXC, конечно, хорошо, но оно ограничивает не перечень системных вызовов, а лишь
    > область их действия.

    Лишь? Вот например rm -rf /* на моем сервере от рута - хреново. Для меня. А на чьем-то еще - пофигу. Для меня. А ведь это всего-то ограничение области действия системных вызовов :)

     
     
  • 3.19, Аноним (-), 20:13, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема ограничения области действия в том, что теоретически возможен путь косвенного воздействия на объекты, находящиеся за пределами зоны ограничения. Особенно при отсутствии ограничений на syscalls.
     
     
  • 4.20, Аноним (-), 21:07, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Проблема ограничения области действия в том, что теоретически возможен путь косвенного
    > воздействия на объекты, находящиеся за пределами зоны ограничения. Особенно при отсутствии
    > ограничений на syscalls.

    Практически однако я не слышал о, допустим, взломе  хоть тех же openvz-контейнеров. Хотя это на каждом первом хостинге понатыкано уже немало лет.

     
     
  • 5.22, Аноним (-), 21:38, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Практически однако я не слышал о, допустим, взломе  хоть тех же
    > openvz-контейнеров. Хотя это на каждом первом хостинге понатыкано уже немало лет.

    Многие ядерные (не юзерспейсные, это важно) дыры на local root позволяют обойти контейнерную изоляцию. Прецеденты были (например, кое-кого повскрывали в честь модуля tun). Видимо, те, на чей опыт вы опираетесь, являются неуловимыми Джо.

     
     
  • 6.23, all_glory_to_the_hypnotoad (ok), 22:03, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    перехват системных вызовов от этого тоже не спасёт
     
     
  • 7.24, Аноним (-), 22:11, 06/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > перехват системных вызовов от этого тоже не спасёт

    Зависит от, имхо. Если проблемный сискол до ядра вообще не долетит - то почему бы и нет? :)

     
     
  • 8.29, Аноним (-), 00:13, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Долететь-то он, может, и долетит, но не туда, куда хотелось Не в уязвимую мякот... текст свёрнут, показать
     
  • 8.42, all_glory_to_the_hypnotoad (ok), 10:17, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    потому что сисколов всего несколько десятков, большая часть всего функционала ре... текст свёрнут, показать
     
     
  • 9.46, Аноним (-), 11:43, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    С вашей логикой, и POSIX capabilties должны быть абсолютно бесполезны Однако он... текст свёрнут, показать
     
     
  • 10.63, all_glory_to_the_hypnotoad (ok), 23:09, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    posix caps ы не решают проблем качества кода, а именно по этой причине в большин... текст свёрнут, показать
     
  • 9.51, Аноним (-), 13:29, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Расскажите это парням с codepad org Они это не знают и поэтому у них работает з... большой текст свёрнут, показать
     
     
  • 10.64, all_glory_to_the_hypnotoad (ok), 23:18, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    И как, много пользы получил выполнения кода в такой поеразнной виртуалке Когда... текст свёрнут, показать
     
  • 9.62, brother anon (?), 22:41, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    setuid 0 ... текст свёрнут, показать
     
  • 7.27, Аноним (-), 00:09, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >перехват системных вызовов от этого тоже не спасёт

    Да неужели? А как тогда, по-вашему, обычно эксплуатируются подобные дыры? Воздушно-капельным путем?

     
     
  • 8.43, all_glory_to_the_hypnotoad (ok), 10:18, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    смотри комент выше... текст свёрнут, показать
     
  • 6.32, Аноним (-), 00:46, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Многие ядерные (не юзерспейсные, это важно) дыры на local root позволяют обойти
    > контейнерную изоляцию. Прецеденты были (например, кое-кого повскрывали в честь модуля
    > tun). Видимо, те, на чей опыт вы опираетесь, являются неуловимыми Джо.

    В принципе - да, это возможно. Если совсем ссыкотно - можно и более тяжеловесный виртуализатор использовать. Там даже проломленное ядро виртуалки - как бы не страшно. Правда скорость в отместку местами просядет, увы.


     
  • 6.35, Michael Shigorin (ok), 01:51, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Многие ядерные (не юзерспейсные, это важно) дыры на local root

    В смысле local kernel?

     
     
  • 7.45, Аноним (-), 11:40, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > В смысле local kernel?

    Нет, именно выполнение кода с повышенными привилегиями. У локальных досов своя специфика, которая требует отдельного обсуждения.

     
     
  • 8.53, Michael Shigorin (ok), 13:52, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Не, ну dos всяко kernel была пара раз припоминается коркомёт и будто kspl... текст свёрнут, показать
     
     
  • 9.54, Аноним (-), 15:19, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    local dos может быть и через ядро, примеров куча почти каждую недели в линуксе ... текст свёрнут, показать
     
  • 2.33, xxx (??), 01:22, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Не понял, это альтернативная реализация TrustedBSD или просто экстенсивное расширение POSIX capabilities?

    Хз, я не фанат безопасности, погляди: http://www.cl.cam.ac.uk/research/security/capsicum/

     
     
  • 3.47, Аноним (-), 11:47, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по тамошнему куцему описанию, это такое недоLXC.
     

  • 1.25, фыг (?), 22:38, 06/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Когда очепятки пальцев можно будет как ключ юзать?
     
     
  • 2.31, Аноним (-), 00:43, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Когда очепятки пальцев можно будет как ключ юзать?

    Думаю что никогда - надежность этого метода применительно к доступу к удаленным серверам получается крайне хилая. К тому же не понятно что делать если хаксор угнал снимки пальцев и подсовывает их внаглую как якобы картинку со сканера.

     
     
  • 3.38, asu (?), 08:07, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Отпечатки как картинки хранят только труодлфагименты.
    В системах биометриии они пересчитываются в хэш.
     
     
  • 4.48, Аноним (-), 12:35, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >В системах биометриии они пересчитываются в хэш.

    Перед этим необходимо довольно трудоемкое преобразование. Потому что хэшировать обычный снимок - заведомый идиотизм. Простая аналогия: если сфоткать одного и того же человека два раза подряд с перерывом в полсекунды, даже если и он, и фотограф постараются не двигаться - все равно с вероятностью 99% даст различные хеши фоток. Для использования в биометрии, снимки нужно обработать и выделить некий каркас, нечувствительный к случайным помехам.

     
  • 4.52, Аноним (-), 13:30, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > В системах биометриии они пересчитываются в хэш.

    И что помешает хаксору высылать этот же хеш "как будто бы только что со сканера"? Кроме того, учитывая дубовое разрешение сканера и огрубления из-за допусков на неточности (иначе сам владелец хрен проавторизуется из-за несовпадений) - есть опасения что сие могут попросту сбрутфорсить.

     
  • 4.58, Аноним (-), 18:52, 07/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > В системах биометриии они пересчитываются в хэш.

    Да похрен. Пароль в случае кражи хотя-бы сменить можно. А что делать если сопрут хэш?

     
  • 3.70, stimpack (?), 08:41, 10/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Когда очепятки пальцев можно будет как ключ юзать?
    > Думаю что никогда - надежность этого метода применительно к доступу к удаленным
    > серверам получается крайне хилая. К тому же не понятно что делать
    > если хаксор угнал снимки пальцев и подсовывает их внаглую как якобы
    > картинку со сканера.

    Угнать можно и закрытый ключ, если получится. Здесь разница лишь в распространенности. Руками вы касаетесь за множество вещей. Отпечатки можно снять, просто забрав после ваш стакан в кафе. Закрытый же ключ лежит в одном месте и менее легкодоступен, чем отпечатки.

    А генерировать закрытый ключ с отпечатков или с /dev/random - разницы нет, все равно серверы получат только открытый, поэтому уровень защиты В СЕТИ одинаковый.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру