LINUX.ORG.RU

SSH buffer overflows


0

0

Новость от 16 декабря - но может кто не слышал - нашли кучу дыр в реализациях SSH протокола

http://www.iss.net/security_center/st...
http://www.iss.net/security_center/st...
http://www.iss.net/security_center/st...
http://www.iss.net/security_center/st...

>>> http://www.iss.net/security_center/static/10868.php

anonymous

Проверено: green

я не въезжаю -- как так может получиться что разные коды, написанные разными командами имеют одни и те же дыры. А в openssh эти дыры есть?

dilmah ★★★★★
()

так что - ежели стоит OpenSSH версии 2.9 и выше - можно спать спокойно? А то у меня и на Солярисе спарк и на линукс х86 он установлен.

anonymous
()

так что - ежели стоит OpenSSH версии 2.9 и выше - можно спать спокойно? Э, родной, только IP адресов никому не говори, Ok?

Shadow ★★★★★
()

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

anonymous
()

Бьерн Страуструп про передаче строки в функцию рекомендует всегда делать проверку на длину.

К сожалению, не все чтят классиков. Думаю, уже давно настало время встроить в C++ механизм такой проверки. Хотябы на уровне среднестатистического параметра, который хранится токо в памяти в виде члена данных.

Пивка сейчас попьем и после рождества дадим боле крутое приложение :))

coffee_break
()
Ответ на: комментарий от coffee_break

coffee_break (*) (2002-12-24 20:26:10.795):
> Бьерн Страуструп ... рекомендует...
> ... К сожалению, не все чтят классиков.
БЛИН!
Классики - они тоже разные бывают.

Я признаЮ, что Бьерн Страуструп - классик, никуда не денешься от фактов.
Но вот ЧТИТЬ его я категорически отказываюсь.

> ...настало время встроить в C++ механизм...
Слава Богу, не все так думают.

Я уж, лучше, буду программы без ошибок писАть. Как-то ...надежнее :)

Die-Hard ★★★★★
()

Если программировать на C++, а не на C, то такая проверка не понадобится. Другое дело, что бинарник получится толще и неповоротливее.

anonymous
()

> Я уж, лучше, буду программы без ошибок писАть. Как-то ...надежнее :)

Совсем без ошибок? А насколько сложны эти ваши программы, как много в них кода? Может вам на премию Тьюринга заявку подать, а то такой талант пропадает?

anonymous
()

2anonymous (*) (2002-12-24 19:14:52.406):

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

Да, этот вопрос уже исследован вдоль и поперёк. Происходит это
в том числе из-за культуры программирования и элементарного
непонимания того, как работают всякие там strncpy, strncat.
Именно из-за этого, например, Theo de Raadt инициировал создание
их заменителей: strlcpy и strlcat.

badger
()

> то вот насчет первого - это получается, что у многих программеров
> просто культура программирования такая (либо отсутствие таковой) -
> длину буфера для данных не проверять.

Не всегда дело в культуре, иногда в организации проекта. Например кто-
то написал модуль внутри которого рекурсивная функция принимающая
(void *) и вызываемая лишь изнутри этого модуля. Посколько она
внутренния, её создатель решает, что точно знает кто и как её будет
вызывать - лишь другии функции того же модуля которые написаны им же.
Он делает проверку длины лишь в этих фунуциях полагая, что внутри
рекурсии такая проверка или передача длины вторым параметром будет
слишком расточительна. Затем человек долго не возвращается к проекту
или туда приходит кто-то совсем другой.
Тут то и начинается самое интересное...

anonymous
()

Эта... Теоретики.. А разницу между контрактным и защитным программированием вы знаете??? Луговского на вас нет, sic!

Bacek
()

Bacek, а ты не умничай, ты поясни аргументированно, ссылками или еще как... и всем лучше будет :)

заранее спасибо.

anonymous
()

blin, takuu novost' nado srazu rasskazyvat' ... u nas kak raz professora otzenki za exameny v komp'uter zagonyaut ... hehe

anonymous
()
Ответ на: комментарий от anonymous

>так что - ежели стоит OpenSSH версии 2.9 и выше - можно спать спокойно?

Э, друг, тебе не меньше, чем 3.4 надо ставить. Или айпешник скажи, мы поставим :)

anonymous
()
Ответ на: комментарий от anonymous

>так что - ежели стоит OpenSSH версии 2.9 и выше - можно спать спокойно?

Э, друг, тебе не меньше, чем 3.4 надо ставить. Или айпешник скажи, мы поставим :)

anonymous
()

А патчи, патчи где?
Ну не люблю я OpenSSH, нравится мне больше ssh тот который от www.ssh.com (3.2.2). И клиент у него приятный, да и сервер тоже не поделка программиста.

anonymous
()

Кстати, разработчики SSH от www.ssh.com не подтвердили существование дырки, так что патчей не будет :)

anonymous
()

ндяя... давно пора на Це++ переползать. я еще в начале 90х нарисовал класс string + потомки всякие и голова не болит. отличие от массива лишь в добавке int lenght и использовании этой переменной когда нужно. доступ к массиву выполнен инлайновыми функциями, так что разницы с Це никакой, если компиллятор нормальный.

SG

anonymous
()

давно пора на kerberos уползти и забыть про это глюкало

dsa
()

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

CybOrc
()
Ответ на: комментарий от anonymous

Насчет "без ошибок" можно погутарить. Это когда сначала программку в уме прокручиваешь, а потом уже к клавиатуре бежишь сломя голову. Если все наоборот, то получается что-то вроде WINDOWS-а или еще хуже. Новиков Владимир.

anonymous
()

Какая версия openSSH не подвержена сему глюку? Чтоб спать спокойно и не дергаться.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.