LINUX.ORG.RU

Безопасность систем с открытым кодом


0

0

Споры о том, приводит ли открытие кода к усилению или ослаблению безопасности программного обеспечения, длятся годами. Ни одно из этих утверждений нельзя считать абсолютной истиной: свободно распространяемое программное обеспечение открывает более широкие возможности и перед хакерами, и перед специалистами по безопасности. К счастью, существуют определенные технологии для систем с открытым кодом, которые могут помочь специалистам усилить защищенность своих решений.

Одни утверждают, что свободно распространяемые программы по своей природе более защищены, чем системы с недоступными исходными текстами [1], а другие считают, что это не так [2]. Ни одну из этих точек зрения нельзя назвать единственно правильной: по сути, это две стороны одной медали.

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

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

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



Проверено: green

ну вот сколько лет живу с opensouce защитой и еще ни разу никто не поломал.. а вот стоит тока вспомнить винды с RPC exploit так ваще... оргазм..

ananymous
()

Re:

все хорошо, только давайте назовем вещи своими именами - "специалистов по безопасности" - хакерами, а "статью о методах организации защиты" - практическим руководством по поиску дыр в opensource ПО ;-)))

dea
()

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

anonymous
()

anonymous (*) (2003-09-11 17:06:01.086008): Да, конечно, такой бы язык - написал "защищенная система", откомпилил и получил защищенную систему. То есть без ошибок и без дыр.

kraw ★★★★
()

безопасность языка и производительность стоят на разных концах... все эти guard-ы добавляя безопасность снижают скорость, иначе была бы халява, а она бывает только в студенческие годы :-))

dimonb
()

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

ananymous
()

Так Минобороны США уже несколько десятков лет назад создало язык для написания больших защищенных (от дурака-программиста) систем реального времени. Язык называется Ada и существует даже его opensource реализация (gnat)

monk ★★★★★
()

хах, паскаль тоже тогда защищенный язык..

дурилка ты картонная, - строго алгоритмизированный не значит секурный!!!

ananymous
()

Последнему анониму: паскаль намного секъюрнее, чем С, потому что он , во-первых, проще и во-вторых, не имеет адресной арифметики. К вашему сведению, например, на Java написать несекъюрный код НАМНОГО сложнее (нужно специально стараться), чем на C

anonymous
()

> потому что он , во-первых, проще и во-вторых, не имеет адресной арифметики.

Вы фичи С выдаете за недостатки? Кто вам не дает - вводите code review и пишите без адресной арифметики на С. Сила С в том, что если вам понадобится злобный изврат в отдельно взятом месте (например, goto в критическом по скорости участке или longjmp из обработчика сигналов или возможность исполнить записанный в массиве hex-код) - вам не придется перекраивать всю систему компиляции, вносить новые модули, менять язык etc. Кашу можно написать на любом языке, и не надо представлять фичи С как его слабости за счет низкоквалифицированных программистов.

anonymous
()

>во-первых, проще и во-вторых, не имеет адресной арифметики.

И массивов там нету ?
И строк, и переполнится они нихрена не могут ??? 8-[ ]

Он секурный, только если там врубить проверку переполнение строк и массивов.
Но это для отладки делается, и то редко

Насчёт проще - тоже загнул

anonymous
()

ugu..вот такие вот "академики" по безопасности как предыдущий несколько постов назад и делают супер секурные продукты, которые потом на каждом strcpy модно сегфаултить, а на каждом 2ом - эксплойтить...

lamerz live, но гоу хом!!

ananymous
()

Чем ниже уровень программиста, тем более "защищенный" язык программирования ему нужен.
Жаба тому хороший пример...

anonymous
()

Вот в таких извратных методах потом и появляются дырки. А контроль размерности в Паскале (в борландовской реализации по крайней мере) есть. В классическом Паскале, насколько знаю, она тоже предусматривается - нельзя присвоить массиву a[ 1 .. 10 ] как a[ 11 ] что-то. И строк в классическом нет вообще (array of char - это не string). А то, что все проверки сжирают ресурсы - оно любому с головой в нужно месте понятно.

anonymous
()

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

ignat

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

2 dimonb (*) (2003-09-11 16:42:30.141526) статью читал?

Хм... поглядел...

встречный вопрос: а ты сам то читал? или не въезжаешь? объяснить?

dea
()

Что даёт контроль размерности ? Почему падение с "превышена размерность массива" лучше, чем падение с "ошибка защиты" ?

lenin
()

2lenin А то что падение с ошибка размерности не ломанет тебя, а вот падения от ошибки защиты может и не быть - получш эксплоит и все...

А вообще ломать можно и на жабе просто уровень взлома меняется хоть в стиле Sobig

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

>Может быть язык изначалько должен быть спроектирован исходя из
>концепции безопасности. Может быть использовать сборщик мусора от
>переполнения буфера.
Мелкий софт уже сделал такую глупость: в реализации C# для .NET они сделали специальный класс, который бы защищал производные от него от ошибки переполнения буфера, причем этот самый класс тоже страдал от этой проблемы ;-))))))))))))))))))))))))))))
Об этом тогда писали в Компьюленте.

SadAlex.

anonymous
()

