LINUX.ORG.RU

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


0

0

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

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

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

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

anonymous

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

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

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

ммм.. вам хочется просто поpi%$ или все-таки ехать? "солнце всходит и заходит.."

// wbr

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

>ммм.. вам хочется просто поpi%$ или все-таки ехать? "солнце всходит и заходит.."

Ну ты хитрый какой. Т.е доказательств не будет?

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

> Ну ты хитрый какой. Т.е доказательств не будет?

я за презумпцию невиновности. пока что аргументов кроме "нуу.. у девелУперов кривые руки" я не видел. это за доказательство не считается. в лучшем случае - ограничивающий фактор.

// wbr

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

>я за презумпцию невиновности. пока что аргументов кроме "нуу.. у девелУперов кривые руки" я не видел. это за доказательство не считается. в лучшем случае - ограничивающий фактор.

Ты наверное плохо смотрел. Глянь заголовок новости. Также я не зря давал ссылку на debian.org, посмотри список последних найденных ошибок, погляди на чем писаны приложения. Потом возвращайся с накопленным результатом, обсудим.

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

> Ты наверное плохо смотрел. Глянь заголовок новости.

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

> Также я не зря давал ссылку на debian.org, посмотри список последних найденных ошибок, погляди на чем писаны приложения.

на Debian не пойду бо Linux не использую. если хотите обсудить примеры со ссылкой на конкретную систему, то мне проще в терминах BSD.

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

что "язык C не подходит для написания приложений?". извините, но это я обсуждать не буду - это чистой воды словоблудие :)

// wbr

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

> $ cd /usr/src/sys/

Это не прикладное. Это системное ;)

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

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

ну насчет шелл-скриптов -- там можно огрести такую кучу ошибок и еще больше дыр, что C и не снилось.

С не защищаю, но нигде в стандарте не сказано, что нельзя автоматом проверять границы массивов. Пропатчи компилятор или неисполнимый стек сделай.. Или═пусть компилятор по другому стек располагает.

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

Сабж! Антон, какие планы на этот раз ;)

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

> Если я не ошибаюсь, ни в одном из них получить дыру в безопасности переполнением буфера нельзя.

Ошибаешься, т.к. принимаешь за аксиому безошибочность работы с памятью
в этих языках. В них самих может быть проблема с переполнением буфера
в их внутреннем коде, что не раз подтверждалось на практике - perl,
python, php и т.д.

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

> Бля урод! Сказали тебе умные люди ПОЧЕМУ ЭТО ВЫЛЕЗЛО.

Ты правда считаешь, что объяснения неких умных людей как-то поможет вернуть 8.5 млрд. баксов, потерянных из-за ошибки в программе на Ada? По-моему, эти объяснения просто никого не волнуют. И ещё после таких ошибок ни одна вошь, типа тебя не имеет права называть Ada безопасным языком. И кстати, ни один по-настоящему умный человек не скажет тебе, что Ada - безопасный язык. Ты сильно увлекаешься бульварной околокомпьютерной прессой.

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

>ну насчет шелл-скриптов -- там можно огрести такую кучу ошибок и еще больше дыр, что C и не снилось.

Это другой вопрос.

>С не защищаю, но нигде в стандарте не сказано, что нельзя автоматом проверять границы массивов. Пропатчи компилятор или неисполнимый стек сделай.. Или═пусть компилятор по другому стек располагает.

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

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

>Ошибаешься, т.к. принимаешь за аксиому безошибочность работы с памятью в этих языках. В них самих может быть проблема с переполнением буфера в их внутреннем коде, что не раз подтверждалось на практике - perl, python, php и т.д.

Ну дык о том и реь. Сами они на чем написаны? :)

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

>Ты правда считаешь, что объяснения неких умных людей как-то поможет вернуть 8.5 млрд. баксов, потерянных из-за ошибки в программе на Ada?

Кончай апелировать к эмоциям. Ты можешь сходу оценить выгоду использования Ада вместо C? Или потери из-за ошибок C? Или потери/выгоду из-за использования C вместо другого языка? Или что было бы, если на месте Ada использовался C?

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

И кстати, ты путаешь причину со следствием. Ошибка была совершена на языке Ada скорее всего потому что многих других языков там и рядом не лежало. Я думаю, стоимость всех ошибок всех программ на GW-Basic-е существенно ниже этих $8.5 млрд, однако это не говорит о надежности GW-Basic-а. Поэтому так же не говорит о надежности Ada ошибка в $8.5 млрд. Понимаешь логику? Это одиночный замер и делать на основании него какие-либо выводы, без знания деталей, - глупо.

>По-моему, эти объяснения просто никого не волнуют. И ещё после таких ошибок ни одна вошь, типа тебя не имеет права называть Ada безопасным языком.

>И кстати, ни один по-настоящему умный человек не скажет тебе, что Ada - безопасный язык. Ты сильно увлекаешься бульварной околокомпьютерной прессой.

