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 [^] [^^] [^^^] [ответить]
| +/– |
>в чистом виде он практически неприменим вне зависимости от объемов носителей
А мужики то и не знают...
| |
|
|
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'шной ни-ни.. низя
| |
|
|
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?
| |
|
|
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дн - мак не рвбртвет, линух - отлияно.
вставить дрова из линуха в мак не удалась.
Купс.
бодяге уже год. Поддкржка в курсе.
| |
|
|
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.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). Видимо, те, на чей опыт вы опираетесь, являются неуловимыми Джо.
| |
|
|
7.24, Аноним (-), 22:11, 06/09/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> перехват системных вызовов от этого тоже не спасёт
Зависит от, имхо. Если проблемный сискол до ядра вообще не долетит - то почему бы и нет? :)
| |
|
8.29, Аноним (-), 00:13, 07/09/2011 [^] [^^] [^^^] [ответить] | +/– | Долететь-то он, может, и долетит, но не туда, куда хотелось Не в уязвимую мякот... текст свёрнут, показать | |
|
9.46, Аноним (-), 11:43, 07/09/2011 [^] [^^] [^^^] [ответить] | +/– | С вашей логикой, и POSIX capabilties должны быть абсолютно бесполезны Однако он... текст свёрнут, показать | |
9.51, Аноним (-), 13:29, 07/09/2011 [^] [^^] [^^^] [ответить] | +/– | Расскажите это парням с codepad org Они это не знают и поэтому у них работает з... большой текст свёрнут, показать | |
|
|
7.27, Аноним (-), 00:09, 07/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
>перехват системных вызовов от этого тоже не спасёт
Да неужели? А как тогда, по-вашему, обычно эксплуатируются подобные дыры? Воздушно-капельным путем?
| |
|
6.32, Аноним (-), 00:46, 07/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Многие ядерные (не юзерспейсные, это важно) дыры на local root позволяют обойти
> контейнерную изоляцию. Прецеденты были (например, кое-кого повскрывали в честь модуля
> tun). Видимо, те, на чей опыт вы опираетесь, являются неуловимыми Джо.
В принципе - да, это возможно. Если совсем ссыкотно - можно и более тяжеловесный виртуализатор использовать. Там даже проломленное ядро виртуалки - как бы не страшно. Правда скорость в отместку местами просядет, увы.
| |
|
7.45, Аноним (-), 11:40, 07/09/2011 [^] [^^] [^^^] [ответить]
| +/– |
> В смысле local kernel?
Нет, именно выполнение кода с повышенными привилегиями. У локальных досов своя специфика, которая требует отдельного обсуждения.
| |
|
|
9.54, Аноним (-), 15:19, 07/09/2011 [^] [^^] [^^^] [ответить] | +/– | local dos может быть и через ядро, примеров куча почти каждую недели в линуксе ... текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
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 - разницы нет, все равно серверы получат только открытый, поэтому уровень защиты В СЕТИ одинаковый.
| |
|
|
|