Не сказано...

Вот так и рушатся легенды о надежном и непрбиваемом линупсе. Решето

На вашем сайте есть визуальный баг:
В свойство CSS background для body стоит добавить #FFFFFF.
А то смотрится страшновато...

Решето!

Еще раз развеян миф о безопасности ляликс...

>их на киллометр в землю закопали и сверху трехтонным монолитом придавили.

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

>когда задаю вопрос «сколько паролей помните?» почти стандартный ответ «два», реже «три»

Освойте терморектальный криптоанализ.

Ответ будет «все» :)

а дальше локальным эксплоитом добили

а почему на таких важных серверах ядро не обновлено?

Такого мифа и не было, все знали, что РЕШЕТО.

Вот Линукс и перестаёт быть неуловимым Джо из анекдота.

кажется, это был я О_о как положено чайнику, я тыкал на невесть-какие кнопочки на сайте kernel.org скачивая ядро как раз 28ого августа. О_о

>у друхих всё в порядке, у тех же бзяшников?

/0

А при чем тут, собственно, неуловимость? Ну бахнулся сайт. Бывает со всеми. С Git репозиторием все в порядке, вроде, и славно. Нечего панику поднимать.

Никогда им и не был, как и любой нормальный софт.

А вот и школьники с линейки вернулись

Интересно когда http://android.git.kernel.org/ починят ...

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

Мде, MS добавит новый пункт к getthefacts.

Стив Балмер, залогиньтесь.

> сначала увели пароль от какого-нибудь mail.ru, а потом чисто случайно он подошел в качестве ssh пароля

Это звучит вполне правдоподобно.

ну а потом получить рута это уже дело техники

А вот это непонятно - IMHO, получить root на сервере (где установлен минимально достаточный набор хорошо протестированного ПО)- задача не тривиальная. Собственно говоря, именно это и вызывает вопросы...

печально зрелище...

тесты не спасают от уязвимостей

> тесты не спасают от уязвимостей

А что спасает? Я по наивности считал, что уязвимость - довольно редкое явление. Тем более, уязвимость, дающая root-доступ. Собственно говоря, насколько я понимаю, владельцы kernel.org сами пока не поняли, как удалось поднять пользовательские привилегии до административных...

только аудит и ревью кода

Да, Господи!

> Освойте терморектальный криптоанализ.

Давно уже. Поймите — расстрельная группа на пати-вене состоит то же из людей. Это не бригада на ментокрылых мусоршмидтах... И люди таки требуют надбавки за вредность! :)))

> а почему на таких важных серверах ядро не обновлено?

На каких «таких важных серверах» - локальной тачке H. Peter Anvin'а, с которой произошел взлом?

> Собственно говоря, насколько я понимаю, владельцы kernel.org сами пока не поняли, как удалось поднять пользовательские привилегии до административных...

http://lwn.net/Articles/457246/

> только аудит и ревью кода

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

А вот это непонятно - IMHO, получить root на сервере (где установлен минимально достаточный набор хорошо протестированного ПО)- задача не тривиальная. Собственно говоря, именно это и вызывает вопросы...

Ходите по ссылкам, читайте.

«If I remember correctly, H Peter Anvin was, at least, an admin for kernel.org services.

That would give easy answer, how root access was possibly gained. I find two possibilities. First if sudo authentication was passwordless on utilities with low security and/or sudo authentication had shortcircuit to ssh-login, a single-sign-on, then the intruder did not need to use any vulnerabilities in software code but just found weak spots in methods to use root priveledges. Secondly, if the ssh-client binary were trojaned at H Peter Anvin's use, typed password for sudo were logged as well.»

Судя по всему пароль от рута увели через кейлоггер на машине H Peter Anvin.

Ни что не спасает.

>> тесты не спасают от уязвимостей

А что спасает? Я по наивности считал, что уязвимость - довольно редкое явление. Тем более, уязвимость, дающая root-доступ. Собственно говоря, насколько я понимаю, владельцы kernel.org сами пока не поняли, как удалось поднять пользовательские привилегии до административных...

Проблема с уязвимостями в том, что они есть. Мы считаем что они есть _всегда_. И не обязательно что это. Это может быть бекдор («закладка»). И это может быть ошибка реализации или ошибка проектирования (каждая из этих ошибок потенциально приводит к бреши в системе безопасности, но немного по-разному). Ошибка может быть даже не в Вашем или моём коде. Она может быть в совершенно третьей (в нашем случае) библиотеке. Она просто _есть_.

Вопрос только когда найдут. И насколько скоро. Тогда вначале будет PoC/0-day (это редко и если повезёт), а потом всё это станет «достоянием общественности».

Статический анализ кода отчасти помогает на этапе разработки «прочесать» код на наличие багов. Для С есть немало инструментов типа splint, dmalloc, Electric Fence... Но Вы спросите у почти любого из присутствующих здесь — а они хоть знают что это и как этим пользоваться? Для динамического анализа кода — valgrind, конечно. Но и фаззерами по-пользоваться не грех. И то после всех перечисленных «мероприятий» можно считать что мы чего-то таки да... Не нашли. Только со временем вся эта байда выплывает.

В проприетарных поделиях ситуация со всем этим ещё хуже. Можете поверить наслово. ;)

Замечу что все перечисленные средства это не то же самое, что подразумевается под unit test'ами.

