LINUX.ORG.RU

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


0

0

Уязвимость позволяет удаленному пользователю вызвать отказ в обслуживании или выполнить произвольный код на целевой системе.

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

2. Удаленный авторизованный пользователь с привилегиями на подтверждение может с помощью некорректно настроенного Perl сценария выполнить произвольный код на целевой системе. Подробности неизвестны.

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

anonymous

Проверено: maxcom ()

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

// wbr

klalafuda ★☆☆
()

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

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

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

lol :)

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

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

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

anonymous
()

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

WFrag ★★★★
()
Ответ на: комментарий от vtVitus

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

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

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от vtVitus

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

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

WFrag ★★★★
()
Ответ на: комментарий от K48

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

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

>C++ + STL?

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

WFrag ★★★★
()
Ответ на: комментарий от kpn

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

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

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

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

WFrag ★★★★
()

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

svu ★★★★★
()
Ответ на: комментарий от Pi

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

svu ★★★★★
()
Ответ на: комментарий от WFrag

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>openwall, grsec

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

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

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

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

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

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

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

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

WFrag ★★★★
()
Ответ на: комментарий от I-Worm

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

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

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

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

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