Микрософт взломан снова.

А кому сейчас легко? Инженерам, видимо, пофиг, а менеджеры отбрешутся. :)

Мда, слишком большая сетка и слишком много людей ей занимаются. За всеми не уследишь, кто-нибудь да забудет какой-нибудь патч поставить. Я с этим борюсь путем установки патчей в logon скрипте администратора домена, но я на всех машинах не логинюсь администратором после выхода каждого патча, а как придется. У меня workstation (сервер под Linux-ом), а на сервере надо в шедулер что-ли вставлять установку патчей. Тоже не шибко хорошо с точки зрения безопасности, но что-нибудь придумать можно, с pgp напрмер. Тут есть еще одна проблема: все это работает только против известных дыр. А против неизвестных вообще бороться трудно, в последнее время security bulletins про IIS сыплются как из рога изобилия. Впрочем, меня они не касаются ;). За то время, пока M$ не выпустит патч знающие хакеры могут ломать все, что угодно, в том числе и саму M$. Люди, которые могут найти новую дыру существуют и нет никакой гарантии, что они кинутся сообщать о свежей дыре, а не попользуются ей сами.

А "хакер"-то голандский, а не немецкий...

"Люди, которые могут найти новую дыру существуют и нет никакой гарантии, что они кинутся сообщать о свежей дыре, а не попользуются ей сами." Утверждение верно для любой программы, что производства MS, что free software

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

Let fhe Flame War begins...

Это в теории. На практике же все совсем по другому: чтоб найти ошибку приводящую к скажем переполнению буфера, совсем не достаточно искать strcmp и заменять их на strncmp, т.к. это еще не гарантирует исправление ошибки (размер буфера может быть выбран не правильно, да и замедляет программу такая постоянная проверка), обычно программам просто скармиливают кучу не правильных данных, а потом разбираются (т.е. натуральный black box testing) и разницы между кол-вом людей занимающихся проблемой нет, мало того для более популярного продукта (который занимает 97% рынка) такого народа будет даже больше, чем для открытого и популярного среди linux, но с рынком 2%. И соответсвенно шанс этой ошибки быть обнаруженной у программы ни как не зависит от открытости-закрытости, но от популярности.

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

Тима, мать-перемать, когда писать правильно научишься, феноминальный-ты-человек.

vsl как всегда юморит - типа дыру дизассемблером
искать будут - и потом ассемблером ее править на
фирме?

Интересно, существуют ли дыры проявляющиеяся на
уровне ассемблерной версии и отсутствующие в
программе написанной на С?

Дыры в бинарнике, отсутствующие в исходниках ? При корявых библиотеках -- запросто :(

Вообще говоря, при написании как открытого, так и закрытого софта,
багов типа оверранов получается, может быть, примерно одинаковое
количество. Другое дело, что в open source софте такие дырки находят
намного быстрее, а где-нибудь глубоко в потрохах NT они могут жить
годами... Так что когда пользуетесь закрытым софтом, надо всегда
помнить, что дыр в нём ооочень много, просто про них никто не знает -
кроме, может быть, разработчиков, которым влом их править.
Зато получается, что если кому-нибудь очень всерьёз приспичит вас
взломать, подходящую дырищу всегда найти можно ;)

2ivan4th: это исключительно в Вашем воображении. Баги живут везде и ждут своего часа. Точно так же как быги в ядре Линукса живут и ждут своего "хакера". О чем я собственно и писал.

Конечно, причем предостаточно.
Например тотже GCC 95.3 на MIPS (и возможно других RISC
архитектурах , где для первого аргумента и результата
возвращаемого функцией используются разные регистры)
неправильно компилирует конструкции вида:

 f1(var1=f2(arg1,arg2,...));

 На MIPS f1 будет вызвана с параметром arg1, а не результатом
выполнения f1(...).

2anonymous: А gcc собирался с установленными флагами big endian? :))))))))))))))))))))

Угу... все забыли про одну достаточно серьезную дырочку, _недавно_ обнаруженную в PGP (OpenSource к слову), которая там жила ну очень долго, чуть ли не с 5ой версии? :)

2.2. Can I use PGPi for commercial purposes?
Yes, you can, but you must obtain a commercial use license from Network Associates Inc. or its authorized representatives.

PGP это вообще не OpenSource. А дыра была в той фиче, которая не входит в стандарт OpenPGP.

2Lae: ты хотел сказать она не GPL? Согласен...:) Но увы - PGP это OpenSource! Ибо исходники есть? Есть! :) GPL не есть нечто тождественно равнозначное OpenSource, GPL это всего лищь частный случай более общего понятия - OpenSource! RTFM батенька! :)
2anonymous: всосал ты, безграмотное убожище...:)

Может хватит базарить, а? Будем уважать друг друга. Каждый имеет право на свое мнение, да если оно не правильное.

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

Разногласие касается только вопроса - ограниченное
количество дыр в софте или нет :-)