Спасибо за ссылку. Впрочем, объяснения, приведенные там, довольно шатки. Одни предположения, никаких фактов. Неизвестно даже, как именно была настроена аутентификация на взломанной машине... Подождем подробностей.

> а почему на таких важных серверах ядро не обновлено?

А сами-то часто обновляетесь? И потом — там ядро-то как-раз и не трогали.

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

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

> в силу конечности любого кода

Код бесконечен же (новые версии, да).

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

Если при закрытии уязвимости не вносятся новые %)

> Правильно ли я понял, что софта без уязвимостей в природе не существует?

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

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

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

Люди ленивы и программисты не исключение. Им иной раз лень _думать_ или (например), сделать одну проверку возвращаемого значения. Или лень внимательно посмотреть на код. Иногда они этого не могут сделать в силу каких-то причин (как обычно, внезапно наступил дедлайн). Причин море. Результат один — кода без ошибок не существует.

С другой стороны, это же хорошо — сколько диссертаций по данной тематике было написано... Мама не горюй! :)))

В продолжение темы «линеек». Напрямую нас касается -> http://news.mail.ru/politics/6709686/?frommail=1 А вы говорите... Альт... Школота... :)))

> Им кажется, что ветка 3.1-rc2 неуязвима к тому конкретному эксплойту, что использовался у них, но они не в курсе было ли это намеренным фиксом эксплойта или выплыло случайно в процессе обычного багфикса.

Т.е. взломщики вошли на сервер git, получили рута через неизвестную уязвимость, после чего пофиксили эту уязвимость в исходниках новой ветки ядра.

> Т.е. взломщики вошли на сервер git, получили рута через неизвестную уязвимость, после чего пофиксили эту уязвимость в исходниках новой ветки ядра.

Какие молодцы. Прямо Тимур и его команда. «Трусы постирали, пирожки бабушке отнесли».

> FreeBSD alive!-атака

Ты хоть одного FreeBSD'оида видел? Их ничего кроме их BSD'ы не интересует (большинство). И уж тем более операционки, где мир пересобирать не надо.

> кажется, это был я О_о как положено чайнику, я тыкал на невесть-какие кнопочки на сайте kernel.org скачивая ядро как раз 28ого августа. О_о

Не-а, все было намного раньше. 28-го только обнаружили проблему: http://www.theregister.co.uk/2011/08/31/linux_kernel_security_breach/

Заражение произошло не позднее 12 августа и оставалось незамеченным еще 17 дней, согласно емейлу John «'Warthog9» Hawley, главного админа kernel.org, отправленного разработчикам в понедельник. В нем говорится, что троян был обнаружен на личной машине разработчика ядра H Peter Anvin, и позднее на серверах kernel.org, известных как Hera и Odin1 - ssh-клиент, используемый для удаленного доступа к серверам был изменен и записывал все пароли и действия пользователя.

> троян был обнаружен на личной машине разработчика ядра H Peter Anvin

Петька, ламер, тебе хана! Анонимус не прощает! Мы тебя из-под земли достанем и покараем!!1

после такого мы понимаем что ссл не всегда спасает...

http://www.opennet.ru/opennews/art.shtml?num=31652

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

Ну что? Полярная лиса подкрадывается?

:)

Таких детских эксплоитов миллион и еще тележку наклепать можно!

1. Нельзя работать под рутом!

2. Все диски на которых находятся исполняемые файлы должны быть смонтированы только для чтения!!

3. Используйте grsecurity!!! В данном случае опции romount_protect и Trusted Path Execution (TPE)

Соблюдение этих правил гарантирует практически 100% невозможность подмены ssh клиента, ну и других системных программ...

программист не может иметь диск с исполняемыми файлами только для чтения. Он же их меняет сам.

Да о чём ты мне шепчешь? Особо они нужны наверно программистам ядра:) Возможно при отладке и нужно держать диск с rw & exec но не надо это делать с / & /usr!!! Сделай себе отдельно: /home/proger/work с rw & exec

>Заражение произошло не позднее 12 августа и оставалось незамеченным еще 17 дней

Версиями линукса свежее чем весна этого года пользоватся не советую.. Лучше взять вообще зимнюю...

:)))

17 дней ничего не замечали. Неплохо.

Еще раз развеян миф о безопасности ляликс...

01.09.2011 14:32:58

линейка уже закончилась?

>3. Используйте grsecurity!!! В данном случае опции romount_protect и Trusted Path Execution (TPE)

echo 'ssh() {evil code goes here}' >> ~/.bashrc

Не говоря о том, что пользователи — разработчики. И как любые разработчики будут крайне рады таким ограничениям.

grsec можно использовать, да. Вместе с его RBAC. Но это требует грамотного сисадмина и время на настройку. Да и SELinux банально лучше при наличии грамотного сисадмина (впрочем, такой сисадмин — первое необходимое условие вменяемой безопасности.).

как страшно жить

первый вопрос - сколько лет этот взлом не был обраружен.

Второй - сколько других аккаунтов важных шишек с kernel.org было подломано за эти годы . Разумеется, все мы люди и иногда используем те же самые пароли или вроде СТАРЫЙПАОЛЬ~ СТАРЫЙПАОЛЬ1 что позволяет лисно мне все таки слегка запаниковать. Сколько патчей от этих сломаных аккаунтов было принято ЗА ВСЕ ГОДЫ присутствия этого трояна?