По сравнению с C Ada бесспорно безопасней. Я где-то видел статистику по среднему количеству ошибок на строчку кода, если найду - покажу.

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

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

Тут я, конечно, совершенно не прав.

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

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

>если говорить о новости, то см. самое первое сообщение в потоке. ссылку на грамотное описание уязвимости в студию. можно без exploit.

Не важно. Речь о переполнениях буфера в целом. Я зря сослался на саму новость, согласен. Ситуация с переполнением в CVS пока не совсем ясна (можно еще тут посмотреть https://ccvs.cvshome.org/source/browse/ccvs/NEWS?rev=1.116.2.127&content-...), но это не важно. Постоянные переполнения буфера - это реальность :)

>на Debian не пойду бо Linux не использую. если хотите обсудить примеры со ссылкой на конкретную систему, то мне проще в терминах BSD.

Да без разницы, я debian.org привел просто потому что это удобное место для просмотра всячеких уязвимостей. Вот, глянь: http://www.debian.org/security/2005/

Заметь, что эти уязвимости не специфичны для Debian, тот же софт используется и во многих других системах. Посчитай количество buffer overflow.

Могу еще вот эту ссылку дать: http://www.frsirt.com/english/index.php

>что "язык C не подходит для написания приложений?". извините, но это я обсуждать не буду - это чистой воды словоблудие :)

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

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

> Ты можешь сходу оценить выгоду использования Ада вместо C?

Я нигде ни словом не обмолвился про Си. Я лишь выступил оппонентом
против высказывания "На Ada ничего подобного невозможно".

> словоблудие насчет "миллиардов баксов" меня мало волнует.

Словоблудие у тебя. У меня факт.

> Ошибка была совершена на языке Ada скорее всего потому что многих других языков там и рядом не лежало.

Опять ошибаешься. Читай до полного просветления:
http://www.rol.ru/news/it/press/cwm/38_97/ariane.htm

> Это одиночный замер

Это могильная плита на которую все называющие себя программистами
должны смотреть время от времени и никогда не произносить бред про
супернадёжность Ada, который тут прозвучал выше.

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

>Я нигде ни словом не обмолвился про Си. Я лишь выступил оппонентом против высказывания "На Ada ничего подобного невозможно".

_подобного_ невозможно. Речь шла о переполнении буфера.

>Опять ошибаешься. Читай до полного просветления: http://www.rol.ru/news/it/press/cwm/38_97/ariane.htm

Ключевой момент:

[...] Однако адаптация ПО для проекта Ariane 5 прошла без должной ревизии уже созданных программных строительных блоков. К сожалению, сделанные в них допущения противоречили спецификациям новой программы полета. [...]

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

>Это могильная плита на которую все называющие себя программистами должны смотреть время от времени и никогда не произносить бред про супернадёжность Ada, который тут прозвучал выше.

Бред. С таким же успехом это мог бы быть любой язык.

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

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

>>Ошибка была совершена на языке Ada скорее всего потому что многих других языков там и рядом не лежало.

>Опять ошибаешься. Читай до полного просветления: http://www.rol.ru/news/it/press/cwm/38_97/ariane.htm

Что-то я не нашел там опровержения своим словам. Например, я на 100% уверен, что Java там не было и поэтому у просто Java не было никаких шансов проявить себя таким образом :) Вот это-то я и хотел сказать.

Никакой статистике по другим языкам, использованным для написания подобных приложений, я там не увидел. Читай, пожалуйста, _внимательно_ мои утверждения.

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

>8.5 млрд. баксов, потерянных из-за ошибки в программе на Ada?


ТЫ, микроб, можешь мне объяснить суть этой ошибки? Не можешь? Тогда не 
вякай. Я те объясню. Такого рода конвертацию в Ada можно сделать только 
с использованием Unchecked_Conversion - простое приведение типов вроде 

1) Integer16(Float64) - недаст сделать компилятор, поэтому
   было сделано Unchecked_Conversion.
2) Из экономии НЕБЫЛО КОДА, отлавливающего возможное исключение 
   Operand_Error, которое возникает при невозможности провести 
   преобразование. 

И нах. со своими ссылками на всяких мудаков. Читай источник.

http://sspg1.bnsc.rl.ac.uk/Share/ISTP/ariane5rep.htm

Вывод таков:
Компилятору заткнули рот Unchecked_Conversion-ом, а обработчики 
исключений были не использованы НАМЕРЕННО, т.к. на 4-м Arian-е такая 
ситуация просто физически возникнуть не могла.

The reason for the three remaining variables, including the one 
denoting horizontal bias, being unprotected was that further reasoning
indicated that they were either physically limited or that there was a
large margin of safety, a reasoning which in the case of the variable 
BH turned out to be faulty. It is important to note that the decision 
to protect certain variables but not others was taken jointly by 
project partners at several contractual levels.