Если ограниченное - то правы сторонники Open Source,
если нет - то Ogr и прочие "химики".
В принципе, число дыр можно было бы считать бесконечным,
если бы на уровне ассемблера появлялись бы случайные дыры
отсутствуюшие на С (шутливая идея vsl).
Но это странно, и примеры отсутствуют. Предложение о
кривых библиотеках не проходит - так как библиотеки
тоже пишутся на С.

Следующим идет вопрос о бесконечности Вселенной...

2Papa: количество дыр разумеется ограниченно... но способности людей вносить новые дыры в процессе исправления старых ничем не ограничено...:)

Дырки просмотром исходников ищут только в уж очень простых программах, наличие же логических дыр делают обыкновенным запуском тестов на собранных модулях, хороший пример linux kernel - с начала пишут потом ловят oops, а за тем пытаются вяснить откуда он взялся. Так чтА открытые исходники в процессе поиска дыр, что мертвому припарка.

Искоренить дыры в софте также невозможно как и победить ДТП на дорогах, (человеческий фактор блин!), другое дело их количество. Вот, например, многие вопят по поводу задержки выхода kernel-2.4.x. А считаю что правильно, пусть позже, да дыр поменьше. И спасибо всем beta тестерам, которые баги отлавливают и отсылают куда нужно, а не вопят давай быстрее 2.4.stable.

Разумеется существуют: например, классический backdoor Кена Томпсона в login: http://www.acm.org/classics/sep95/

Ссылка интересная, но сам пример с login-трояном
написан на Си.
Наверно, я малопонятно выразился, но интересен
эффект дыры, случайно появившийся в ассемблерном
коде и совершенно отсутствующий на уровне С
(некая фантастика ИМХО).

С другой стороны мы удалились от темы ИМХО.
Печь шла о дырах угрожающих безопасности, а
не о всех возможных ошибках.
Можно даже утверждать ИМХО, что возможные
ошибки бесконечны, так как совершенные программы -
недостижимый идеал (каждое усовершенствование - это
исправление некой логической или еще какой ошибки).

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

А вот число ошибок безопасности далеко не бесконечно
ИМХО, так как всегда связано с вводом в программу.
В последнее время особенно популярны дыры с переполнением
буфера, но кто сказал, что таких дыр меньше в
продуктах M$? Просто их сложнее найти ИМХО из-за закрытых
исходников и процесс их поиска не совсем статистический.
К сожалению, я сам этим не занимался...

К тому же, ремонт дыры в ОИ не ограничен временем и поэтому
меньше порождает вторичных ошибок. Можно представить идеальную
компанию, где руководство все понимает и даст возможность
все сделать правильно, но сложно (обычно начальство все меряет
не в энтропии, а во времени).

Насчёт того, что тут irsi говорил про Open Source - см.
определение : http://www.opensource.org/osd.html
У ssh сырцы были всегда доступны, однако проект Open SSH всё равно
был запущен, тк от Open Source эта прога была весьма далека.
Если имеете ввиду просто доступность сырцов - так и говорите.

А по поводу того, что закрытый софт лучше ковыряют, тк на мол на
уровне ассемблера - да гон это всё. Я сам порядком ковырял закрытый
софт SoftICE'ом и etc. (правда с несколько иными, менее возвышенными целями ;) Но, извините меня, искать дыры в _недокументированных_ API...
Возьмём, например, NTшный системный вызов - int 2e (бывают намного
более малоизвестные API, в которых дыркам живётся как у Христа за
пазухой - API скрепки в Офисе, например - летом там кажись хорошие
такие баги обнаружились, но это, можно сказать, чудом, а сколько их
там ещё? ). Некий чел (может быть, Solar Designer, точно не помню)
просто стал вызывать различные функции int 2e набивая random
значения в регистры. 40 что ли вызовов нашлось, которые могли
давать BSOD - как это объяснялось (as far as I remember), в корне неправильная работа с адресами, передаваемыми этим вызовам (в ядре),
может там ещё со стеком что-то. Тогда Micro$oft это подправил. А спрашивается, если бы точно знать, как работать с этими вызовами - сколько дыр там можно было бы найти? Я думаю, сколько угодно. Вобщем, одно дело когда хотя бы известно, как работать с той или иной частью
системы, пусть даже исходников к ней нет, и совсем другое - когда
даже не знаешь, как ей данные передавать, чтоб на тот же оверран
проверить...

Такая дыра - в принципе возможна, но маловероятна. В языке, где семантика более упорядованея, чем в С, - праметически невозможна (я вообще полагаю, что 90% дыр в языке наподобие Modula-2, который является аналогом С по преполагаемой области применения, были бы отлоылены либо при трансляции, либо в run-time). Но забавный вопрос о другом: а почему все так уверены, что в Linux GCC остуствует алналогичный троян: минимальная проверка, позволяющая надеятся на от, что все в порядке это: перетранслировать GCC _другим_ транслятором (например - Visual C), после чего сделать полный bootstrap gcc и сравнить результаты с bootstrap обычным образом. Если все совпало - можно надеятся, что трояна нет. Но такую проверку ведь вряд ли кто-то проделывал. PS: Кстати, если друзья-хакеры действительно две недели резвились м сорцах M$^ то они имели достаточно времени на стваивание подобной back door в M$ C++. Причем восстановление всех исходых текстов из архива тут не поможет. Надо еще восстановить и все бинарники. А об этом мало кто задумывается. Антон

