Переполнение буфера в CVS

наверное, я что-то сурово не понимаю в securitylab.ru, но где же по ссылке подробное описание проблемы? что, где, когда etc.

// wbr

>...ивании сервиса. Подробности неизвестны.

>...полнить произвольный код на целевой системе. Подробности неизвестны.

>>>>Подробности

lol :)

> Подробности неизвестны.

Приметы преступников уточняются :)

Кажется, цивилизованные люди перешли на svn? Xfce тот же.

Долбанный C. Вот уж казалось бы, такие приложения самое то на безопасных языках писать. Пусть бы даже на ML-языке.

я могу, конечно, ошибаться, а проверять меня ломает, но имно cvs накалякан на modula2 :).

> я могу, конечно, ошибаться, а проверять меня ломает, но имно cvs накалякан на modula2 :).

и вы конечно же ошибаетесь :)

// wbr

Да не, вроде C. Я помню как-то что-то в исходниках смотрел...

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

C++ + STL?

https://ccvs.cvshome.org/servlets/NewsItemView?newsItemID=141

кому ругаться, а кому перекомпиляться.. :(

Ну не нравится вам GNU CVS vulnerabilities, так используйте OpenCVS.
Делов-то .....

На модуле написан cvsup.

Думается мне, что это ещё та головная боль переводить крупный проект с cvs на svn например.

>C++ + STL?

Не, там тоже безопасностью надо явно озаботиться. Например, vector::operator[] проверки не производит (хотя и вреда, наверное, будет чуть меньше - буффер все-таки не на стеке, а в куче).

Дык если б дело только в CVS было. Ведь это нормой стало, постоянные переполнения буфера. Вон зайди на debian.org и подивись.

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

Интересно, а кто-нибудь вообще делал таксономию существующих типов ошибок с предложением механизмов решения по каждому таксону?

Например, переполнение буфера -> проверки границ массивов; небезопасное создание временного файла -> паттерн создания временного файла, высокоуровневые механизмы создания временного файла; ошибки, связанные с правами доступа -> формальные модели безопасности, и.т.д.

Вот интересно, когда на нашем флеймообразующем сайте разгорится первая битва вокруг фразы "CVS is dead"...

подожди: гконф ещё не похоронили

"Мюллер бессмертен" (с) Хоронить gconf на ЛОРе будут, наверное, вечно - и уж явно еще долго будут пинать его бездыханное тело после того как он и правда того...:)

>Ведь это нормой стало, постоянные переполнения буфера

Нормой стало НАХОДИТЬ переполнение буфера. Круг проблем однако четко очерчен - т.е. есть четкие рекомендации ( не паттерны - патерны для придурков ) как делать ненадо, и как надо, чтобы избежать этой ошибки. С здесь ниразу не причем, а плохому танцору известно что мешает...

>Не, там тоже безопасностью надо явно озаботиться. Н

И это есть гуд. Безопасностью нужно озабочиваться всегда.

>Нормой стало НАХОДИТЬ переполнение буфера.

Ну я том и говорю.

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

Я понимаю, все сразу умные становятся, когда речь о высших материях идет :) Но best practices (они же - паттерны), на мой взгляд, не помешают. Не все такие умные, как ты. Я специально за дырами не слежу, но помоему часто повторяются ошибки одних и тех же типов (как правило, специфичные для языка).

Например, для шелловских скриптов часто встречается "небезопасная работа с временными файлами", причем, насколько я понимаю, как правило повторяется одна и та же ошибка.

>С здесь ниразу не причем, а плохому танцору известно что мешает...

Что не при чем?

>И это есть гуд. Безопасностью нужно озабочиваться всегда.

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

Я имел ввиду то, что приходится думать о "низменных" проблемах типа переполнения буффера. Все-таки, хочется выражать свои мысли на чем-то более высокоуровневым.

Однако я не отрицаю, что "нечто высокоуровневое" вполне можно разработать и на C++. Например, если пользоваться строками std::string, то переполнение все же сложнее получить (если, конечно, руками по ним не лазить), чем в случае C-шных строк.