Особенно поражают выпады в сторону несекьюрности C... Просто из-за тотального отупения, всем облом вставить пару строк кода чтобы защититься от переполнений.. или посмотреть man и почитать, почему лучше не использовать функции типа gets(), sprintf() и т.п... Всегда легко свалить свои ошибки на несовершенство языка который, думаю многие поддержат, - великолепная "игрушка", но только для больших и умных. И вообще, он, как говорится - оЧЧень дружелюбный, но сам выбирает себе друзей. Так что кому не повезло - дерзайте всякие вижуал бейсики, си-шарпы и т.д... Быть может хоть там у Вас что-нибудь да получится... -- Andy

anonymous
()

2SadAlex. Глупость говориш ты. Никакого такого специального класса в .Net нет. Есть опция компилятора C++ /GS, о которой когда то (сама того не зная) писала компьюлента. Но эта опция ни какого отношения к C# и .Net не имеет. 2Andy - да, именно на gets и sprintf погорела MS в реализации RPC. теперь будут cin и CString использовать.

gggg
()

Похоже Andy еще один местный суперпрограммист, который пишет программы без ошибок. А язык С - вершина человеческой мысли.

anonymous
()

ошибки всегда будут пока человек останется таким тупым!!

БУДЬ КАК МАШИНА. ДУМАЙ КАК МАШИНА. ДЕЛАЙ КАК МАШИНА.

ananymous
()

Казалось бы, причем здесь слакварь ?

anonymous
()

2ggg: да, именно на gets и sprintf погорела MS в реализации RPC. теперь будут cin и CString использовать. Откуда в RPC gets? Неужели он stdin юзает? Сомневаюсь я че-то.

P.S: CString и cin они юзать не будут. cin только для "hellow word" программ подходит, а CString из libMFC, которую они сами негде не юзают из-за ее убогости невероятной (хотя в в VC пихают до сих пор)

P.P.S: Будут юзать fgets и snprintf, а sprintf и прочие уже давно пора сделеть deprecated

anonymous
()

БУДЬ КАК МАШИНА. ДУМАЙ КАК МАШИНА. ДЕЛАЙ КАК МАШИНА.

не пользуй strcpy().

ananymous
()

> libMFC, которую они сами негде не юзают из-за ее убогости невероятной (хотя в в VC пихают до сих пор)

Опять попёрло луноходников!!! Один из любинмых наездов - MFC криво и MS нигоде её не пользует!!! Опять голословное утверждение. Посмотри на DLL-ки системные... Пользуют, ещё как пользуют. А на счёт убогости... Покажи, в чём жа она убога ? Если ты тупой, это совсем не значит, что вещи, которые ты не понимаешь, тоже тупые!

SCREW
()

2SCREW : Ну MS ее (MFC) использует в некоторых утилитах Windows (Paint, WordPad и т.д). Но, например, Word и Excel ее ни когда не использовали. Те библиотеки, на которых они сделаны MS не дает ни кому (или дает, но не за стоимость VisualStudio). Даже свои COMпоненты MS не делает с помощью ATL.

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

Не суперпрограммист, да и отсутствие ошибок в
программе - вещь недоказуемая...
Просто Andy делает 2 простые вещи:
1) Учится на своих ошибках
2) Не считает, что виной его ошибкам - несовершенство языка.
--
Andy

anonymous
()

> gggg

оН-ОНБНДС ХЯОНКЭГСЕР-МЕ ХЯОНКЭГСЕР. бНР ЖХРЮРЮ (MSDN)

"Does Microsoft use MFC in their products? Which ones?

There are many Microsoft apps written in MFC. Sometimes it's just not obvious. (To name a few: Bookshelf, Bob, WordArt OLE server, Visual C++ (of course), Windows 95 Paint, Windows 95 WordPad, some portions of Windows 95 FAX software, some Windows 95 games I know of....)

In the future, there are more apps coming out using MFC. I don't have a way to track all of these uses, so there is certainly more that I'm not aware of or can't remember. I don't expect Word or Excel to ever use MFC≈they have way too much legacy code and they don't see any customer benefit to rewriting to MFC. But my point is≈definitely for new code, Microsoft is using MFC. Even some "old" code is taking advantage of MFC in future versions.

Dean McCrory, MSMFC, 6/8/95"

дЮКЕЕ:

мЕ ГЮАШБЮИ, ВРН РНР ФЕ нТТХЯ ЯНДЕПФХР рсебс усвс ЙНДЮ, СМЮЯКЕДНБЮММНЦН ЕЫЕ НР Win16. оЕПЕОХЯШБЮРЭ ЕЦН ГЮМНБН МХЙРН Б ГДПЮБНЛ СЛЕ МЕ АСДЕР. хлун, БЕЯЭ "АНКЭЬНИ" ЯНТР НР MS МЮВХМЮКЯЪ нвемэ ДЮБМН, ЙНЦДЮ MFC КХАН МЕ АШКН, КХАН НМЮ МЮУНДХКЮЯЭ Б ПСДХЛЕМРЮПМНЛ ЯНЯРНЪМХХ. х ЯЕИВЮЯ MS ЯНБЯЕЛ МЕ ВСПЮЕРЯЪ ХЯОНКЭГНБЮРЭ MFC Б ЯБНХУ ОПНДСЙРЮУ... сАЕДХК ?

SCREW
()

2Screew Нет, не убедил! Ты на дату посмотри: 6/8/95. Более свежих аргументов у MS нет?

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