IMHO, дело в отношении MS ко всму миру и самой-себе. Ставить заплатки - работа для остальных, у MS одно из главных направлений: 1) делать дырки 2) продавать дырки (самая главная задача - здесь и проявляется гениальность Вилли) 3) делать заплатки на дырки ( для успокоения публики ) Самим лечиться - времени нет. Вторая проблема в видимости архитектуре. Когда видишь исходники легче представить архитектуру и или найти дырку или отказаться от прилады.

Добил бы кто его, чтоб менеджеры не мучались... :-)

йЮЙ СФЕ МЮДНЕКХ АЮИЙХ ОПН РН, ВРН НРЙПШРШИ ЙНД КСВЬЕ ГЮЙПШРНЦН... щРНР АПЕД Ъ ВХРЮК Б ЙСВЕ ЙНМТ, ОСАКХЙЮЖХИ, Х Р.Д. ю БЕДЭ БЯЕ МЕ РЮЙ! йНЦДЮ ФЕ, МЮЙНМЕЖ, ГЮЙНМВХРЯЪ ЩРН МЮЦКНЕ НУЛСПЕМХЕ ЛЮЯЯ?!
оНЯВХРЮИРЕ УНРЪ АШ ЙНКХВЕЯРБН ДШПНЙ Б ОПНДСЙРЮУ OpenSource Х MS!
дЮКЕЕ... БНР БНГЭЛЕЛ ОПНЯРНЦН ЯХЯЮДЛХМЮ. аСДЕР КХ НМ ЙНОЮРЭЯЪ БН БЯЕИ ЩРНИ ЛЮЯЯЕ ХЯУНДМХЙНБ? дЮ МХ Б ФХГМЭ! с МЕЦН Х АЕГ ЩРНЦН ЙСВЮ БЯЕБНГЛНФМШУ ОПНАКЕЛ. х МЕ РНКЭЙН С мюьецн ЯХЯЮДЛХМЮ, ГЮ АСЦПНЛ - РН ФЕ ЯЮЛНЕ!.. еЛС ЦКЮБМНЕ - ВРН АШ БЯЕ ПЮАНРЮКН ЙЮЙ ЯКЕДСЕР, МЕ ГЮБХЯЮКН, ВРНА ЧГЕПШ МЕ ДНЯРЮБЮКХ. х ЩРН - ОПЮБХКЭМН!
нРЙСДЮ ЯХЯЮДЛХМ АЕПЕР ХМТНПЛЮЖХЧ Н ДШПЙЮУ? ОПЮБХКЭМН! ХГ хМЕРЮ. ю ЙРН ДЮЕР ЩРС ХМТНПЛЮЖХЧ? НОЪРЭ ОПЮБХКЭМН! ме яхяюдлхмш! Ю РЕ, С ЙНЦН УБЮРЮЕР ЯБНАНДМНЦН БПЕЛЕМХ МЮ ПЮЯЙНОЙХ ЩРХУ ЯЮЛШУ ХУНДМХЙНБ, ХКХ, РЮЛ, ДХГЮЯЯЕЛАКХПНБЮМХЕ. хКХ ФЕ РЕ, ЙРН ЩРХЛ ГЮМХЛЮЕРЯЪ ОН ЯКСФЕАМНИ МЕНАУНДХЛНЯРХ... х ЩРХ ПЕАЪРЮ БЯЕЦДЮ ВЕЦН-МХАСДЭ МЮЙНОЮЧР, МЕБЮФМН - ГЮЙПШРШИ ЙНД ХКХ НРЙПШРШИ. ю ЯХЯЮДЛХМ ОНКСВХР ХМТНПЛЮЖХЧ НА ЩРНЛ (ЦНДХЙЮ, РЮЙ, ВЕПЕГ ДБЮ), СРПЕРЯЪ, ОНЯРЮБХР ПЕЙНЛЕМДНБЮММШИ ОЮРВ, Х АСДЕР НОЪРЭ ФДЮРЭ МНБНИ МЮОЮЯРХ.
бНР РЮЙ!

Интересно, хоть кто-нибудь может сказать, какая ЭТО ^^^ кодировка... ;-)

cat > win.shit
recode -wk win.shit
cat win.shit
=>
текст (был в виде1251)

А почему говеный russian-apache пропустил чужую кодировку? Отстооой.

> почему говеный russian-apache пропустил чужую кодировку? Отстооой. links кривой.