>Я понимаю, все сразу умные становятся, когда речь о высших материях идет :)

НО Я НЕ ПОНИМАЮ ЭТОГО. Что высшими материями нынче принято называть ер корректное использование например функций работы со строками типа "используйте strncpy вместо strcpy" и тому подобное? Или типа "избегайте совместного использования signed и unsigned типов"? Или "забудьте про существование scanf" и т.д. и т.п. Так любой мало-мальски грамотный человек без труда усвоит эту муйню без всяких там паттернов.

>Что не при чем?

Язык программирования C.

>Язык программирования C.

Хотя конечно на Ada такую ситуацию (переполнение буфера) получить просто невозможно...

>Хотя конечно на Ada такую ситуацию (переполнение буфера) получить просто невозможно...

О чем и речь. Можно долго рассуждать про "мало-мальски грамотных людей", но де-факто мы имеем постоянные проблемы, связанные с переполнением буферов.

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

>Например, vector::operator[] проверки не производит а vector::at() производит. Т.е. безопасные механизмы есть. Конечно о безопасности стоит особенно заботится. Но все же C++ + STL + строки + потоки ввода/вывода предоставляют более безопасные инструменты, чем чистый C.

> Кажется, цивилизованные люди перешли на svn? Xfce тот же.

Такое же фуфло. Такой с позволения сказать софт называется "bloatware". А xfce что? Идеал секьюрности и правильности кода? Такая ж хрень. Я понимаю ещё, если бы сказали про arch/tla.

> Хотя конечно на Ada такую ситуацию (переполнение буфера) получить просто невозможно...

Да что вы такое говорите... Для любителей Ада всегда есть убойный пример. На Ada сделана самая дорогая в истории программирования ошибка. Стоимость ошибки - 8.5 млрд.долл. Всякие там и Си/С++ отдыхают. Падение ракеты Arian 5 в 1996-ом году. Припоминаем? Операция по преобразованию данных из 64-разрядного числа с плавающей запятой в 16-разрядное знаковое целое вызвала исключение Operand Error. Сонвертируемое значение оказалось члишком велико, чтобы поместиться в 16-bit signed integer... Вот вам и защита от переполнения... В результате накрылись медным тазом 10 лет работы и труд тысяч людей.

> Интересно, а кто-нибудь вообще делал таксономию существующих типов ошибок с предложением механизмов решения по каждому таксону?

http://en.wikipedia.org/wiki/Category:Programming_bugs

> Операция по преобразованию данных из 64-разрядного числа с плавающей запятой в 16-разрядное знаковое целое вызвала исключение Operand Error.

ошибка была в том, что они взяли часть кода предназначенного для предыдущей модели ракеты, для которого было _доказано_ что 16-то разрядов достаточно и сдедовательно все проверки во время исполнения можно спокойно отключить, при этом не сделав никаких поправок на различия моделей.

и это всё-таки другой тип ошибки, нежели переполнение буфера.

> и это всё-таки другой тип ошибки, нежели переполнение буфера.

Какая нафиг разница когда речь идёт о безопасности? Другой тип или не другой... Понятно, что они не идентичны. Но и то, и другое - ошибка программеров. И могучий язык Ada от этой ошибки не уберёг.

в данном случае речь идёт об ответе на:

> Хотя конечно на Ada такую ситуацию (переполнение буфера) получить просто невозможно...

как получить на Ада ошибку переполнения буфера ты не показал.

используя haskell, ты банально такой программы не напишешь ;)

Это демагогия. Рассматривается определенный тип ошибок, переполнения буфера. Про конвертацию чисел речь пока не идет, хотя и эта ошибка может вылавливаться статически. Хотя бы даже формальным доказательством правильности программы.

>используя haskell, ты банально такой программы не напишешь ;)