>И кстати, ни один по-настоящему умный человек не скажет тебе, что Ada 
- безопасный язы


Ты это про себя? Нах!


>Ты сильно увлекаешься бульварной околокомпьютерной прессой.


В натуре? Ошибаешся. Я давно и успешно делаю программы на Ada.

Потявкаешь еще?











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

>Я нигде ни словом не обмолвился про Си. Я лишь выступил оппонентом >против высказывания "На Ada ничего подобного невозможно".

Похоже я неточно выразился - фраза должна была звучать так "На Ada переполнение буфера можно устроить, но для этого надобно СИЛЬНО постараться и точно знать что ты делаешь - т.е. СПЕЦИАЛЬНО ДЕЛАТЬ ИМЕННО ПЕРЕПОЛНЕНИЕ БУФЕРА". Более того, если начинающему программисту на Ada предложить сделать переполнение буфера - он будет долго думать как это устроить и скорее всего у него не получится.

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

плохой из тебя фраг. то что больше уязвимых аппсов на си - это потому что на нем 90% всего пишется

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

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

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

да. потому паскаль и ада - языки для обучения программированию =) получению экспириенса. ну как курс по ВВ для саперов

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

>плохой из тебя фраг.

Это сокращение от Walking Frag, если что :)

>то что больше уязвимых аппсов на си - это потому что на нем 90% всего пишется

Не, речь про переполнение буфера. Хрен с ними, с другими ошибками, речь пока не о них. Меня смущает количество ошибок безопасности из-за переполнения буфера. Как-то их много слишком.

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

>короче WFrag срочно бросай пользоваться кухонным ножом, потому что ты можешь отрезать или серъезно повредить себе палец, тот который у тебя за программирование на аде отвечает и тебя выгонят с работы.

Честно скажу - Ada-у только в книжке видел :) Моя позиция немного не о том. А хлеб я кухонным ножом режу, а не бензопилой "Дружба", как раз чтобы ногу себе не отпилить случайно :)

Ну вот нафиг в большинстве задач низкоуровневая работа с памятью? Возьмем, например, Subversion. Там основная семантика - это всяческие манипуляции с деревьями, изменениями, etc. Зачем там тонкая работа с памятью?

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

> подобного_ невозможно. Речь шла о переполнении буфера.

Ну что за детские отмазки? Кому интересен какой-то buffer overflow сам по себе? Трогает лишь эффект от него. Дык подобный эффект и был показан.

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

> 2) Из экономии НЕБЫЛО КОДА, отлавливающего возможное исключение
Operand_Error, которое возникает при невозможности провести
преобразование.

Вывод нормального человека из вышесказанного таков: в Ada нет реальной
защиты от ошибки программиста. Вывод фаната Ada: язык не при чём,
виноваты космические лучи.

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

>Вывод нормального человека

Вывод ПРИДУРКА с которым разговаривать совершенно бесполезно.

Адью красавчик.

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

>Ну что за детские отмазки? Кому интересен какой-то buffer overflow сам по себе? Трогает лишь эффект от него. Дык подобный эффект и был показан.

Ты это, от темы не уходи. Моя цель не пиписьками померяться и выяснить кто прав, а кто нет, а обозначить некоторую проблему, предложить способы ее решения и обсудить это.

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

>Трогает лишь эффект от него.

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

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

> Остальные ошибки кроме переполнения буфера я на данный рассматривать не хочу

Вот от таких товарисчей и заваливаются ракеты Ариан. Потому как мышление их однобоко: нет buffer overflow? - безопасен, можно расслабиться. И всё-таки ошибка была того же порядка и того же класса. Недосмотр, превышение границ.

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

>Вот от таких товарисчей и заваливаются ракеты Ариан. Потому как мышление их однобоко: нет buffer overflow? - безопасен, можно расслабиться. И всё-таки ошибка была того же порядка и того же класса. Недосмотр, превышение границ.

Ну ты странный какой-то. Я не господь бог и решить _все_ проблемы этого мира начиная от негров и кончая ракетами я не могу (и ты тоже). И даже обсудить не могу. Именно по этому я хочу ограничить тему узкими рамками, чтобы было ясно когда все аргументы перечислены и стоит закончить разговор. Тема, навеянная новостью - ошибки безопасности из-за переполнение буфера и язык C в прикладном программном обеспечении. Заметь, ракеты мы пока не запускаем. Более того, я не говорю, что остальные ошибки в прикладном софте можно игнорировать - они несомненно тоже важны. Но я выделил именно ошибку переполнения буфера так как встречается она ну уж очень часто. Вопросы по постановке задачи есть?

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

Если тебе интересно обсудить ошибку переполнения - открывай отдельную тему.

Все, я больше не хочу говорить на эту тему.

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

>Если тебе интересно обсудить ошибку переполнения - открывай отдельную тему.

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

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