Думаю, напишу. Выглядеть она может будет и страшно, работать медленно, но думаю все же напишу :) Haskell я так, для примера привел. Это может быть любой другой язык: Clean, OCaml, Python, Scheme, Java, VB.NET, Bash scripts, Tcl. Если я не ошибаюсь, ни в одном из них получить дыру в безопасности переполнением буфера нельзя. Но почему-то для прикладного софта постоянно выбирают язык C.

Очень интересно!

Еще бы статистика была бы, хотя бы по проектам Open Source. С указанием типа ошибки, вероятности ее появления, корелляции с языком, и т.д.

Целая тема для курсовой работы! :)

openwall

grsec

и с памятью и указателями там нормально тоже невозможно работать

короче ты предлагаешь уродовать нормальный язык только потому что находятся идиоты неумеющие научится простым вещам? знаешь куда такая философия заводит?

которая будет абсолютно бесполезна без указания IQ использующего язык

>openwall, grsec

Дык это устранение следствия, а не причины.

>короче ты предлагаешь уродовать нормальный язык только потому что находятся идиоты неумеющие научится простым вещам? знаешь куда такая философия заводит?

C - нифига не нормальный язык для прикладного обеспечения. И практика это подтверждает. :)

>которая будет абсолютно бесполезна без указания IQ использующего язык

Все равно. Иначе это будет рассмотрение сферического коня в вакууме. Хотя статистика несомненно должна быть релевантной, а не собранной по 10 проектам Васи Пупкина.

>релевантной

Тьфу, репрезентативной :)

> знаешь куда такая философия заводит?

Куда?

практика говорит что я использую кде еще с ветки 2.х

так что перестаньте выдумывать

маздай видел? вот то-то

"сделай интерфейс понятным и тупому, и только тупой захочет им пользоваться"

>И могучий язык Ada от этой ошибки не уберёг.

Бля урод! Сказали тебе умные люди ПОЧЕМУ ЭТО ВЫЛЕЗЛО. А ты чмо думаеш на чем пишут авионику, всякие системы управления стрельбой, системы управления ядерными реакторами и т.п. хуйню, причем не только сдесь, но даже в совке? на жабе или на сях? Ась? НА Ada.

>практика говорит что я использую кде еще с ветки 2.х

>так что перестаньте выдумывать

Что-то я не понял логики. Кто ж спорит, что можно вообще хоть на ассемблере писать или на машине Тьюринга. Причем это даже работать будет. Вопрос-то не в этом.

>маздай видел? вот то-то

>"сделай интерфейс понятным и тупому, и только тупой захочет им пользоваться"

И как это относится к безопасным языкам? Приведу в пример Clean. Или пусть это будет OCaml. Оба имеют довольно шустрые реализации, т.е отмазки типа "медленные" без тестов не поканают. Ты хочешь сказать, что они по сравнению с C имеют "интерфейс понятный и тупому"?

Вот как раз C - это и есть очень тупой и простой язык, да еще и с грабельками. :)

> C - нифига не нормальный язык для прикладного обеспечения. И практика это подтверждает. :)

та канечна..

$ uname -a
NetBSD NBSD1 3.99.3 NetBSD 3.99.3 (GENERIC-$Revision: 1.628 $)
$ cd /usr/src/sys/
$ find . -type f -name \*.c -exec cat {} \; | wc -l
2806111

и как это такое количество C кода умудряется так стабильно работать.. :-?

// wbr

Блин, еще один. Причем тут это-то? Давай ты приведешь свою цепочку доказательств того, что C подходит под задачу написания прикладного софта и мы вместе посмеемся.

Большое количество софта на C - это следствие того, что его выбрали для написания в большинстве случаев. А уж почему выбрали - это совершенно отдельный вопрос. Не путай причину со следствем.

Большое количество проектов на C - это следствие. Возможных причин выбора - множество, в том числе и адекватность, скорость, неспособность разработчиков изучить что-то новое, неграмотность разработчиков, нежелание что-то менять, возможность тонкой работы с памятью, и.т.д.