форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Kernel.org подвергся взлому"	+1 +/–
Сообщение от opennews on 01-Сен-11, 09:09
Обнаружен (http://pastebin.com/BKcmMd47) факт взлома нескольких серверов в инфраструктуре Kernel.org (https://www.kernel.org/), используемых для распространения архивов с исходными текстами и обслуживании Git-репозиториев с ядром Linux. Атакующим удалось получить root-доступ к серверам, модифицировать системное программное обеспечение (заменили ssh-сервер) и организовать перехват паролей разработчиков. По предположению администраторов проекта проникновение было совершено через утечку параметров одного из аккаунтов. Данное предположение подтверждает обнаружение троянского ПО на машине одного из разработчиков ядра, который имел доступ к двум взломанным серверам (Hera и Odin1). Тем не менее, пока не ясно как именно удалось поднять свои привилегии в системе, судя по всему был задействован эксплоит для еще публично не известной уязвимости. Факт взлома был выявлен 28 августа. Проникновение было совершено не позднее, чем 12 августа, при этом как минимум 17 дней злоумышленники оставал... URL: https://www.kernel.org/ Новость: http://www.opennet.dev/opennews/art.shtml?num=31651
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Kernel.org подвергся взлому"	+17 +/–
Сообщение от Вова on 01-Сен-11, 09:09
Немного жаль, что сегодня 1е сентября, а не апреля.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Kernel.org подвергся взлому"	+28 +/–
	Сообщение от Alen (??) on 01-Сен-11, 09:29
	Настоящему коту и в декабре - март ;)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	239. "Kernel.org подвергся взлому"	+/–
	Сообщение от Щекн Итрч (ok) on 02-Сен-11, 12:25
	> Настоящему коту и в декабре - март ;) Чем раньше, тем лучше. Если бы не бразильские братья (а это зверьё ещё то!) я бы так лаптем щи и хлебал бы. А взломщики меня взбодрили и мотивировали. И на «кернеле» теперь отработают систему восстановления после взлома и вообще.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	275. "Kernel.org подвергся взлому"	–2 +/–
	Сообщение от Аноним (??) on 02-Сен-11, 20:08
	> Если бы не бразильские братья (а это зверьё ещё то!) я бы > так лаптем щи и хлебал бы. Интересно, почему вы решили что ваши проблем с хлебанием щей волнуют кого-то кроме вас? > А взломщики меня взбодрили и мотивировали. Фиолетово. Зато не фиолетово что взбодрили админов кернел-орга. > И на «кернеле» теперь отработают систему восстановления после взлома и вообще. Git так устроен что там очень сложно подделать что либо задним числом. У всех есть полноценная копия репа. С теми же хешами. Если задним числом поменять что-то в каком-то git, то при его попытках синхронизации с другими - все синхронизирующиеся с ним увидят массовый отъезд хешей. А расхакать всех кто клонировал git до момента взлома - нереально. Мистеру Торвальдсу можно только поапплодировать за такую предусмотрительность. По сути он сделал то что обычно делают цифровыми подписями, обойдясь без публичных и приватных ключей, используя сам факт распределенности. К сожалению, далеко не у всех программ руководители проекта столь же мозгасты, и даже не всем хватает ума использовать git, который может выручить в трудную минуту (дотошно аудитить надо только то что после момента взлома было).
	Ответить | Правка | ^ к родителю #239 | Наверх | Cообщить модератору

	289. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 03-Сен-11, 15:27
	Git так устроен что там очень сложно подделать что либо задним числом. У всех есть полноценная копия репа. С теми же хешами. Если задним числом поменять что-то в каком-то git, то при его попытках синхронизации с другими - все синхронизирующиеся с ним увидят массовый отъезд хешей. А расхакать всех кто клонировал git до момента взлома - нереально. Мистеру Торвальдсу можно только поапплодировать за такую предусмотрительность. По сути он сделал то что обычно делают цифровыми подписями, обойдясь без публичных и приватных ключей, используя сам факт распределенности. К сожалению, далеко не у всех программ руководители проекта столь же мозгасты, и даже не всем хватает ума использовать git, который может выручить в трудную минуту (дотошно аудитить надо только то что после момента взлома было). Меттью Диллон однажды и перевел всю DragonFlyBSD и ее репы на git именно по этой причине
	Ответить | Правка | ^ к родителю #275 | Наверх | Cообщить модератору

	290. "Kernel.org подвергся взлому"	–1 +/–
	Сообщение от Щекн Итрч (ok) on 03-Сен-11, 17:55
	>> Git так устроен что там очень сложно подделать... А при чем тут Git, дорогой агрессивный и малопочтенный собеседник? Бэкдор это бэкдор. Или, если Git так неуязвим, пусть бэкдоры остаются? Не жалко, типа? :) :) :) И технология восстановления системы, не репов, раздающих код, а собственно, системы, на которой Git крутится, не нужна?
	Ответить | Правка | ^ к родителю #289 | Наверх | Cообщить модератору

	293. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 04-Сен-11, 06:47
	>>> Git так устроен что там очень сложно подделать... > А при чем тут Git, дорогой агрессивный и малопочтенный собеседник? > Бэкдор это бэкдор. > Или, если Git так неуязвим, пусть бэкдоры остаются? Не жалко, типа? :) > :) :) > И технология восстановления системы, не репов, раздающих код, а собственно, системы, на > которой Git крутится, не нужна? Ты почитай хоть какой кусок текст я процитировал прежде, чем ответ я написал
	Ответить | Правка | ^ к родителю #290 | Наверх | Cообщить модератору

	297. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 05-Сен-11, 15:44
	> Ты почитай хоть какой кусок текст я процитировал прежде, чем ответ я > написал Вы криво процитировали, в результате этот наивный чукотский юноша и перепутал двух анонимов.
	Ответить | Правка | ^ к родителю #293 | Наверх | Cообщить модератору

	298. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 05-Сен-11, 15:49
	> А при чем тут Git, дорогой агрессивный и малопочтенный собеседник? Какой эпичный набор взаимоисключающих параграфов. А git тут при том что на kernel.org кроме ядер в гитах - брать толком нечего. > Бэкдор это бэкдор. А Капитан это Капитан. > Или, если Git так неуязвим, пусть бэкдоры остаются? Не жалко, типа? :) :) :) Так написано же что будет сделан реинсталл. > И технология восстановления системы, не репов, раздающих код, а собственно, системы, на > которой Git крутится, не нужна? Всем давно известна - реинсталл под ноль назывется.
	Ответить | Правка | ^ к родителю #290 | Наверх | Cообщить модератору

2. "Kernel.org подвергся взлому"	–6 +/–
Сообщение от Wormik (ok) on 01-Сен-11, 09:12
Троянское ПО? У разработчика Linux?! Кто-нибудь знает, Касперский для Linux на том же уровне, что и для Windows?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Kernel.org подвергся взлому"	+11 +/–
	Сообщение от sndev (ok) on 01-Сен-11, 09:33
	Может просто не факт, что он подключался с линуховой машины на момент атаки ? Ну там с лаптопа любимой жены, или еще лучше блондинки любофницы :) Касперский на том же уровне - это в смысле, что пользоваться системой невозможно ? :)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	50. "Kernel.org подвергся взлому"	–4 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 01-Сен-11, 11:03
	> Может просто не факт, что он подключался с линуховой машины на момент атаки ? гнать таких разработчиков
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	81. "Kernel.org подвергся взлому"	–3 +/–
	Сообщение от cybermax on 01-Сен-11, 12:26
	а вы давно касперским пользовались?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	84. "Kernel.org подвергся взлому"	+2 +/–
	Сообщение от sndev (ok) on 01-Сен-11, 12:46
	угу. давно. Лет 10, как минимум, назад. Просто он мне напаркуа не сдался.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	85. "Kernel.org подвергся взлому"	+7 +/–
	Сообщение от anonymous (??) on 01-Сен-11, 12:47
	> а вы давно касперским пользовались? не ставится, зараза, под вайном. давно.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	103. "Kernel.org подвергся взлому"	+/–
	Сообщение от filosofem (ok) on 01-Сен-11, 14:06
	>а вы давно касперским пользовались? Знаю множество несчастных, которым его впарили. Подтверждаю, даже чистая система становится неюзабильной и часто вообще не загружается.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	184. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 22:23
	> Знаю множество несчастных, которым его впарили. Подтверждаю, даже чистая система становится > неюзабильной и часто вообще не загружается. Кроме того, его методы защиты являют собой самый обычный руткит, который и защищает антивирус от удаления. Проблема только в том что немелкая блобятина с полномочиями руткита и автоапдейтом в моей операционке душу как-то совсем не греет. Спасибо за такую защиту, конечно, но я лучше пешком постою. А какие у меня основания доверять большому блобу с правами руткита?
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	288. "Kernel.org подвергся взлому"	–1 +/–
	Сообщение от stimpack on 03-Сен-11, 09:14
	Еще оно в грязных вещах хозяина копается без угрызений совести. поймал гада за руку на принудительной кривой и нахер не нужной перекодировке символов у юзера пришедшего через почтовый клиент html-письма. Видимо, готовил report для отсылки в центральную базу и сразу правил-резал на живом письме. Или просто баловался, надувал щеки и симбурде.
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

	83. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от BratSinot on 01-Сен-11, 12:29
	А что такого? Трояны и черви есть на любой ОС, просто в *nix сложность в правах доступа.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	87. "Kernel.org подвергся взлому"	+4 +/–
	Сообщение от Аноним (??) on 01-Сен-11, 12:51
	Скорее в том что просто выложить их на варезник - недостаточно для скачки и запуска юзерами. А убедить майнтайнеров добавить в репы троян - задачка нетривиальная.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	126. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от brother anon on 01-Сен-11, 15:11
	Скорее в том, что десктопный линукс это неуловимый Джо. Будет популярность будет и "rpm бесплатно скачать ильхам зюлькорнеев".
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	188. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 22:27
	> Будет популярность будет и "rpm бесплатно скачать ильхам зюлькорнеев". В паре с инструкцией как инстальнуть gpg ключ или форсануть инсталл недоверяемого пакета, да? И какой процент хомяков это осилит? :) А тот кто это осилит - скорее такой файл отощлет антивирусникам + зарепортит сайт с малварью и браузеры начнут дико выть еще при входе на оный. При том большая красная табличка надежно отпугивает даже полного хомяка :)
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	240. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от brother anon on 02-Сен-11, 12:32
	> В паре с инструкцией как инстальнуть gpg ключ или форсануть инсталл недоверяемого > пакета, да? И какой процент хомяков это осилит? :) А какие проблемы? Мы же о user-friendly дистрибутивах говорим, правда? Вот возьмем например дружественную пользователю opensuse. В ней есть one click install: пользователь скачивает специальный файлик в котором написано из какого репозитория и какой пакет надо установить. Если репозиторий ещё не подключён он подключается, в этом случае система спрашиват у пользователя надо доверять этому репо. Как думаешь нажмёт ли хомячок кнопку "Да"?
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	281. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 02-Сен-11, 23:59
	> Как думаешь нажмёт ли хомячок кнопку "Да"? К счастью я не юзаю опенсусь и не знаю хомяков с ней. А хомяки с убунтой от такой напасти избавлены.
	Ответить | Правка | ^ к родителю #240 | Наверх | Cообщить модератору

	264. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от Клыкастый (ok) on 02-Сен-11, 19:29
	> Скорее в том, что десктопный линукс это неуловимый Джо. Либо парням из kernel.org показалось, либо вы неправы.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	272. "Kernel.org подвергся взлому"	–1 +/–
	Сообщение от Аноним (??) on 02-Сен-11, 19:54
	> Кто-нибудь знает, Касперский для Linux на том же уровне, что и для Windows? Тормозам типа вас никакой каспер не поможет, особенно если атакующий задался целью вздуть именно вас. Как вы думаете, насколько сложно упаковать даже общеизвестный троян пакером так что антивирус перестанет его опознавать? Замена мозгу нужна только тем у кого его нет. Правда, такие интересны только как ресурсный придаток и потому сколь-нибудь скоординированную атаку на таких как вы никто делать не станет - вы из себя ценности не прдставляете.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Kernel.org подвергся взлому"	+/–
Сообщение от поцанчик (ok) on 01-Сен-11, 09:13
Ну и прально, в следующий раз не будут зевать.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "Kernel.org подвергся взлому"	–60 +/–
	Сообщение от bezopasnik.org (ok) on 01-Сен-11, 10:37
	> Ну и прально, в следующий раз не будут зевать. Да дело даже не в том что зевали После фразы: > В будущем в профилактических целях планируется полностью переустановить систему и на остальных серверах Очередной раз поражаюсь дибилизму среди луноходов Еще несколько лет назад задавал вопрос одному луноходу - а что делать после того как выявлен факт взлома ? он мне не задумываясь ответил - переставлять систему просто крындец, безмозглость
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	41. "Kernel.org подвергся взлому"	+7 +/–
	Сообщение от Ващенаглухо (ok) on 01-Сен-11, 10:48
	это первое, что нужно сделать. В чем тут безмозглось? или вас не волнуют руткиты?
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	42. "Kernel.org подвергся взлому"	+6 +/–
	Сообщение от anton7811 (ok) on 01-Сен-11, 10:53
	Раскажите свой вариант, что делать.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	48. "Kernel.org подвергся взлому"	+8 +/–
	Сообщение от anonymous (??) on 01-Сен-11, 10:59
	> Раскажите свой вариант, что делать. видимо, расслабиться и получать удовольствие. и не мешать руткиту работать, он же делом занят.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	59. "Kernel.org подвергся взлому"	–18 +/–
	Сообщение от bezopasnik.org (ok) on 01-Сен-11, 11:15
	> Раскажите свой вариант, что делать. Существуют как минимум 4 способа проверки целостности на изменение файлов в системе да хотя б для начала контрольные суммы собрать со всей системы, дату изменения конечно можно подставить свои. SELinux на кой Вам ???
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	60. "Kernel.org подвергся взлому"	+5 +/–
	Сообщение от anonymous (??) on 01-Сен-11, 11:21
	ты живой руткит-то видел хоть раз? "проверка целостности файлов", ага. с неизвестным руткитом.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	61. "Kernel.org подвергся взлому"	+7 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Сен-11, 11:24
	Только все эти способы НЕ ГАРАНТИРУЮТ, что вы всё вычистите. Вы так уверены, что ничего не пропустите? Вы уверены, что нарушители спокойствия не воспользовались какой-то неизвестной вам (и, возможно, практически всему человечеству) возможностью? Вы так уверены, что где-то не осталось нечаянно включённой в прошлый раз дырки, через которую (тоже) можно попасть в систему? Полная переустановка — единственный надёжный способ. В любой операционной системе. Всё остальное, весь контроль целостности, нужен для диагностики.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	68. "Kernel.org подвергся взлому"	+7 +/–
	Сообщение от anonymous (??) on 01-Сен-11, 11:37
	господа модераторы! не трогайте его, пожалуйста. веселит же. бесплатный клоун на выезде.
	Ответить | Правка | ^ к родителю #240 | Наверх | Cообщить модератору

	108. "Kernel.org подвергся взлому"	+3 +/–
	Сообщение от Аноним (??) on 01-Сен-11, 14:24
	>Я согласен что есть руткиты которые сидят только в памяти но такое можно определить в считанные секунды Дядя Женя Касперский нервно курит в сторонке.
	Ответить | Правка | ^ к родителю #240 | Наверх | Cообщить модератору

	170. "Kernel.org подвергся взлому"	+/–
	Сообщение от Анон on 01-Сен-11, 18:59
	Ну и собирай тогда бинари вручную, ептыть, в чем проблема? Можешь даже свой локальный реп создать закрытый от внешней среды и из него ставиться.
	Ответить | Правка | ^ к родителю #240 | Наверх | Cообщить модератору

	201. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 23:27
	> Я согласен что есть руткиты которые сидят только в памяти Он может и на диске сидеть. Что если бяка, получив управление, немного допатчит в ядре сисколы чтения файлов чтобы они его тело никода не возвращали, даже если оно на самом деле там физически и было? Техника стара как х86 проц, в досе такое называлось stealth-вирусами. Времена шли, ОС менялись, но потенциальная возможность этой техники никуда не пропала. > но такое можно определить в считанные секунды, теоретически можно запихать руткит Универсальный и надежный способ это сделать - в студию. Известный метод засечения руткитов сводится к поиску аномалий в поведении разных сисколов. И да, руткит в общем случае не может полностью спрятаться. Но даже после этого надежно вычистить руткит может быть проблематично, просто потому что он со своей стороны может саботировать эти потуги просто заворачивая выполнение соотв. системных вызовов. А что ему помешает понять что вызов его затирает, сообщить в результате сискола что ок, было сделано, но забыть собственно перезаписать себя при этом? :))) > и в железо - преценденты уже такие были, тогда уже даже и переустановка > системы не поможет В железо - сложно. Низкоуровневая ранняя инициализация железа типа чипсетов - кастомна, и биос специфичен для своей мамки. И даже ранний бутблок проверяет как минимум чексумму биоса. Мало-мальски универсальный троянец получится нереально геморным в написании. Как самый максимум, был WinCIH но все на что его хватало - просто стереть BIOS. Это намного проще, тем более если ограничиться 1 чипсетом как он и делал :) > Больше волнует то что неизвестно на сколько достоверно в софте линуховом - > исходники могут быть одни а бинарники в репазитарии лежать другие и > проверить это практически не возможно Подменить бинарники достаточно сложно - они подписями обвешаны. Просто замена бинаря на сервере приведет к визгам пакетного манагера что подпись не совпала, отсутствует или ключ неизвестный, что очень быстро спалит хацкера при практически нулевой результативности атаки. Кстати был случай когда в программе (inrealircd) подменили именно сырец, впихнув довольно кондовый бэкдор. Гентушники даже успели его пересобрать и раздать :))
	Ответить | Правка | ^ к родителю #240 | Наверх | Cообщить модератору

	210. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Сен-11, 23:46
	Справедливости ради поправлю по двум пунктам: >> и в железо - преценденты уже такие были, тогда уже даже и переустановка >> системы не поможет > В железо - сложно. Низкоуровневая ранняя инициализация железа типа чипсетов - кастомна, > и биос специфичен для своей мамки. И даже ранний бутблок проверяет > как минимум чексумму биоса. Мало-мальски универсальный троянец получится нереально геморным > в написании. Как самый максимум, был WinCIH но все на что > его хватало - просто стереть BIOS. Это намного проще, тем более > если ограничиться 1 чипсетом как он и делал :) Есть уже прототипы, которые себя в BIOS пишут. Не любой матери — но большинства распространённых. BIOS'ы нынче на x86 жирные и не сильно отличающиеся у одного производителя пошли, несколько килобайт места найти не проблема. Универсальные прошивальщики, знающие о многих BIOS'ах разом, видели? Дальше, думаю, понятно. >> Больше волнует то что неизвестно на сколько достоверно в софте линуховом - >> исходники могут быть одни а бинарники в репазитарии лежать другие и >> проверить это практически не возможно > Подменить бинарники достаточно сложно - они подписями обвешаны. Просто замена бинаря на > сервере приведет к визгам пакетного манагера что подпись не совпала, отсутствует > или ключ неизвестный, что очень быстро спалит хацкера при практически нулевой > результативности атаки. Да, вот только эти визги сработают лишь при обновлении софта. Поздновато будет. Ежедневные (или даже ещё более частые) проверки целостности — уже лучше, особенно если заблокировать изменение файлов, отвечающих за выполнение проверок, для всех, включая рута. Правда, обновление системы при этом станет более гиморным, особенно в большинстве Linux-дистрибутивов, где система вся состоит из пакетов. Ну да это уже совсем отдельная тема.... > Кстати был случай когда в программе (inrealircd) подменили именно сырец, впихнув довольно > кондовый бэкдор. Гентушники даже успели его пересобрать и раздать :)) Да таких случаев уже не так и мало. В своё время даже исходники OpenSSH подменяли — взломали ftp.openbsd.org (проекту OpenBSD он не принадлежит и поэтому не контролируется; работает машина, кажется, на Солярке). Инцидент оставался незамеченным около пары суток.
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

	246. "Kernel.org подвергся взлому"	+5 +/–
	Сообщение от Аноним (??) on 02-Сен-11, 12:46
	> Есть уже прототипы, которые себя в BIOS пишут. Не любой матери — > но большинства распространённых. Ну cih стирал только мамки с чипсетом Intel TX. Это был самый популярный в тот момент и принесло некоторую известность. На остальных фокус не работал, разумеется. > BIOS'ы нынче на x86 жирные и не сильно отличающиеся у одного производителя пошли, Чипсеты и чипы флеш-памяти весьма разнообразны. А чтоб в них таких еще и запатчить что-то, попутно не угробив систему до unbootable - высший пилотаж. А если учесть что ядро и его загрузчики постоянно меняются да еще и по разному сделаны в разных пингвинах и прочих... не, ну теоретически вроде можно, но практически такое дикое количество сочетаний получается, что кодить убьешься. К тому же всякие асусы и гигабайты, да и не только - очень любят кастомизировать биосы (и их прошивалки) под себя. Поэтому оно хоть и на основе стандартного, но имеет кучу левых особенностей, делающих их не всегда совместимыми с стандартными утилитами и прочая. Т.е. сделать нечто на 1 случай не вопрос. А вот чтобы работало более-менее универсально, с разными ос и версиями/апдейтами оных - вот это уже ж--а. К тому же просто вписаться - недостаточно. Биосы имеют свойство проверять чексумы или даже подписи. Об этом хотелось бы поподробнее заметить. В современных BIOS замечена инфраструктура для проверки цифровых подписей. Вам это о чем-то говорит? Кстати, в полной версии trusted computing нелегитимная модификация биоса приведет к просто отказу предыдущей части его запускать, так что сие потеряет смысл в качестве трояна. Правда, "небольшая" проблема лишь в том, что нынче данный вид технологии, будучи способен защитить юзера от хакеров очень кардинальными, термоядерными средствами, на практике гораздо чаще защищает производителя и медиа-барыг. От пользователя. Который считается чем-то типа хакера. В общем абсолютный максимум до чего можно довы... - до активации trusted computing в каждом компе, а с этим лично я вас не поздравлю, т.к. есть риск что после этого вы вообще будете кушать Единственно Правильную Систему (tm), "для вашего же блага", ту которую "минздрав" одобрит. Ну как в ифоне примерно. Там trusted boot уже реализован и активирован. И заставляет следовать генеральной линии компартии^W яблочной секты. С другой стороны, это очень мощное средство контроля целостности и построения системы которая доверяма на все сто. Только вот не принято мощные инструменты в неандертальские лапы отдавать. > несколько килобайт места найти не проблема. Это - да, только вот впатчиться туда и чтобы ничего не отвалилось, не убилось и чтоб потом ОС при загрузке запатчилась - убиться можно кодить. А после парочки неожиданных факапов вероятно вредитель будет обнаружен. Учтя что на этой планете очень немного людей которые вообще понимают как все это работает - весьма рисковенько получается. Так можно надолго за решетку угодить, пожалуй. > Универсальные прошивальщики, знающие о многих BIOS'ах разом, видели? Дальше, думаю, понятно. Видел. Flashrom называется. Есть в пакетах линя, даже с исходниками. Но даже он... - На знает все чипы флеша. - Не все чипсеты поддерживает. - Ряд мамок, особенно от гигабайта - с двойным биосом. Чип с базовой версией перешить проблематично, насколько я знаю. - На куче мамок нынче обитает кастомная "полуаппаратная" защита от незапланированной записи в флеш: до того как получится писать в флеш, надо поменять состояние некоего I/O пина чипсета, посаженного на вывод "write protect" флешки, например. При том, каждый производитель мамок норовит поюзать тот пин чипсета который удобен лично ему (в плане его разводки по плате или просто по вкусу левой пятке). Как делать разрешение записи - ну родной фирменный прошиватор знает. Учтя что это знание актуально в рамках только 1 чипсета, 1 производителя мамки и едва ли нескольких моделей мамки - довольно сложно набрать базу на вообще все мамки в мире. Тот же flashrom например умеет шить далеко не все, очень много - совершенно без гарантий и "ну попробуйте, на свой страх и риск, если у вас есть рядом второй PC и программатор". Кстати, на подумать: например у интела в ноутах "BIOS" по факту содержит намного больше чем BIOS. В той же флешке низкоуровневые конфигурационные параметры ранней инициализации, фирмваре небольшого служебного системного процессора управляющего питанием/вентилями/прочая, фирмваре сетевой карты, etc, etc. А то что видно как BIOS - лишь часть этого айсберга на самом деле.Формально, чипсет вообще не дает доступа в эти области на запись (теоретически). А вот как оно там практически (а также что делают эти фирмвары и нет ли там багов и бэкдоров) - другой вопрос. >> сервере приведет к визгам пакетного манагера что подпись не совпала, отсутствует >> или ключ неизвестный, что очень быстро спалит хацкера при практически нулевой >> результативности атаки. > Да, вот только эти визги сработают лишь при обновлении софта. Поздновато будет. Что значит - поздновато? Пакет с кривой подписью можно поставить если вручную это форсануть. Ну если вы это форсанули - вы наверное знали на что шли, или где?! > Ежедневные (или даже ещё более частые) проверки целостности — уже лучше, В случае именно руткита - может и не помочь, поскольку злобный руткит вполне может немного "поправить" системные вызовы. Допустим подшили вы себя (руткит) к некоему файлу. Ну допустим в хвост. Пусть добавив еще 2Кб. Тогда при вопросе какой размер файла - надо соврать на 2 кб, а при чтении более чем (истинный размер - 2кб) - врать что там ошибка чтения. Ну и запись заодно можно перехватить. Или не выполнять ее в этот файл совсем но наврать что успешно записали, или перезаписать файло, но опять дописаться в хвост - в зависимости от лени, наглости и фантазии автора руткита :). Реально чуть сложнее, но я думаю идея понятна. При правильной реализации - файл будет при своем старте сперва выполнять руткита, а потом уже полезную прогу. А вот при попытке чтения будет видно только полезную прогу. Без пришитого к ней руткита. Очевидно, при идеальной реализации хуков на сисколы, чексум файла окажется без изменений :). И единственный метод заметить грабли - это читать физический девайс, парсить файловую систему в проге-сканере самостоятельно и смотреть совпало ли содержимое файла с тем что через сисколы ОС видится. Примерно так некоторые антивирусы и делают. Только вот опять же - руткит может и чтение физического девайса перехватить, в принципе, и или виртуализануть и его, или просто самоликвидироваться на всякий пожарный, избежав поимки и изучения. Ну, можно конечно и это обойти, прямым программированием железа в обход дров ОС вообще, но крайне грабельно, клещится с ОС и вообще полный головняк, хотя некоторые антивирусы и такое тоже делали, но это уже начинает попахивать изобретением своей операционки. ИМХО чем все эти извращения, проще и надежнее просто загрузиться с ридонли носителя и заведомо чистой ОС ;).Хотя с программингом железа через регистры пожалуй даже самый злостный вирь в биосе ничего поделать не сможет. Сложно это - понять что вы сектора с руткитом попросили вон теми записями в регистры и перехватить все это. Из особо неожиданных методов могу предложить хакинг PCI девайсов. У них во первых часто есть option ROM (иногда прошиваемые, довесок к BIOS) а сам девайс умеет вбабахивать DMA "куда попросишь" зачастую. Так что если удалось сломать фирмваре контроллера девайса (это не BIOS!) - можно попробовать убедить девайс сделать запись в память через DMA, например. Кстати FireWire по этой причине можно официально считать бэкдор-разъемом. Интерфейс умеет DMA и тот кто к нему приаттачился потенциально контролирует содержимое оперативы, со всеми вытекающими. Еще наверное очень смешно пропатчить фирмвару винча или сидюка чтобы тот в нужный момент подпихивал "неправильный" сектор. Только представьте себе - вирус который упорно воскресает после лечения :). Или который появляется на CD, независимо от того какой CD в привод засунули :). Правда в силу очень разного железа, постоянных перетрясов модельных рядов и прочее - опять же: сделать PoC - можно. Сделать что-то универсальное - сомнительно. Кстати могу предложить метод поимки пакости переписывающей BIOS "на живца" - "виртуальная флешка BIOS". Берем микроконтроллер, пишем на оном эмулятор SPI-флеша. Который не только отдает по SPI чипсету образ bios в нужный момент, но и логгит подозрительные потуги записи и вообще может издеваться над вредителями как хочет. Руткит может и не знать, но флеха которую он собирается переписать - тоже как-то не обязана быть доверяемой и играющей по именно его правилам и вполне может быть гнусной эмуляцией. Можно его даже обмануть что мы тут типа записали ваш новый биос, аж два раза. А отдавать старый образ из загашников все-равно :P. Таким наглым маневром можно вероятно обдурить даже фирменные утилиты-флешеры, которые поверят в то что они, типа, заапдейтили. Особо злые софтварщики могут написать эмулятор эмулирующий чипсет и флеху и сделать то же самое но чисто программно. Для отлова и изучения пакости сойдет, хотя реализовывать чипсет с докой на ~1000 страниц немного утомительно, разумеется :). Ну как, теперь паранойя не даст вам спать? :))) > особенно если заблокировать изменение файлов, отвечающих за выполнение проверок, Если ядро взято под контроль руткитом, реализуемые им системные вызовы могут возвращать НЕДОСТОВЕРНЫЕ данные. Не соответствующие истинной картине. Покуда ваша программа написана стандартным методом ака "делаем сискол - разгребаем результаты" - она имеет все шансы быть обдуреной. Т.е. чтение файла может и не показать изменений. Но это не значит что то же самое фактически прочлось при первом запуске этого файла, ну а потом оно пропатчило сисколы и стало всем радостно врать что там ничего нет ;). Теоретически вы можете конечно написать программу - дисковый ревизор, который прямым доступом к диску в обход сисколов прочитает сектора, распарсит их сам вместо ядра и драйвера ФС, но по-моему, проще и надежнее перегрузиться с readonly диска. Где то же самое сделает заведомо исправная копия ядра и ОС и не будет шансов что руткит обнаружит проблемы :) > для всех, включая рута. Вы хотите запретить ядру что-то делать? При том что оно же эти запреты расставляет и контролирует? Хотеть не вредно ;P. Если вы еще не поняли, наиболее проблемный класс руткитов - это которые меняют обработку сисколов ядром (а поскольку RAM в общем то по природе своей read-write, всегда остается ненулевая вероятность что образ ядра в памяти тем или иным методом будет слегонца запатчен в случае взлома). > Правда, обновление системы при этом станет более гиморным, особенно > в большинстве Linux-дистрибутивов, где система вся состоит из пакетов. Ну да > это уже совсем отдельная тема.... Уж простите конечно, но ваши понятия о руткитах - на уровне пещерного человека. >> кондовый бэкдор. Гентушники даже успели его пересобрать и раздать :)) > Да таких случаев уже не так и мало. В своё время даже > исходники OpenSSH подменяли — взломали ftp.openbsd.org В этом плане подменять готовые пакеты на сервере явно сложнее - они подписаны и проверка при установке делается. Что пакетов с бинарями, что с сырцами. И такие номера - не катят. > (проекту OpenBSD он не принадлежит и поэтому не контролируется; За отмазку не считается. Тоже мне безопаснички, без своего сервера. Ну вашу двадцать, если вы бомжуете, денег едва хватило на последние штаны, а на сервак уже не осталось - киньте клич! Сообщите про это! Попросите, блин, адресно задонейтить - на цель "сервак и его оплата". Учтя количество юзеров SSH - денег накидают, ИМХО. > работает машина, кажется, на Солярке). Инцидент оставался > незамеченным около пары суток. Sh... happens. Но по-моему, когда безопаснички отвечают за чужие FAILы - это идиотизм чистой воды.
	Ответить | Правка | ^ к родителю #210 | Наверх | Cообщить модератору

	250. "Kernel.org подвергся взлому"	–1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 02-Сен-11, 14:07
	>> Есть уже прототипы, которые себя в BIOS пишут. Не любой матери — >> но большинства распространённых. > Ну cih стирал только мамки с чипсетом Intel TX. Это был самый > популярный в тот момент и принесло некоторую известность. На остальных фокус > не работал, разумеется. И тем не менее шороху наделал изрядно. Ведь для зловредов «массового поражения» не обязательно поддерживать всё. Это ведь бизнес. Разработка и прочие расходы должны банально окупаться доходами. Если целевая платформа популярна, удельные затраты будут низкие, вот и всё. >[оверквотинг удален] > пилотаж. А если учесть что ядро и его загрузчики постоянно меняются > да еще и по разному сделаны в разных пингвинах и прочих... > не, ну теоретически вроде можно, но практически такое дикое количество сочетаний > получается, что кодить убьешься. К тому же всякие асусы и гигабайты, > да и не только - очень любят кастомизировать биосы (и их > прошивалки) под себя. Поэтому оно хоть и на основе стандартного, но > имеет кучу левых особенностей, делающих их не всегда совместимыми с стандартными > утилитами и прочая. Т.е. сделать нечто на 1 случай не вопрос. > А вот чтобы работало более-менее универсально, с разными ос и версиями/апдейтами > оных - вот это уже ж--а. Повторюсь, прототипы УЖЕ ЕСТЬ. Может, есть и боевые, но про то я не в курсе. > К тому же просто вписаться - недостаточно. Биосы имеют свойство проверять чексумы > или даже подписи. Своего кода — да. А как насчёт ACPI, например? В его километровых таблицах можно что угодно творить... > Об этом хотелось бы поподробнее заметить. В современных BIOS замечена инфраструктура для > проверки цифровых подписей. Вам это о чем-то говорит? Говорит. Только проверяется не всё подряд. Потому что CMOS, например, или те же ACPI-таблицы никто подписывать не будет. >[оверквотинг удален] > на практике гораздо чаще защищает производителя и медиа-барыг. От пользователя. Который > считается чем-то типа хакера. В общем абсолютный максимум до чего можно > довы... - до активации trusted computing в каждом компе, а с > этим лично я вас не поздравлю, т.к. есть риск что после > этого вы вообще будете кушать Единственно Правильную Систему (tm), "для вашего > же блага", ту которую "минздрав" одобрит. Ну как в ифоне примерно. > Там trusted boot уже реализован и активирован. И заставляет следовать генеральной > линии компартии^W яблочной секты. С другой стороны, это очень мощное средство > контроля целостности и построения системы которая доверяма на все сто. Только > вот не принято мощные инструменты в неандертальские лапы отдавать. Боюсь, всё ещё немного сложнее. Как минимум потому, что сводится всё по сути к двум схемам: а) ключ для доступа (подписи или ещё что, не суть) к системе доступен пользователю, и тогда техническая надёжность системы будет компенсироваться успехами социальной инженерии; б) ключ не доступен пользователю, а лежит где-то в централизованном хранилище — и тогда объектом атаки будет становиться данное хранилище. Как это с HDCP было, например. >> несколько килобайт места найти не проблема. > Это - да, только вот впатчиться туда и чтобы ничего не отвалилось, > не убилось и чтоб потом ОС при загрузке запатчилась - убиться > можно кодить. Боюсь, вы переоцениваете. Конечно, не все BIOS'ы одинаковые, но большая часть (т.е. под неё выгодно этими разработками заниматься) x86-материнок достаточно типовая. Более того, устройства от Apple, например, тоже становятся очень лакомой мишенью, т.к. количество моделей мало, а аппаратов — велико... > А после парочки неожиданных факапов вероятно вредитель будет обнаружен. Ну что ж, на его место придёт следующий. :) > Учтя что на этой планете очень немного людей которые вообще понимают > как все это работает - весьма рисковенько получается. Так можно надолго > за решетку угодить, пожалуй. Вы это скрипткидисам говорите, которые шальными эксплоитами роняют сайты быстро злящихся дядь и тёть. :) >> Универсальные прошивальщики, знающие о многих BIOS'ах разом, видели? Дальше, думаю, понятно. > Видел. Flashrom называется. Есть в пакетах линя, даже с исходниками. > Но даже он... > - На знает все чипы флеша. > - Не все чипсеты поддерживает. Ну и что, что не все — вполне достаточно для массового распространения. > - Ряд мамок, особенно от гигабайта - с двойным биосом. Чип с > базовой версией перешить проблематично, насколько я знаю. Дык до перепрошивки ещё дойти надо. Надо тварь обнаружить. А чем? Ни одного надёжного способа, кроме исследования микросхемы BIOS в лабораторных условиях, нет по определению. > - На куче мамок нынче обитает кастомная "полуаппаратная" защита от незапланированной записи > в флеш: до того как получится писать в флеш, надо поменять > состояние некоего I/O пина чипсета, посаженного на вывод "write protect" флешки, > например. При том, каждый производитель мамок норовит поюзать тот пин чипсета > который удобен лично ему (в плане его разводки по плате или > просто по вкусу левой пятке). Как делать разрешение записи - ну > родной фирменный прошиватор знает. Учтя что это знание актуально в рамках > только 1 чипсета, 1 производителя мамки и едва ли нескольких моделей > мамки - довольно сложно набрать базу на вообще все мамки в > мире. Не так уж и сложно, было бы желание. Прошивальщики-то обычно однотипные сами по себе у одного производителя. Сначала ищется, где в нём эти сведения зашиты, а потом для остальных моделей вытаскивается в полуавтоматическом режиме. > Тот же flashrom например умеет шить далеко не все, очень > много - совершенно без гарантий и "ну попробуйте, на свой страх > и риск, если у вас есть рядом второй PC и программатор". А зачем мне-то пробовать? Я зловреды не пишу. А авторы зловредов не будут сильно переживать, если что-то накроется... Ну то есть, конечно, они заинтересованы в том, чтобы не накрывалось. Но не настолько, чтобы плакать горючими слезами над каждым убитым чужим BIOS'ом. > Кстати, на подумать: например у интела в ноутах "BIOS" по факту содержит > намного больше чем BIOS. В той же флешке низкоуровневые конфигурационные параметры > ранней инициализации, фирмваре небольшого служебного системного процессора управляющего > питанием/вентилями/прочая, фирмваре сетевой карты, etc, etc. А то что видно как > BIOS - лишь часть этого айсберга на самом деле.Формально, чипсет вообще > не дает доступа в эти области на запись (теоретически). А вот > как оно там практически (а также что делают эти фирмвары и > нет ли там багов и бэкдоров) - другой вопрос. Угу... >>> сервере приведет к визгам пакетного манагера что подпись не совпала, отсутствует >>> или ключ неизвестный, что очень быстро спалит хацкера при практически нулевой >>> результативности атаки. >> Да, вот только эти визги сработают лишь при обновлении софта. Поздновато будет. > Что значит - поздновато? Пакет с кривой подписью можно поставить если вручную > это форсануть. Ну если вы это форсанули - вы наверное знали > на что шли, или где?! Мы о разных вещах говорим. Я-то про изменение уже имеющихся в системе файлов писал, а не установку «гнилого» пакета. >> Ежедневные (или даже ещё более частые) проверки целостности — уже лучше, > В случае именно руткита - может и не помочь, Естественно. Это второй или третий, и отнюдь не последний, уровень обнаружения вторжений. Дальше я убрал написанное, ибо - поверьте - в курсе. :) >[оверквотинг удален] > как хочет. Руткит может и не знать, но флеха которую он > собирается переписать - тоже как-то не обязана быть доверяемой и играющей > по именно его правилам и вполне может быть гнусной эмуляцией. Можно > его даже обмануть что мы тут типа записали ваш новый биос, > аж два раза. А отдавать старый образ из загашников все-равно :P. > Таким наглым маневром можно вероятно обдурить даже фирменные утилиты-флешеры, которые > поверят в то что они, типа, заапдейтили. Особо злые софтварщики могут > написать эмулятор эмулирующий чипсет и флеху и сделать то же самое > но чисто программно. Для отлова и изучения пакости сойдет, хотя реализовывать > чипсет с докой на ~1000 страниц немного утомительно, разумеется :). Это уже не обнаружение вторжений, а разбор полётов после... > Ну как, теперь паранойя не даст вам спать? :))) Сплю как убитый. ;) >> особенно если заблокировать изменение файлов, отвечающих за выполнение проверок, > Если ядро взято под контроль руткитом, реализуемые им системные вызовы могут возвращать > НЕДОСТОВЕРНЫЕ данные. Да. Я в курсе. Возможно, я не совсем ясно выразился — приношу свои извинения. >> Правда, обновление системы при этом станет более гиморным, особенно >> в большинстве Linux-дистрибутивов, где система вся состоит из пакетов. Ну да >> это уже совсем отдельная тема.... > Уж простите конечно, но ваши понятия о руткитах - на уровне пещерного > человека. Это было уже не об аппаратных руткитах, повторюсь, а о других попытках незаметно закрепиться в системе. Руткит — не обязан работать на уровне ядра. :) Конечно, он при этом легче отлавливается, но если уж другого способа нет — пусть так, чем никак. :) >>> кондовый бэкдор. Гентушники даже успели его пересобрать и раздать :)) >> Да таких случаев уже не так и мало. В своё время даже >> исходники OpenSSH подменяли — взломали ftp.openbsd.org > В этом плане подменять готовые пакеты на сервере явно сложнее - они > подписаны и проверка при установке делается. Что пакетов с бинарями, что > с сырцами. И такие номера - не катят. Подписанные — сложнее, да. Впрочем, когда это было-то... >> (проекту OpenBSD он не принадлежит и поэтому не контролируется; > За отмазку не считается. Тоже мне безопаснички, без своего сервера. Ну звиняйте. Можно систематически бросать далеко не бесконечные ресурсы на собственный ftp.openbsd.org, а можно что-то исправлять и дополнять в самой системе. Ну да это отдельный разговор. > Ну вашу > двадцать, если вы бомжуете, денег едва хватило на последние штаны, а > на сервак уже не осталось - киньте клич! Сообщите про это! > Попросите, блин, адресно задонейтить - на цель "сервак и его оплата". > Учтя количество юзеров SSH - денег накидают, ИМХО. Купить сервак — это одно. А интернет-канал толстый поддерживать кто будет и на какие деньги, например? Вы знаете, сколько стоят честные 100 Мбит/с в нормальном датацентре? «Киньте клич»... Будьте реалистом. >> работает машина, кажется, на Солярке). Инцидент оставался >> незамеченным около пары суток. > Sh... happens. Но по-моему, когда безопаснички отвечают за чужие FAILы - это > идиотизм чистой воды. Идиотизм — это когда утащили у конторы Самый Главный Электронный Сертификат, а контора вместо того, чтобы быстренько заиметь другой, ждёт у моря погоды, пока опростоволосившийся выпускатор сделает ей новый. А тут — тоже нехорошо, конечно, но, как показывает практика, FAIL'ы бывают у всех. Весь вопрос — насколько серьёзные и насколько долго. :)
	Ответить | Правка | ^ к родителю #246 | Наверх | Cообщить модератору

	278. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 02-Сен-11, 23:43
	> И тем не менее шороху наделал изрядно. Ведь для зловредов «массового поражения» > не обязательно поддерживать всё. Я склонен его считать просто удачным PoC`ом (и плосковатой шуткой над пользователями). Автор даже не пытался зарабатывать. Это лишь демо умений кодера и технических возможностей. В нем было сразу много чего необычного: - Обход колец защиты i386, правда только в win9x. В НТях не работало, там изоляция юзера от кернела менее халявная. - Прямой программинг железа под виндой. Олдскул показал что и на новых рельсах себя неплохо чувствует, сделав то что даже любители доса не осиливали. - Флеш до этого момента никто сносить > Это ведь бизнес. Wrong. Такие вещи - делаются как искусство. Черная магия. От злых волшебников. Но все-таки, временами у них получаются довольно красивые штуки. Хоть и зловредные по природе своей. > Разработка и прочие расходы должны банально окупаться доходами. Не вижу как можно было поиметь денег за CIH. Наиболее реальное что там можно поиметь - увесистый срок в случае поимки, т.к. это вполне ощутимая порча оборудования будет суду более понятна чем эфемерное стирание пары файлов ;) Те кого волнует бизнес - скорее всего покупают у хардкорных реверсеров свежий сплойт на 0day дыры для ишака (микрософт дыры не покупает, в отличие от гугла и мозиллы). Пишут свой троян на дельфе (дотнете, vb или какой там еще пакости любимой школьниками). Вгружают его сплойтом. И вот там уже имеют некий доход от краж паролей к популярным ресурсам (для спама), всякого там спама во всех видах, ддосов/флудов на заказ, etc. Особо элитные злодеи собирают свои ботнеты. Но, собственно, как шедевры кодерского искусства это фуфло из себя ничего такого не представляет. Ну может кроме сплойта, при том что реверсеры сами по себе обычно на бизнесе не ушиблены и продают все это вредителям только потому что кроме них никто не платит, а трудная работа - должна вознаграждаться. Мозилла и гугл умно вклинились в эту схему и по этой причине имеют на порядки меньше проблем со взломами через их браузеры. Тем более что ишак апдейтится не чаще раза в месяц. Есть время для, кхе-кхе, толкания бизнеса. Одно дело купленый сплойт будет месяц гарантированно работать блгодаря циклам патчинга и немного другое дело если гугл или мозилла его заткнут через сутки экстренным фиксом. Понятно чего перспективнее для этих бизнес-уродов. > Если целевая платформа популярна, удельные затраты будут низкие, вот и всё. Субъективно, бизнес-ориентированные трояны (lol!) отличаются довольно ламерским уровнем технической части. То что интересно бизнесменам - вызывает зевоту у технарей. Поэтому уровень реализации обычно понятно какой. > Повторюсь, прототипы УЖЕ ЕСТЬ. Может, есть и боевые, но про то я не в курсе. Прототип написать не настолько уж и сложно. Сложно сделать так чтобы оно стало более-менее массово работать. > Своего кода — да. А как насчёт ACPI, например? В его километровых > таблицах можно что угодно творить... Можно, но насколько я помню, это не машинный код. А как, собственно, на машинный код управление то попадет без патчинга хоть небольшого кусочка основного BIOS? А если пропатчить - так чексумм или подпись на раз возбухнут и будет у юзера просто факап - биос выпадет в режим рекавери. Если он выпадет в этот режим на ровном месте, технарь который будет данный факап разруливать скорее всего заинтересуется вопросом "а какого черта, собственно?!". А на нотиках вообще биосы какие-то извращенские, с фирменными фичами ... и дебилизмами (типа блеклистинга "расово неправильных" карточек wi-fi). > Говорит. Только проверяется не всё подряд. Потому что CMOS, например, или те > же ACPI-таблицы никто подписывать не будет. ACPI таблицы кстати вроде как чексуммами снабжены. И это не машинный код. От того что вы туда х86 команды записали, выполняться они там не начнут. А как туда управление то получить при старте биоса без хака части биоса с машинным кодом, у которой тоже чексумм или даже подпись? Не, ну наверное можно найти какой-то баг типа buffer overrun в парсере ACPI, но это уже как-то совсем изврат. Да и с учетом засилья кривых биосов - есть шансы что парсеры окажутся довольно дуракоустойчивы. Хотя это был бы крайне оригинальный и извращенский метод, безусловно :) >>[оверквотинг удален] > а лежит где-то в централизованном хранилище — и тогда объектом атаки > будет становиться данное хранилище. Как это с HDCP было, например. Как пример реализации такой схемы: у процов самсуня есть efuses. В них можно 1 раз зашить хеш. Это - хеш пубкея. Проц при старте читает из флешки пубкей. Считает его хеш и убеждается что ему дали верный пубкей. Далее читается первый загрузчик их флешки. И его подпись проверяется прочитанным ранее кеем. Этот загрузчик читает следующую часть (загрузчик, OS loader или что там еще) - и тоже проверяет их подпись. Я вот так сходу не вижу - чего предлагается в такой схеме сломать? _Однократно_ зашиваемые фьюзы? Не, там кто первый встал - того и тапки^W ключ. А остальные - ну вы в курсе, да? Не очень понятно - а что предлагается расхакать? Думается в х86 как самый максимум - могут позволить перезапись корневого ключа по аппаратному воздействию типа кнопки. Но подозреваю что софтварной халявы тут всяко не будет. И вообще, скажете еще спасибо, если сможете запускать другие системы кроме сами знаете какой. > Боюсь, вы переоцениваете. Конечно, не все BIOS'ы одинаковые, но большая часть (т.е. > под неё выгодно этими разработками заниматься) x86-материнок достаточно типовая. Зависит от того что понимать под достаточностью. Я понимаю под достаточностью возможность автоматически утолкать в BIOS, не убив попутно комп, достаточно кода для того чтобы потом в автоматическом режиме патчить загрузчик какой-либо ОС для чего-то злонамеренного с учетом того что содержимое оного может заметно меняться у разных юзеров и версий ОС. ИМХО это выглядит как довольно геморройное начинание, не несущее само по себе никакого очевидного профита, зато довольно рисковое и крайне геморройное в техническом плане. > Более того, устройства от Apple, например, тоже становятся очень лакомой мишенью, т.к. > количество моделей мало, а аппаратов — велико... Думается их намного проще поиметь другими методами. Например, вбросив легиимному разработчику в код бэкдор. А тот пусть компилит и публикует в яблосторе, и вот уже миллионы ничего не подозревающих хомяков ставят себе прогу... и бэкдор.... И пропатчить текстовичок с сырцом - явно более просто чем с цифровыми подписями и низкоуровневыми особенностями чипсетов и разводки мамок долбаться :). Тем более что никто наверняка не проверяет детально что там в сторе. Ну потом то конечно вынесут, но энное время оно похулиганит, а потом и другого лоха можно найти. Под ифончик программит довольно много глуповатых гламурных тупиц, которые слыша "security" издают "wtf?" и вообще не греют свой мозг такой ерундой. >> А после парочки неожиданных факапов вероятно вредитель будет обнаружен. > Ну что ж, на его место придёт следующий. :) Пока я для начала и первого не вижу толком (лабораторный PoC и работоспособная дикая зараза не ломающая дров в автоматическом самоходном режиме - немного разные вещи). Ну CIH разве что,  и тот - PoC такой злобненький по сути, просто так подгаданный что более-менее в майнстрим попал (процент компов на одном конкретном чипсете был большой). Сейчас нет такого единодушного засилия какого-то одного из чипсетов с точностью до модели. Интел и тот развел кучи подвидов и подтипов чипсетов на разные сегменты. Это тогда у них было все просто - один TX на все, и конкуренты как раз отстали. >> за решетку угодить, пожалуй. > Вы это скрипткидисам говорите, которые шальными эксплоитами роняют сайты быстро злящихся > дядь и тёть. :) Скрипткидисов - много. Каждый второй школьник - потенциальный киддис. Поэтому хотя их ловят пачками в силу тупизны, всех переловить нереально - тюрем не хватит. Зато всегда можно покозырять красивыми отчетами за счет этих олухов :). Тех кто может напрограммить код способный биос перещивать - намноооого меньше. Что здорово сужает круг подозреваемых. > Ну и что, что не все — вполне достаточно для массового распространения. Более реалистично - для факапа в стиле cih некоторого процента неудачников. Ну может попутно впихивания такого на пару компов на заказ за большие бабки.   >> - Ряд мамок, особенно от гигабайта - с двойным биосом. Чип с >> базовой версией перешить проблематично, насколько я знаю. > Дык до перепрошивки ещё дойти надо. Надо тварь обнаружить. Она сама себя обнаружит. Попробовать грузануть операционку мало-мальски нестандартной версии/типа/с другим бутлоадером (у только линукса есть лило, груб1, груб2 и исолинукс, которые довольно существенно отличаются на уровне базовой анатомии) и пакость тут же обломится запатчить систему или сделает это крайне криво и вызовет уйму глюков, а то и просто покрешится все напрочь. Основная проблема руткита - в том что они себя демаскируют аномалиями. А тут еще ограниченность в месте и 100500 всяких факторов, которые надо учесть и которые усложняют жизнь. Оно очень быстро засветит себя имхо. Даже обычный то руткит вон попался на совершенно левом доступе к памяти + крахе процесса :) > А чем? Ни одного надёжного способа, кроме исследования микросхемы BIOS > в лабораторных условиях, нет по определению. Да блин, грузим линя и дампаем флеху flashrom. Просто, брутально, доступно даже хомяку в принципе, когда прижало. Ну и вот скажи еще что руткит (которому надо втиснуться в кошкин зад места) будет знать как сие перехватить и себя убрать из дампа, ага. А еще он надурит и методы сохранения дампа родными флешерами мамки и что там еще, при том и в виндозе и в досе сразу, ага. В минимум трех разных режима проца. А он не припухнет такую эвристику таскать в сильно ограниченном по месту (как бы BIOS львиную долю флехи и так занимает) низкоуровневом коде? Кстати упомянутый тобой фокус с ACPI тоже наврняка вызовет массу глюков и кто-то с экзотичной осью непременно полезет дампить столь странную таблицу для изучения и багрепортов и сильно удивится тому что там есть по факту :) > Не так уж и сложно, было бы желание. Прошивальщики-то обычно однотипные сами > по себе у одного производителя. Сначала ищется, где в нём эти сведения зашиты, > а потом для остальных моделей вытаскивается в полуавтоматическом режиме. Угу, еще и полуавтоматический дизассемблятор нужен? Всего-то? Который сможет в результате осилить только несколько ревизий мамок и может несколько типов оных от 1 производителя? А то эти редиски имеют свойство дописывать под себя утилсы и биосы, особенно крупные фирмы.   >> и риск, если у вас есть рядом второй PC и программатор". > А зачем мне-то пробовать? Я зловреды не пишу. Ну как бы и добронамеренный флешер, который НИЧЕГО НЕ ПАТЧИТ может при просто обычной записи то все раздестроить, если производитель где-то отступил на миллиметр хоть в каком-то вопросе от того что ожидалось. А вы хотите еще и патчить что-то автоматически, и чтоб потом ничего не сдохло :) > А авторы зловредов не будут сильно переживать, если что-то накроется... Зато это их будет сильно палить а пользователи и фирмы-производители будут жаждать крови. > Ну то есть, конечно, они заинтересованы в том, чтобы не накрывалось. Но не > настолько, чтобы плакать горючими слезами над каждым убитым чужим BIOS'ом. Просто у меня есть такое ощущение что затраты сил на этот гемор vs результативность - совершенно никакие. Собственно, тем кому денег надо - проще примитивные ламерские трояны крупным оптом через 0day вбрасывать. Ботнеты - они да, в цене. Как и услуги по спаму, ддосам и прочая. А впихивание в биос - гемора много, неуниверсально чуть более чем полностью. Проще, блин, отгрузить малварь хомякам через аппсторы и отослать 100500 смс на короткий номер. [кусь] > Мы о разных вещах говорим. Я-то про изменение уже имеющихся в системе > файлов писал, а не установку «гнилого» пакета. Дык откуда эти изменения возьмутся у например типового юзверга, кроме как из проги в пакете? Ну сплойты можно допустить, но все известные дыры как правило штопают быстро и массовых поимений как правило не происходит. Единственным исключением является винда, где апдейты по расписанию, при том хакерам почему-то впадлу ждать месяц и они обычно действуют иным методом: кто не спрятался - они не виноваты. И то сетевой софт типа браузеров и т.п. - научился апдейтиться оперативно (ну кроме IE, как обычно). > Естественно. Это второй или третий, и отнюдь не последний, уровень обнаружения вторжений. Просто когда речь идет о успешно установленном рутките - такое выглядит довольно странно. Руткит сразу же подразумевает что мы не доверяем операциям чтения и системным утилитам в работающей системе. Возможно я что-то недопонял и вы в отличие от меня имели в виду восстановительно исследовательские операции, когда заведомо чистая копия ос заружена с ридонли носителя для изучения ситуации. > Дальше я убрал написанное, ибо - поверьте - в курсе. :) Ну и ок :) >> но чисто программно. Для отлова и изучения пакости сойдет, хотя реализовывать >> чипсет с докой на ~1000 страниц немного утомительно, разумеется :). > Это уже не обнаружение вторжений, а разбор полётов после... Это скорее полужелезный трейсинг/логгинг странных операций. Никто не мешает его делать в run time, если сильно охота, прямо в run time сливая логи. Другое дело что опять же - все упрется в геморность реализации. Но если вы вознамерились всерьез охотиться за привидениями - вариант в принципе, и не то чтобы так уж дико сложный в реализации. Явно не сложнее самого руткита пишущего себя в флеху :) Тем более что полуаппаратная виртуализация железа - достаточно интересное упражнение для любого человека который находится между железом и софтом. >> Ну как, теперь паранойя не даст вам спать? :))) > Сплю как убитый. ;) Ну вот :((. А у вас есть допустим привкеи которыми вы подписываете наиболее чувствительные операции? А где вы их храните? Допустим, хакеры готовы выложить несколько k$ или даже десятков k$ чтобы их спереть. Где бы вы их хранили, зная что на них будут всерьез охотиться не слишком глупые хаксоры? > Да. Я в курсе. Возможно, я не совсем ясно выразился — приношу свои извинения. Видимо так. Я почему-то так понял из вашей фразы что вы не учли этот момент. >> Уж простите конечно, но ваши понятия о руткитах - на уровне пещерного >> человека. > Это было уже не об аппаратных руткитах, повторюсь, а о других попытках > незаметно закрепиться в системе. Руткит — не обязан работать на уровне ядра. :) Я знаю, но честно говоря, поделки меняющие системные утили я за серьезные руткиты вообще не считаю в силу относительной простоты поимки. Например простейшей прогой на си написанной за 5 минут или любым охотником на руткиты из репов даже.   > Конечно, он при этом легче отлавливается, но если уж > другого способа нет — пусть так, чем никак. :) Это весьма лайт версия руткита. И что значит - нет другого способа? Чисто физически оперативка - read/write, поэтому как минимум теоретически такой способ есть. Практически он может быть заметно загеморроен если ядро не грузит модули + метит область кода как ридонли а данных - как невыполнябельную. Тем не менее, кэп намекает что IOMMU например появился без году неделя и сильно местами. А без него - да, проц может и испытывает ограничения по доступу к оперативе, но железки с DMA могут и побеспределить. И как бы вся надежда на добропорядочность железяки :))) >> подписаны и проверка при установке делается. Что пакетов с бинарями, что >> с сырцами. И такие номера - не катят. > Подписанные — сложнее, да. Впрочем, когда это было-то... Ну да, мы не злопамятные. Но все-таки злые и память у нас хорошая. Поэтому злопыхать не буду, но выводы делать это не мешает. Если честно - как-то не ожилал настолько несерьезного администрирования от ЭТИХ людей. > Ну звиняйте. Можно систематически бросать далеко не бесконечные ресурсы на собственный > ftp.openbsd.org, а можно что-то исправлять и дополнять в самой системе. Ну да это отдельный разговор. Я думаю что с учетом кол-ва юзеров openssh и важности задач - они бы включили совесть и скинулись бы на сервачок для openssh, если попросить их об этом. > в нормальном датацентре? «Киньте клич»... Будьте реалистом. Википедия так собирает несколько миллионов баксов в год. Куда уж реалистичнее?! И не надо пожалуйста рассказывать про дикие цены в ДЦах, нынче цены стали вполне культурные и по зубам уже чуть ли не для хоумпаг. И траффика дают - хоть залейся. >> Sh... happens. Но по-моему, когда безопаснички отвечают за чужие FAILы - это >> идиотизм чистой воды. > Идиотизм — это когда утащили у конторы Самый Главный Электронный Сертификат, а > контора вместо того, чтобы быстренько заиметь другой, ждёт у моря погоды, > пока опростоволосившийся выпускатор сделает ей новый. Что-то торможу, а это о каком инцеденте речь? И кто ждал выпуска сертификата от слившегося выпускатора? Что-то настолько махровая тупость мне даже не припоминается. Это кто так? > А тут — тоже нехорошо, конечно, но, как показывает практика, FAIL'ы бывают у всех. Весь вопрос > — насколько серьёзные и насколько долго. :) Это тоже важный фактор, хрен поспоришь.
	Ответить | Правка | ^ к родителю #250 | Наверх | Cообщить модератору

	287. "Kernel.org подвергся взлому"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 03-Сен-11, 01:21
	>> Это ведь бизнес. > Wrong. Такие вещи - делаются как искусство. Черная магия. От злых волшебников. > Но все-таки, временами у них получаются довольно красивые штуки. Хоть и > зловредные по природе своей. Лет ещё десять назад это было хакерство (в исконном смысле этого слова). А сейчас — just business. Конечно, красивые концепты могут и сейчас появляться, но скорее в виде исключения. Если не верите — почитайте подробные отчёты антивирусных контор, или интервью со специалистами в этой области. Зловреды стали бизнесом и готовятся (а кое-где, похоже, уже стали) оружием массового поражения. Те же порнобаннеры — типичный бизнес. Технически — да, разве что некоторые последние версии могут быть интересными с точки зрения анализа. Хотя нет, всё же не столько интересными, сколько муторными... Ну да хватит, а то совсем уже старым пердуном себя ощущаю. :) >> Разработка и прочие расходы должны банально окупаться доходами. > Не вижу как можно было поиметь денег за CIH. Наиболее реальное что > там можно поиметь - увесистый срок в случае поимки, т.к. это > вполне ощутимая порча оборудования будет суду более понятна чем эфемерное стирание > пары файлов ;) Дык CIH — он из другой эпохи, см. выше. > Те кого волнует бизнес - скорее всего покупают у хардкорных реверсеров свежий > сплойт на 0day дыры для ишака (микрософт дыры не покупает, в > отличие от гугла и мозиллы). Пишут свой троян на дельфе (дотнете, > vb или какой там еще пакости любимой школьниками). Вгружают его сплойтом. > И вот там уже имеют некий доход от краж паролей к > популярным ресурсам (для спама), всякого там спама во всех видах, ддосов/флудов > на заказ, etc. Особо элитные злодеи собирают свои ботнеты. Собирают ботнеты и сдают в аренду, да. Троянов на заказ, AFAIK, пишут сейчас редко, как правило хватает «массового продукта»; максимум, что делается — какой-нибудь тот же ZeuS чуть адаптируется под конкретную среду. >> Повторюсь, прототипы УЖЕ ЕСТЬ. Может, есть и боевые, но про то я не в курсе. > Прототип написать не настолько уж и сложно. Сложно сделать так чтобы оно > стало более-менее массово работать. Если есть прототип и есть заинтересованные лица — результат будет. Повторюсь, они уже могут даже успешно работать. Даже на вашем компе. Паранойя, да? ;) >> Своего кода — да. А как насчёт ACPI, например? В его километровых >> таблицах можно что угодно творить... > Можно, но насколько я помню, это не машинный код. Не машинный, но по факту там язык программирования имеется. Который позволяет достаточно для того, чтобы маскировать присутствие постороннего кода. >> Говорит. Только проверяется не всё подряд. Потому что CMOS, например, или те >> же ACPI-таблицы никто подписывать не будет. > ACPI таблицы кстати вроде как чексуммами снабжены. И это не машинный код. Ну так контрольную сумму и обновить можно. И никто ругаться не будет, ибо что нелегального в изменении каких-то там данных в ACPI? Но, подозреваю, что на самом деле всё ещё хуже — однако для подтверждения (или опровержения) этих догадок надо зарываться глубже в спеки, а сейчас, пардон, голова болит... >[оверквотинг удален] > Как пример реализации такой схемы: у процов самсуня есть efuses. В них > можно 1 раз зашить хеш. Это - хеш пубкея. Проц при > старте читает из флешки пубкей. Считает его хеш и убеждается что > ему дали верный пубкей. Далее читается первый загрузчик их флешки. И > его подпись проверяется прочитанным ранее кеем. Этот загрузчик читает следующую часть > (загрузчик, OS loader или что там еще) - и тоже проверяет > их подпись. Я вот так сходу не вижу - чего предлагается > в такой схеме сломать? _Однократно_ зашиваемые фьюзы? Не, там кто первый > встал - того и тапки^W ключ. А остальные - ну вы > в курсе, да? Не очень понятно - а что предлагается расхакать? Я ж специально HDCP упомянул. :) В таком случае предлагается увести хеш у Самсуня. Ибо это самое уязвимое место. Поскольку запись одноразовая, то ничего подобного отзыву сертификата в X509 не возможно в принципе. Да, сделать это будет сложно. Но с каждым годом, думаю, это будет всё проще и проще. Так как системы (в том числе защиты) усложняются, в них появляется всё больше проблем, в том числе связанных с безопасностью, плюс средний уровень образованности пользователей тоже не растёт... все предпосылки к тому, что чем дальше, тем проще будет добыть любую информацию. А уж передать-распространить после добычи — уже сейчас раз плюнуть. >> Боюсь, вы переоцениваете. Конечно, не все BIOS'ы одинаковые, но большая часть (т.е. >> под неё выгодно этими разработками заниматься) x86-материнок достаточно типовая. > Зависит от того что понимать под достаточностью. Я понимаю под достаточностью возможность > автоматически утолкать в BIOS, не убив попутно комп, достаточно кода для > того чтобы потом в автоматическом режиме патчить загрузчик какой-либо ОС для > чего-то злонамеренного с учетом того что содержимое оного может заметно меняться > у разных юзеров и версий ОС. Учитывая, что dual-boot с регулярным переключением между ОСями — весьма нетипичный usecase, на него попросту забьют. :) Вы подходите к задаче написания таких зловредов как математик, вам нужно 100% решение. Но в реальном мире оно сейчас мало кого интересуют. Спрос — на выгодные (читай: массовые) решения. Так же как практически никто не заморачивался написанием кроссплатформенных вирусов (чтобы и на винде работали, и на Linux — хотя бы). Достаточно было одной винды, чтобы «продукт» был «успешным». > ИМХО это выглядит как довольно геморройное начинание, не несущее само по себе > никакого очевидного профита, зато довольно рисковое и крайне геморройное в техническом > плане. Когда-то так же думали про сам Linux. ;) >> Более того, устройства от Apple, например, тоже становятся очень лакомой мишенью, т.к. >> количество моделей мало, а аппаратов — велико... > Думается их намного проще поиметь другими методами. Например, вбросив легиимному разработчику > в код бэкдор. Как вариант, конечно. Более того, прецеденты уже были (только не помню, у ЙаМагазинчега, или кого-то аналогичного). >[оверквотинг удален] >> Ну что ж, на его место придёт следующий. :) > Пока я для начала и первого не вижу толком (лабораторный PoC и > работоспособная дикая зараза не ломающая дров в автоматическом самоходном режиме - > немного разные вещи). Ну CIH разве что,  и тот - > PoC такой злобненький по сути, просто так подгаданный что более-менее в > майнстрим попал (процент компов на одном конкретном чипсете был большой). Сейчас > нет такого единодушного засилия какого-то одного из чипсетов с точностью до > модели. Интел и тот развел кучи подвидов и подтипов чипсетов на > разные сегменты. Это тогда у них было все просто - один > TX на все, и конкуренты как раз отстали. Подвиды чипсетов отличаются включением-отключением каких-то фич (не важных для руткитов), вроде встроенного видео. Более того, определённая преемственность сохраняется и между поколениями. Так что всё не так уж страшно... для разработчиков зловредов, желающих их запускать на аппаратном уровне. >>> за решетку угодить, пожалуй. >> Вы это скрипткидисам говорите, которые шальными эксплоитами роняют сайты быстро злящихся >> дядь и тёть. :) > Скрипткидисов - много. Каждый второй школьник - потенциальный киддис. Поэтому хотя их > ловят пачками в силу тупизны, всех переловить нереально - тюрем не > хватит. Зато всегда можно покозырять красивыми отчетами за счет этих олухов > :). Тех кто может напрограммить код способный биос перещивать - намноооого > меньше. Что здорово сужает круг подозреваемых. Сужает или нет, но вы так говорите, как будто пойти на киберпреступление тяжело для любого человека. :) Это не говоря о кибервойнах между государствами и корпорациями... >> Ну и что, что не все — вполне достаточно для массового распространения. > Более реалистично - для факапа в стиле cih некоторого процента неудачников. Ну > может попутно впихивания такого на пару компов на заказ за большие > бабки. Вы оптимист, как я погляжу. :) >>> - Ряд мамок, особенно от гигабайта - с двойным биосом. Чип с >>> базовой версией перешить проблематично, насколько я знаю. >> Дык до перепрошивки ещё дойти надо. Надо тварь обнаружить. > Она сама себя обнаружит. Попробовать грузануть операционку мало-мальски нестандартной > версии/типа/с другим бутлоадером (у только линукса есть лило, груб1, груб2 и > исолинукс, которые довольно существенно отличаются на уровне базовой анатомии См. выше про dual boot. Та же ОСь, через которую руткит обосновался в системе, будет загружена и далее в 99,9...% случаев. Оставшиеся доли процента... кого он волнуют? Так что до обнаружения дойдёт не скоро. Повторюсь, вы идёте академическим путём. Он тоже хороший и иногда нужный. Но в данном случае он приводит вас к излишне оптимистичным прогнозам. :) Уже появлялась вирусня, прогрызающая виртуализаторы через те или иные уязвимости. Зловреды, массово внедряющиеся в BIOS'ы и иже с ними, — просто следующий шаг. >> А чем? Ни одного надёжного способа, кроме исследования микросхемы BIOS >> в лабораторных условиях, нет по определению. > Да блин, грузим линя и дампаем флеху flashrom. Просто, брутально, доступно даже > хомяку в принципе, когда прижало. Ну и вот скажи еще что > руткит (которому надо втиснуться в кошкин зад места) будет знать как > сие перехватить и себя убрать из дампа, ага. Если будет знать, как BIOS перепрошивается, может и защититься, как правило. Более того, никто не помешает ему вести себя, как описывалось (кажется, вами же) для Flash-анализатора: делать вид, что всё запатчилось. Места, повторюсь, ему хватит: несколько килобайт для защиты и передачи управления по команде более чем достаточно. >> Не так уж и сложно, было бы желание. Прошивальщики-то обычно однотипные сами >> по себе у одного производителя. Сначала ищется, где в нём эти сведения зашиты, >> а потом для остальных моделей вытаскивается в полуавтоматическом режиме. > Угу, еще и полуавтоматический дизассемблятор нужен? Всего-то? Который сможет в результате > осилить только несколько ревизий мамок и может несколько типов оных от > 1 производителя? А то эти редиски имеют свойство дописывать под себя > утилсы и биосы, особенно крупные фирмы. Не знаю, что такое «дизассемблятор». :)) И я про другое говорил: что один прошивальщик разбирается на детали, отыскивается магическая последовательность действий, а место, где она находится, запоминается. Остальные прошивальщики (для других материнок) разбирать уже не надо, просто идём в нужное место и добываем инфу. И, повторюсь, это наихудший из реальных вариантов. >> А авторы зловредов не будут сильно переживать, если что-то накроется... > Зато это их будет сильно палить а пользователи и фирмы-производители будут жаждать > крови. Полностью спрятать массовый продукт всё равно не удастся. :) И крови жаждать будут в любом случае, просто поводы будут разные: в одном случае поводом будет отправленная в кому железка; в другом — украденные деньги или конфиденциальная информация, например. И ещё неизвестно, за что голову будут хотеть открутить больше. ;) Если же говорить о чём-то нишевом, то там и спецификации будут более конкретные, а, значит, и возможностей качественно замаскироваться будет больше. > прочая. А впихивание в биос - гемора много, неуниверсально чуть более > чем полностью. Проще, блин, отгрузить малварь хомякам через аппсторы и отослать > 100500 смс на короткий номер. Пока что да. Но постепенно защита улучшается, рентабельность таких зловредов понижается... дальше понятно. :) > [кусь] >> Мы о разных вещах говорим. Я-то про изменение уже имеющихся в системе >> файлов писал, а не установку «гнилого» пакета. > Дык откуда эти изменения возьмутся у например типового юзверга, кроме как из > проги в пакете? Как откуда — из сплоита, вестимо. > Ну сплойты можно допустить, но все известные дыры > как правило штопают быстро и массовых поимений как правило не происходит. Это вы про *nix? Ну так и доля десктопов пока что мала. Вот, Android пошёл в массы — и проблемы безопасности на нём уже стоят довольно остро. Займёт какая-нибудь Убунта хотя бы 10% рынка десктопов-ноутбуков, и дырки в *nix-софте также начнут массово использовать (не забывая, разумеется, и про социальную инженерию). Один только XDG со всеми предлагаемыми им прибабахами и друзьями по имени Кеды и Гном уже подготовил платформу для злоупотреблений. > Единственным исключением является винда, где апдейты по расписанию, Справедливости ради следует сказать, что в особых случаях обновления в винде приплывают моментально. Плюс для корпоративных пользователей они тоже приходят немного пораньше. Ну да не суть. >> Естественно. Это второй или третий, и отнюдь не последний, уровень обнаружения вторжений. > Просто когда речь идет о успешно установленном рутките - такое выглядит довольно > странно. Руткит сразу же подразумевает что мы не доверяем операциям чтения > и системным утилитам в работающей системе. Возможно я что-то недопонял и > вы в отличие от меня имели в виду восстановительно исследовательские операции, > когда заведомо чистая копия ос заружена с ридонли носителя для изучения > ситуации. Нет, я имел в виду, например, такое: # chflags schg /bsd* /bin/* /sbin/* /etc/boot.conf /etc/rc{,.securelevel} ... Плюс, разумеется, отсылку syslog'а на удалённый хост. Добавляет немного гимора при обновлении, но в качестве рубежа обороны вполне себе: при отсутствии эксплоита для выхода в ядро, позволит защитить систему от прописывания дряни на автозапуск, что уже немало, согласитесь. >[оверквотинг удален] >>> чипсет с докой на ~1000 страниц немного утомительно, разумеется :). >> Это уже не обнаружение вторжений, а разбор полётов после... > Это скорее полужелезный трейсинг/логгинг странных операций. Никто не мешает его делать > в run time, если сильно охота, прямо в run time сливая > логи. Другое дело что опять же - все упрется в геморность > реализации. Но если вы вознамерились всерьез охотиться за привидениями - вариант > в принципе, и не то чтобы так уж дико сложный в > реализации. Явно не сложнее самого руткита пишущего себя в флеху :) > Тем более что полуаппаратная виртуализация железа - достаточно интересное упражнение для > любого человека который находится между железом и софтом. Хм. Что-то в этом есть... >>> Ну как, теперь паранойя не даст вам спать? :))) >> Сплю как убитый. ;) > Ну вот :((. А у вас есть допустим привкеи которыми вы подписываете > наиболее чувствительные операции? А где вы их храните? Допустим, хакеры готовы > выложить несколько k$ или даже десятков k$ чтобы их спереть. Где > бы вы их хранили, зная что на них будут всерьез охотиться > не слишком глупые хаксоры? Этот вопрос сильно зависит от организации работы в фирме, стоимости информации, особенностей работы с оной (подписывания в данном случае)... В одном случае это будет сейф, из которого раз в месяц будет доставаться волшебный USB-брелок; в другом случае это будет волшебная машина в сети... Надеюсь, вы правильно поймёте, что детально о том, как это было на том или ином месте моей работы сделано, я рассказывать не буду? ;) >>> Уж простите конечно, но ваши понятия о руткитах - на уровне пещерного >>> человека. >> Это было уже не об аппаратных руткитах, повторюсь, а о других попытках >> незаметно закрепиться в системе. Руткит — не обязан работать на уровне ядра. :) > Я знаю, но честно говоря, поделки меняющие системные утили я за серьезные > руткиты вообще не считаю в силу относительной простоты поимки. Например простейшей > прогой на си написанной за 5 минут или любым охотником на > руткиты из репов даже. Или вообще штатными средствами ОС. ;) Но не суть. Я с руткитом на никсах вживую сталкивался всего раз. Он засел внутри фряшного jail'а, и дальше не ушёл. Поимка была элементарной. Но это было ещё до массового помешательства на почве виртуализации, сейчас бы пришлось тщательно проверять всё подряд. >> Конечно, он при этом легче отлавливается, но если уж >> другого способа нет — пусть так, чем никак. :) > Это весьма лайт версия руткита. И что значит - нет другого способа? Это значит, нет возможности вылезти на уровень ядра. То есть это именно классический руткит: прячем себя и указанные процессы от любопытных глаз, и даём доступ по хитрому запросу. > Чисто физически оперативка - read/write, поэтому как минимум теоретически такой способ > есть. Практически он может быть заметно загеморроен если ядро не грузит > модули + метит область кода как ридонли а данных - как > невыполнябельную. Тем не менее, кэп намекает что IOMMU например появился без > году неделя и сильно местами. А без него - да, проц > может и испытывает ограничения по доступу к оперативе, но железки с > DMA могут и побеспределить. И как бы вся надежда на добропорядочность > железяки :))) Гм. Не все ОСи — тридцатидвухбитная винда. :) Напрямую к железке обращаться как бы никто не даст. >>> подписаны и проверка при установке делается. Что пакетов с бинарями, что >>> с сырцами. И такие номера - не катят. >> Подписанные — сложнее, да. Впрочем, когда это было-то... > Ну да, мы не злопамятные. Но все-таки злые и память у нас > хорошая. Поэтому злопыхать не буду, но выводы делать это не мешает. > Если честно - как-то не ожилал настолько несерьезного администрирования от ЭТИХ > людей. Администрированием занимаются не они, а университет Альберты, Канада. >> в нормальном датацентре? «Киньте клич»... Будьте реалистом. > Википедия так собирает несколько миллионов баксов в год. Куда уж реалистичнее?! Хм. Ну, если в OpenSSH тоже начать каждый год по месяцу при каждом подключении писать «дайте денег»... ;) > И не надо пожалуйста рассказывать про дикие цены в ДЦах, нынче цены > стали вполне культурные и по зубам уже чуть ли не для > хоумпаг. И траффика дают - хоть залейся. Первый попавшийся датацентр в Канаде: http://www.datacenterscanada.com/private-racks.html 800$ в месяц за отдельную стойку (а ставить ftp.openbsd.org в общую стойку вы бы стали?), плюс 35$ за каждые Мбит/с сверх 10. И ещё за разные опции сдерут. Не кислая сумма выходит. И это не считая собственно железа. >>> Sh... happens. Но по-моему, когда безопаснички отвечают за чужие FAILы - это >>> идиотизм чистой воды. >> Идиотизм — это когда утащили у конторы Самый Главный Электронный Сертификат, а >> контора вместо того, чтобы быстренько заиметь другой, ждёт у моря погоды, >> пока опростоволосившийся выпускатор сделает ей новый. > Что-то торможу, а это о каком инцеденте речь? И кто ждал выпуска > сертификата от слившегося выпускатора? Что-то настолько махровая тупость мне даже не > припоминается. Это кто так? Да вот недавний факап с сертификатами у нидерландского центра сертификации. Несколько дней сертификаты крупных компаний не отзываются и не перевыпускаются — это нормально? Не говоря о том, сколько времени эти герои вообще молчали в тряпочку.
	Ответить | Правка | ^ к родителю #278 | Наверх | Cообщить модератору

	306. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 07-Сен-11, 01:59
	> Лет ещё десять назад это было хакерство (в исконном смысле этого слова). > А сейчас — just business. ... и в силу этого изменился качественно-количественный состав малвари. В ботнете потеря 1 машины вообще ничего не значит а большой ботнет сколько бы он ни ныкался будет обнаружен и тогда будет создан метод по надежному детекту его руткита и анинсталлу. > Конечно, красивые концепты могут и сейчас появляться, но скорее в виде исключения. Ну вот видимо поэтому мы и не видим красивых руткитов в биосе пачками. Зато всякого крапа писаного на дельфи и даже VB/.net от каких-то ламеров - полно. > Если не верите — почитайте подробные отчёты антивирусных контор Верю, верю. А теперь покажите мне засилье этих, которые биос стирают/патчат с бизнес-целями. Что-то вместо них в основном какая-то примитивная малварь да ботнеты сплошняком. > Те же порнобаннеры — типичный бизнес. Технически — да, разве что некоторые [...] > да хватит, а то совсем уже старым пердуном себя ощущаю. :) Да ну, ничего там особо интересного нет. Мошенники которые поумнее разводят лошков которые поглупее. Бизнес - есть. Техническая составляющая - примитивна как копье неандертальца. В бизнесе важно не это :). > Дык CIH — он из другой эпохи, см. выше. Вот в ту эпоху и писали крутые штуки, чтобы показать умения остальным, затестить концепции или просто поиздеваться над глупыми юзерями. Ряд вирусов был вообще PoC не ориентированными на "боевое" применение и случайно, по технической ошибке начинали свое шествие в диком виде. Это не мешало вставлять даже в такие версии довольно деструктивные функции, чтоб "все понастоящему". > Собирают ботнеты и сдают в аренду, да. Троянов на заказ, AFAIK, пишут > сейчас редко, как правило хватает «массового продукта»; максимум, что делается > — какой-нибудь тот же ZeuS чуть адаптируется под конкретную среду. Вот-вот. При этом оно в техническом плане не такое уж и крутое. Это вам не хитровыгнутый полиморфик где ни 1 байта в новой копии не совпадает, и не хитрый перехватыватель сисколов. Это всего лишь заурядная пакостилка нацеленная на ведение бизнеса :). Зевс может и не так уж плохо сделан. Но в целом разница - как между серийной скрипкой из магазина и скрипкой Страдивари. > Если есть прототип и есть заинтересованные лица — результат будет. Повторюсь, они > уже могут даже успешно работать. Даже на вашем компе. Паранойя, да? ;) На моем? С удовольствием посмотрел бы на это. Только оно рискует попаться, т.к. я иногда не прочь слить образ BIOS и сунуться в него хексэдитором, анализируя что и как там устроено. И даже иногда проверяю отличия образов, чисто из научного интереса "а что там меняется и насколько часто" :). И если честно - я не вижу для руткитов простого и удобного метода перехватить все методы дампа биоса и выпилить себя из оных дампов. Хотя если у меня будут такие подозрения - я в состоянии прочесть/записать SPI-флеху своего биоса брутальными аппаратными методами. > для того, чтобы маскировать присутствие постороннего кода. Ну, замаскировали, допустим. И ... выполнить то его потом как? Парсер ACPI вовсе не собирается запускать это. Bios управление туда тоже передать забывает :) > Ну так контрольную сумму и обновить можно. И никто ругаться не будет, > ибо что нелегального в изменении каких-то там данных в ACPI? В принципе - да. Правда все-равно не понятно как потом туда управление попадет. Кстати сами таблицы крайне кривые и потуги их распарсить, запатчить и собрать заново могут привести к веселым фэйлам. > подтверждения (или опровержения) этих догадок надо зарываться глубже в спеки, На эти спеки производители с удовольствием кладут, при том изучать как именно тот или иной производитель накосячил в той или иной мамке или ноуте - достаточно трудоемко. Впрочем мне не понятно главное: пусть вы даже записали осмысленный код в ACPI таблицу, область DMI или куда там еще. Но вот каким манером код там выполняться начнет? > Я ж специально HDCP упомянул. :) В таком случае предлагается увести хеш у Самсуня. Хеш не надо "уводить" - он известен. Ты можешь посчитать его схешировав пубкей. И пубкей известен (в флеше лежит). А вот умыкнуть парный к нему привкей у самсуня, чтобы убедить  данный проц запустить данный код - удачи. Тем более что у производителей эти кеи могут быть их собственными и как бы к "вон той" железке может требоваться другой кей (вшитый производителем). Собственно бывает и так что кей не вшит и можно самому эти тапки одеть, если не жмут. Вот тогда многие бут/руткиты лососнут тунца, если вы цепочку трастов при загрузке сами не прервете. Тем не менее, это не панацея. Ядро может быть запатчено в оперативке после старта, например атакой по сети. От этого подписи уже не спасут. > Ибо это самое уязвимое место. Поскольку запись одноразовая, то > ничего подобного отзыву сертификата в X509 не возможно в принципе. Да, но чтобы ломануть эту схему - надо спереть привкей, пубкей от которого имеет указанный хеш. Ежу понятно что этот привкей берегут не хуже чем рутовый серт CA, поэтому... поэтому я еще ни разу не видел чтобы такой ключ хоть у кого-то сперли :))). Единственным известным мне исключением является разве что фирма Сони, где похожий по смыслу ключ ECDSA был наглейше _вычислен_ нехитрой математикой. Но это Сони сами ступили, не почитав ман на используемый алгоритм. [del] > усложняются, в них появляется всё больше проблем, в том числе связанных > с безопасностью, Как ни странно, это факт. Мне известны случаи поимения защит такого плана через дыры в самой защите, лол :) [del] > предпосылки к тому, что чем дальше, тем проще будет добыть любую > информацию. А уж передать-распространить после добычи — уже сейчас раз плюнуть. Тем не менее, я ни разу еще не видел чтобы у какого-нибудь производителя реально сперли такой привкей (лопухи из Сони которые сами себя обманули не почитав толком описание алгоритма до его реализации и не осознавшие что рандом именно критичен - не считаются). > Учитывая, что dual-boot с регулярным переключением между ОСями — весьма нетипичный > usecase, на него попросту забьют. :) Да даже просто при переустановке оси или установке иной версии оси или другой операционки - неизбежно косяки полезут. Как максимум я знаю про чуть ли не единственный реально применяемый boot-кит, пишущий себя довольно олдскульненько в бутсектор (прямо как в DOSовых-вирусах), патчащий семерку/висту с их подписями, которые в противном случае мешали бы это делать. И то штука довольно редкая и как я уже сказал - половина антивирусов обнаглело и первым делом все по подобным штукам и ловит :) > Вы подходите к задаче написания таких зловредов как математик, вам нужно 100% решение. Я подхожу как реалист :). То-есть, 1) Не должно быть так что 90% - факапы. Иначе про эту штуку уже завтра будет знать даже самый зачуханный антивирус и месяцы геморроя - насмарку. Да еще какойнить козел напишет утилю с одной кнопкой "убить гада" специально для хомяков, а киберкопы встанут на уши. 2) Вариантов дико много. Поэтому избежать пункта 1) почти нереально. 3) Место ограничено. Поэтому архисложная логика на 100500 вариантов просто не упихается туда. 4) На мало-мальски отличных от тепличных условиях (т.е. почти везде) будут разные баги и глюки, даже заметные окружающим или даже нагибающие их. И вы не сможете это оттестить как это работает толком и обезглючить за разумное время. Потому что сложно добыть сотни разных машин и сложно протестировать и обезглючить на них все это в разумные временные рамки. > не заморачивался написанием кроссплатформенных вирусов (чтобы и на винде работали, и > на Linux — хотя бы). Достаточно было одной винды, чтобы «продукт» был «успешным». Ну да. Хотя некоторые руткиты вполне себе встречаются и для *nix-like. Чему лишним примером эта новость. Просто встречаются редко. > Когда-то так же думали про сам Linux. ;) Как максимум Торвальдс поначалу считал это баловством и несерьезной системой, но постепенно решил что получается неплохо и что оно может быть полезно другим. Плохо себе представляю как такое же будет применено к руткитам или иному типу malware. Публичный анонс малвари вообще чреват посадкой автора ;). [del] > Как вариант, конечно. Более того, прецеденты уже были (только не помню, у > ЙаМагазинчега, или кого-то аналогичного). Как минимум, в андроид маркете жила была куча всякой малвари. Да и сейчас наверное не все выпилили. Вот это да, бизнес - впаривание дряни лохам оптом и не менее оптовый профит от их развода. А технически все уныло и банально. > Подвиды чипсетов отличаются включением-отключением каких-то фич (не важных для руткитов), Они могут отличаться подключением и типом флешки, работой с ней, тем что там по факту записано, реализацией защиты записи и прочая. Универсальный патчер+флешер вшивающий еще один унивирсальный патчер в ограниченный объем получается какой-то крайне нетривиальной конструкцией. > вроде встроенного видео. Более того, определённая преемственность сохраняется и между > поколениями. Определенная - есть. Это не значит что новореализованный SPI шьется точно так же как fw hub или LPC флешка или тем более параллельная. По этому поводу у вполне легитимных флешеров и то заряд бодрости - надо понять как именно поюзан конкретный чипсет, и выбрать из кучи вариантов верный. Не говоря о том что сакральное знание о том какое IO надо дернуть чтобы write protect отключить - в самом биосе обычно живет (как я понимаю, пункт биоса разрешающий или запрещающий запись оного - за это и отвечает). Кстати если я правильно помню, фирменные флешеры обычно не таскают с собой сакральное знание как это выключить, а, считая спецификой мамки, детектят неуспех записи и просят вырубить в биосе защиту от записи. Биос на своей мамке разумеется знает как это сделать. > Так что всё не так уж страшно... для разработчиков зловредов, > желающих их запускать на аппаратном уровне. Судя по отсутствию массовых зловредин такого типа - соотношение затрат усилий и результатов разработчиков видимо не прельщает. > Сужает или нет, но вы так говорите, как будто пойти на киберпреступление > тяжело для любого человека. :) Это не говоря о кибервойнах между > государствами и корпорациями... Дело не в киберпреступлении а в способности понять как это работает. Пойти на киберпреступление не сложно. Понять как записать пакость в флешку - сложнее. Поэтому то и есть легион скрипткидиссов vs аж целый 1 автор CIH и еще несколько совсем уж концептов :) > Вы оптимист, как я погляжу. :) Всего лишь реалист, способный прочитать даташиты на флешки и чипсеты. > См. выше про dual boot. Та же ОСь, через которую руткит обосновался > в системе, будет загружена и далее в 99,9...% случаев. Оставшиеся доли > процента... кого он волнуют? Так что до обнаружения дойдёт не скоро. Это годится только для персональной адресной атаки на конкретную машину. Такая атака в принципе возможна, но крайне дорогостоящая из-за необходимости большого объема кастом кодинга под конкретно вон ту машину и ее специфику. > Повторюсь, вы идёте академическим путём. Он тоже хороший и иногда нужный. Но > в данном случае он приводит вас к излишне оптимистичным прогнозам. :) Напротив, я всего лишь представляю: а что если бы я это захотел реализовать? Какие проблемы меня бы ожидали на этом пути? Наиболее очевидные я перечислил. > Уже появлялась вирусня, прогрызающая виртуализаторы через те или иные уязвимости. А нельзя пример именно вируса (т.е. самоходного ПО, способного к размножению, работающее в автоматическом режиме) который на автомате пробивает виртуализаторы? Я пока как максимум видел во первых анонсы уязвимостей, тупенькие детекторы виртуализаторов да парочку PoC "можно сломать вон тот гипервизор через дырку". Реально боевых экспонатов - не попадалось. > Зловреды, массово внедряющиеся в BIOS'ы и иже с ними, — просто следующий шаг. Так где они? >> Да блин, грузим линя и дампаем флеху flashrom. Просто, брутально, доступно даже хомяку [...] > Если будет знать, как BIOS перепрошивается, может и защититься, как правило. Защититься от чего? От последовательности действий с железом приводящей к чтению содержимого флешки? Так работа с железом может быть реализована кучей разных способов, отследить и пропатчить именно нужное крайне сложно. Как  максимум можно наверное попробовать стать гипервизором и пытаться показывать ОС виртуальный чипсет и флешку, но это вы не о чипсете с спекой на 1000 страниц же?! Такое в пустое место в биосе не влезет :) > Более того, никто не помешает ему вести себя, как описывалось (кажется, вами > же) для Flash-анализатора: делать вид, что всё запатчилось. В упомянутом случае задача была бы сильно облегчена тем фактом что это отдельная программно-аппаратная приблуда. Она не зависит от того какая именно ос там загрузится, какой режим CPU и вообще кто и как дорвался до SPI шины. Важен сугубо результат этих действий. А вот со стороны х86 как это надежно перехватить? Разве что виртуализатор впихнуть? Ну там вылезет гора других нестыковок, вплоть до того что точно сэмулировать именно мою мамку, именно ее чипсет и именно ее флешку - задача нетривиальная. > Места, повторюсь, ему хватит: несколько килобайт для защиты У х86 нет каких-то удобных и штатных средств для "защиты доступа к одному конкретному девайсу". Как абсолютный максимум, я могу представить себе загрузку системы под гипервизором. Но при этом вылезет 100500 особенностей и глюков, и я готов поспорить что виртуализатор, особенно способный мне показать именно мою флеху, на моем чипсете, на правильном интерфейсе, нигде не приврать, но при этом перехватить доступ - очень врядли втиснется в свободное место в биосе. Кстати сидя за компом, успех записи в BIOS несложно проверить и без программатора. > и передачи управления по команде более чем достаточно. Передачи управления кем, куда и в какой момент? [del] > И я про другое говорил: что один прошивальщик разбирается на детали, > отыскивается магическая последовательность А она вроде и не отыскивается - если я правильно помню прошивальщик просто обламывается и просит отключить в BIOS защиту от записи. > действий, а место, где она находится, запоминается. Остальные прошивальщики (для других > материнок) разбирать уже не надо, просто идём в нужное место и > добываем инфу. И, повторюсь, это наихудший из реальных вариантов. Ну, со времен CIH кое-какие средства добавления сложностей вирусам - появились. В частности - какая-никакая защита от записи встречается не то чтобы редко. > Полностью спрятать массовый продукт всё равно не удастся. :) Дла начала его сделать надо. PoC отличается от боевой версии как ракета для фейерверка - от лунного модуля. [del] > или конфиденциальная информация, например. И ещё неизвестно, за что голову будут > хотеть открутить больше. ;) Конфиденциальную информацию можно упереть и без таких извращений и логично потратить ресурсы на эффективность именно этого, раз уж все-равно обнаружат при более-менее массовых диверсиях ;).Все-равно при обнаружении сделают средства автоматизированного обнаружения, обезвреживания и удаления. Если уж на bluepill сделали детектор... ;) > Если же говорить о чём-то нишевом, то там и спецификации будут более > конкретные, а, значит, и возможностей качественно замаскироваться будет больше. Наиболее реалистично - поставить партию компов с предустановленной операционкой и/или bios где то или другое немного пробэкдорены, при этом можно все более-менее подогнать. Но это совершенно заурядное вредительство. И в серьезных местах должны такую возможность рассматривать. Ну и какие-то сильно адресные атаки может быть. И то - проще просто упереть инфо да самовытереться после того как интересная инфа уперта. > дальше понятно. :) Дальше, судя по сабжу - разломают эпплу аппстор и сразу оптом отгрузят всем счастья килограммами. Проще и результативнее. [del] > Как откуда — из сплоита, вестимо. Опять же - софт апдейтится довольно оперативно. Массовых поимений пользователей оперативно обновляемого софта не видно даже под виндой. Почему-то через хром и фокс пользователей почти не ломают, откровенно предпочитая IE, ридер и прочих - у которых обновление тормозное, кривое или отсутствует. >> как правило штопают быстро и массовых поимений как правило не происходит. > Это вы про *nix? Да про всех. См. выше. Виндоусапдейт с его циклом выпуска = 1 месяц не считается. За месяц можно все разнести. Почему MS не в курсе - не мои проблемы. > Ну так и доля десктопов пока что мала. А вон ту кучу серверов мы не будем замечать? Судя по тому что на вывешенном SSH лог отрастает на десятки метров в сутки - желающих халявы в природе навалом. А случаи взлома все-таки единичные почему-то. Ну во всяком случае zeus-ы всякие - под виндой :). Заявления о том что миллионы всегда включенных мощных машин на >=100М канале никому не нужны - неубедительны. > Вот, Android пошёл в массы — и проблемы безопасности на нём > уже стоят довольно остро. В нем довольно остро стоит в общем то одна единственная проблема: гугл тянет в свой каталог всякий сомнительный хлам являющийся по большому счету малварью. > Займёт какая-нибудь Убунта хотя бы 10% рынка десктопов-ноутбуков, и дырки > в *nix-софте также начнут массово использовать Нерентабельно получается покупать сплойт. Заплатить денег чтобы обнаружить что все уже законопачено - не прикольно, знаешь ли. Это ж не MS который раз в месяц фиксы выкатывает. Там да, если ты заплатил - у тебя гарантированно месяц есть, кроме ну совсем уж вопиющих случаев способных сподвигнуть этих бегемотов на внеплановый апдейт :) > (не забывая, разумеется, и про социальную инженерию). С которой опять же все не так удобно. > Один только XDG со всеми предлагаемыми им прибабахами и друзьями по имени Кеды > и Гном уже подготовил платформу для злоупотреблений. Теоретически, найти тот или иной баг можно везде кроме разве что hello world. Практически, есть еще вопрос соотношения затрат сил к результативности мероприятия. Оттуда и вытекает то что наблюдяется по факту на рынке заразы. >> Единственным исключением является винда, где апдейты по расписанию, > Справедливости ради следует сказать, что в особых случаях обновления в винде приплывают > моментально. Справедливости ради, я видел такое лишь несколько раз в жизни. А ддосы и спамы с виндовых ботнетов почему-то валятся ежедневно, поэтому налицо некоторая нестыковка. Секрет в том что хакерам глубоко наплевать на удобные таймлайны лощеных манагеров и их корпоративные проблемы.  Внеплановый апдейт обычно делается под давлением недовольных кастомеров, в том числе и корпоративных, когда они устают массово вытряхивать малварь. > Плюс для корпоративных пользователей они тоже приходят немного пораньше. > Ну да не суть. Да хрен там. Скорее, чаще админы напротив не пускают те или иные апдейты по причине обнаруженных проблем совместимости и деферрят их до момента когда станет понятно как с этим бороться. Через корпоративный апдейт может быть роздано МЕНЬШЕ (админы могут выбрать что раздать а что нет). Но больше - не может. И приезжает всем примерно одинаково, по вторникам, раз в месяц. Вообще странно было бы корпоративщикам раньше остальных присылать - они не оценят бетатесты на себе ;) [del] > Нет, я имел в виду, например, такое: > # chflags schg /bsd* /bin/* /sbin/* /etc/boot.conf /etc/rc{,.securelevel} ... Это что-то bsd-специфичное? Если верить гуглю, оно не позволяет изменять файлы. Повторяю еще раз: в случае руткита мы НЕ ДОВЕРЯЕМ ядру. И не доверяем флагам. И не доверяем тому что и как ядро будет энфорсить. Рут - повелитель ОС. Он в принципе может все. Да, можно что-то где-то вроде бы откусить, но у рута всегда в запасе over 9000 интересных фокусов. Исходная логика кто такой рут не предусматривает эффективной защиты от него. По сути он "представитель системы". Ее управляющий. Запрещать ему административные действия в общем случае отдает ФГМ. Но руткит чуть покруче. В хучшем случае он - кусок ядра. Тот кто и определяет кому и что можно, а кому - нельзя. Ядро и применяет те или иные флаги. Если его поломали в памяти (а руткиты наполовину именно об этом) - мы уже не можем доверять флагам. Вообще, в такой ситуации верить можно только носителю который полностью readonly на аппаратном уровне (CD-R еще никто перезаписать не смог :D). А всякие там атрибуты, флаги и свойства энфорсимые ядром - это так, от обычных пользователей. А от качественного руткита, патчащего сисколы в ядре - не спасет совсем. Ядро само себе не разрешит чего-то? Ха-ха. > Плюс, разумеется, отсылку syslog'а на удалённый хост. Добавляет немного гимора при обновлении, > но в качестве рубежа обороны вполне себе: От серьезно настроенного ядерного руткита не обязано спасать, т.к. как минимум теоретически, руткит вполне способен переиначить логику работы ядра. Как пример: хваленый SELinux ядерные сплойты выпинывают в два счета. Что помешает втулить патч для забития на флаги? Лично я бы не стал уповать на этот рубеж применительно к руткитам. На самом деле, задача хорошего, годного руткита в правильном понимании этой технологии - вломиться в память ядра и захватить контроль над сисколами. Утилитки режима пользователя - невинные детские шалости. Их должен детектить и выносить любой вменяемый админ, голыми руками (из инструментов достаточен сишный компилер как максимум). Палится тупо: дерганием сискола и сравнением результата дерга с выводом соотв. утили. Куча программ-охотников на руткиты проверяют это первым делом. Нормальные охотники идут намного дальше и дотошно сравнивают дерги разных сисколов между собой. Вот на этом уже и ядерный руткит может спалиться. Сисколов - много, все захватить и с 100% точностью запатчить так чтобы поведение было везде идентично - довольно сложно. К тому же ядерщики их перетрясают, добавляют новые и прочая. Руткит вполне может и облажаться где-то. > при отсутствии эксплоита для выхода в ядро, позволит защитить систему > от прописывания дряни на автозапуск, что уже немало, согласитесь. Осталось только найти метод который позволит достоверно определить - а вот в данный момент у нас в оперативной памяти нормальная версия кернела или уже похаканая? Если некто получил именно настоящего рута - по исходной задумке этой системы прав, руту можно все. Вплоть до работы с оборудованием и прочая. Поэтому в такой ситуации довольно криво и ненадежно уповать на то что рут был глуп и не смог пропатчить ядро в памяти. Подстановка костылей - это замечательно, но т.к. методов пролезания в ядро настоящему руту доступно целая уйма - я не думаю что их можно все более-менее эффективно законопатить. > Хм. Что-то в этом есть... Сэмулировать одну железку другой железкой - всегда забавно. [skip] >> выложить несколько k$ или даже десятков k$ чтобы их спереть. Где >> бы вы их хранили, зная что на них будут всерьез охотиться >> не слишком глупые хаксоры? > Этот вопрос сильно зависит от организации работы в фирме, стоимости информации, особенностей > работы с оной (подписывания в данном случае)... Мне не слишком интересно как организован процесс в некоей конкретной шараге. Интересно как лично вы бы действовали допустим для лично себя, если бы у вас был допустим сертификат за которым гоняются хакеры, готовые угробить некоторое количество усилий чтобы его умыкнуть. В такой постановке задачи - можете считать что бюрократия равно нулю, а цель - получить максимальную сохранность сертификата при минимизации геморроя. [del] > Надеюсь, вы  правильно поймёте, что детально о том, как это было на том > или ином месте моей работы сделано, я рассказывать не буду? ;) Меня не интересует как оно было. Меня интересует как действовали бы вы лично от себя.   [..] >> прогой на си написанной за 5 минут или любым охотником на >> руткиты из репов даже. > Или вообще штатными средствами ОС. ;) А вот их могли и подменить, если это не автоматическая атака тупого бота. Собственно потому то и своей прогой. Хотя в принципе могут и компилер/либы подменить, поэтому лучше все-таки грузиться с заведомо чистой копии ОС, во избежание сюрпризов. > Но не суть. Я с руткитом на никсах вживую сталкивался всего раз. Он засел > внутри фряшного jail'а,  и дальше не ушёл. Поимка была элементарной. Но это было ещё > до массового помешательства на почве виртуализации, сейчас бы пришлось тщательно проверять > всё подряд. Малварь под *никс вообще довольно редкая штука. >> Это весьма лайт версия руткита. И что значит - нет другого способа? > Это значит, нет возможности вылезти на уровень ядра. Чисто теоретически такой способ есть всегда. Потому что оперативка сама по себе read-write, а сумеет ли этим воспользоваться злодей или нет - как-то очень уж негарантированный фактор. Например, всего 1 баг в ядре - и вот уже в нем крутится хацкерский код. Учитывая размеры современных кернелов баги там ожидать вполне можно. > То есть это именно классический руткит: прячем себя и указанные процессы > от любопытных глаз, и даём доступ по хитрому запросу. ИМХО что-то такое в юзермоде сколь-нибудь всерьез может насолить разве хукая вызовы ВСЕХ программ путем перехвата вызовов в либы с помощью всяких там LD_PRELOAD (и то, это паливно). В остальных случаях это всего лишь довольно смешной лохоразвод. > Гм. Не все ОСи — тридцатидвухбитная винда. :) Напрямую к железке обращаться > как бы никто не даст. В общем случае руту можно весьма дофига, и надежно откусить реально разве что "фэйковым рутом", типа того который в openvz/lxc недавних. Который для остальной системы - конь в пальто. Защита системы от настоящего рута попахивает маразмом в стиле цифровых подписей у дров на висте и семерке, которые больше для защиты DRM-ограничений от юзера + диктатуры производителям железа чем для защиты собственно OS от хакеров. >> Если честно - как-то не ожилал настолько несерьезного администрирования от ЭТИХ людей. > Администрированием занимаются не они, а университет Альберты, Канада. Тогда, "настолько несерьезного управления проектом". Так больше нравится? > Хм. Ну, если в OpenSSH тоже начать каждый год по месяцу при > каждом подключении писать «дайте денег»... ;) На один сервак - хватит и пары упоминаний в год, пожалуй. У вики серверов несколько сотен, они все-таки круглосуточно и много отгружают всей планете :) >> хоумпаг. И траффика дают - хоть залейся. > Первый попавшийся датацентр в Канаде: http://www.datacenterscanada.com/private-racks.html > 800$ в месяц за отдельную стойку (а ставить ftp.openbsd.org в общую стойку > вы бы стали?), Ну нифига себе практика двойных стандартов. Значит ставить сервак администраяемый посторонними - нормально, а в общую стойку - "ну что вы, как можно?!" :))). А если развить идею, тогда наверное и свой датацентр надо. А то как это вообще - ставить свой сервак рядом с какими-то еще козлами в одном датацентре? Да еще и всякий там чужой персонал шляться будет?! Вообще, тем что набито в 42U можно пожалуй весь опенбсд обслужит. Ну договориться тогда с еще несколькими заинтересованными и арендовать на толпу, под кучу связанных проектов, вплоть до того что персональный сервак занедорого. Наверное 800 баксов в месяц на всю ораву можно и найти. В пересчете на 1U получается всего 19 баксов в месяц. Ну, если забыть про относительно скромное питание (на то и 110 вольт) и какой-то жадновато-хилый интернет (берите ). > плюс 35$ за каждые Мбит/с сверх 10. И ещё за разные опции сдерут. > Не кислая сумма выходит. И это не считая собственно железа. А если весь ДЦ скупить - ценник будет еще круче :). А то 42U за раз на 1 не очень большой проект - хорошо живете, а? >> Это кто так? > Да вот недавний факап с сертификатами у нидерландского центра сертификации. Несколько дней > сертификаты крупных компаний не отзываются и не перевыпускаются — это нормально? > Не говоря о том, сколько времени эти герои вообще молчали в тряпочку. Нет, разумеется это EPIC FAIL. Кстати а они разве не норвежцы были? Впрочем, от господ с IIS на сайте я как-то и не привык ожидать особо здоровского администрирования и трепетного отношения к безопасности.
	Ответить | Правка | ^ к родителю #287 | Наверх | Cообщить модератору

	308. "Kernel.org подвергся взлому"	+/–
	Сообщение от Michael Shigorin (ok) on 07-Сен-11, 13:51
	> В общем случае руту можно весьма дофига, и надежно откусить реально разве > что "фэйковым рутом", типа того который в openvz/lxc недавних. Который для > остальной системы - конь в пальто. JFYI, не очень давно lxc-шный рут в контейнере без своей сети вполне мог уложить интерфейс в HN.  В ovz да, подобного не наблюдалось.
	Ответить | Правка | ^ к родителю #306 | Наверх | Cообщить модератору

	311. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 08-Сен-11, 04:17
	> JFYI, не очень давно lxc-шный рут в контейнере без своей сети вполне > мог уложить интерфейс в HN.  В ovz да, подобного не наблюдалось. Тут где-то рядом кто-то припомнил про tun драйвер еще. В общем "на контейнеры надейся, а сам не плошай".
	Ответить | Правка | ^ к родителю #308 | Наверх | Cообщить модератору

	265. "Kernel.org подвергся взлому"	+/–
	Сообщение от Клыкастый (ok) on 02-Сен-11, 19:36
	>> Только все эти способы НЕ ГАРАНТИРУЮТ, что вы всё вычистите. > Я согласен что есть руткиты которые сидят только в памяти но такое > можно определить в считанные секунды, Серьёзно? А я всегда считал, что одна из первейших целей руткита - сокрытие себя любимого. Но если руткит определяется за несколько секунд, то видимо я ошибался: цель руткита другая. Возможно мир во всём мире. Или коррекция оси Галактики. Товарисч. Вы правы только в одном. Сначала надо разобраться, что это было, и как оно туда попало, дабы на свежей машине не наступить на те же грабли. Но потом - переустановка скомпрометированной системы и усиление мер по безопасности.
	Ответить | Правка | ^ к родителю #240 | Наверх | Cообщить модератору

	72. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 12:01
	> Только все эти способы НЕ ГАРАНТИРУЮТ, что вы всё вычистите. Вы так > уверены, что ничего не пропустите? Вы уверены, что нарушители спокойствия не > воспользовались какой-то неизвестной вам (и, возможно, практически всему человечеству) > возможностью? Вы так уверены, что где-то не осталось нечаянно включённой в > прошлый раз дырки, через которую (тоже) можно попасть в систему? > Полная переустановка — единственный надёжный способ. В любой операционной системе. > Всё остальное, весь контроль целостности, нужен для диагностики. Полная переустановка возвращает систему в исходное состояние, со всеми УЖЕ ИЗВЕСТНЫМИ дырами в готовности к повторному сносу. Это как хирургическое восстановление гимена (девственной плевы) у женщин. Суть и смысл тот же самый. Как, впрочем, и результат.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	75. "Kernel.org подвергся взлому"	+6 +/–
	Сообщение от anonymous (??) on 01-Сен-11, 12:07
	а без переустановки дыры магически исчезают, надо полагать. ещё один клоун.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	152. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 17:27
	А что, они магически исчезают при переустановке? Если уязвимость неизвестна, что помешает еще раз ее использовать?
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	156. "Kernel.org подвергся взлому"	+/–
	Сообщение от anonymous (??) on 01-Сен-11, 17:32
	> А что, они магически исчезают при переустановке? Если уязвимость неизвестна, что помешает > еще раз ее использовать? а ты попробуй почитать пару нитей рядом. может, сможешь понять (если хорошо поднатужишься), зачем делают переустановку.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	157. "Kernel.org подвергся взлому"	+3 +/–
	Сообщение от Andrey Mitrofanov on 01-Сен-11, 17:36
	> А что, они магически исчезают при переустановке? Если уязвимость неизвестна, что помешает > еще раз ее использовать? В этой новости не было удалённой уязвимости. Разработчикам, прошляпившим ключи и пароли их прикрыли-отключили, меняют и по ушам ездят. Если ты, клоун, хочешь углубиться в оффтопик, что ты тут старательно демонстрируешь, пройди лесом в своё болото.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	124. "Kernel.org подвергся взлому"	+/–
	Сообщение от Phake on 01-Сен-11, 14:59
	И что? Ну вернётся система в исходное состояние с уязвимостями... Только чтобы до них по новой добраться, надо ещё одну учетку скомпрометировать... Пока будут искать такую учетку, и уязвимость всплывёт из привата, как старая, и софт весь 10 раз обновится. В итоге скомпрометировав ещё 1 учетку через пару месяцев, лишь 20-30% вероятность, что эта уязвимость ещё работает. Поэтому естественно после анализа происшествия, система переустанавливается, ставятся последние апдейты и докручивается безопасность. Благо анализ происшествия позволяет выявить наиболее уязвимые места в защите...
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	202. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 23:28
	> И что? Ну вернётся система в исходное состояние с уязвимостями... В конкретно этой новости я не вижу пока анонсов о уязвимостях.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	253. "Kernel.org подвергся взлому"	+/–
	Сообщение от Phake on 02-Сен-11, 14:36
	>> Тем не менее, пока не ясно как именно удалось поднять свои привилегии в системе, судя по всему был задействован эксплоит для еще публично неизвестной уязвимости. Вот анонс предполагаемой уязвимости. О ней и речь.
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	255. "Kernel.org подвергся взлому"	+/–
	Сообщение от Andrey Mitrofanov on 02-Сен-11, 15:21
	>>> Тем не менее, пока не ясно как именно удалось поднять свои привилегии в системе, судя по всему был задействован эксплоит для еще публично неизвестной уязвимости. > Вот анонс предполагаемой уязвимости. О ней и речь. На kernel.org написано >>>> how they managed to exploit that to root access is currently unknown and is being investigated. За фантазии про "публично неизвестной уязвимости" скажите отдельное спасибо автору текста новости и больше не повтооряйте ерунду. Разницу-то осилите?
	Ответить | Правка | ^ к родителю #253 | Наверх | Cообщить модератору

	160. "Kernel.org подвергся взлому"	+2 +/–
	Сообщение от Xasd (ok) on 01-Сен-11, 17:54
	> Полная переустановка возвращает систему в исходное состояние, со всеми УЖЕ ИЗВЕСТНЫМИ дырами ну да, всё верно... ....при условии -- если переустанавливать систему с тогоже самого диска "Реаниматор 2002: Microsoft Windows XP SP1" :-D
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	74. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 12:05
	Полная переустановка не спасёт, если "пока не ясно, как именно удалось поднять свои привилегии в системе, судя по всему, был задействован эксплоит для еще публично не известной уязвимости" (кстати, исправьте текст новости). В таком случае установят с нуля уже скомпрометированную систему, содержащую уязвимость. "В будущем планируется пересмотреть политику безопасности и методы организации доступа." А вот это уже правильнее, организационные методы здесь эффективнее технических мер.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	76. "Kernel.org подвергся взлому"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Сен-11, 12:09
	> Полная переустановка не спасёт, если "пока не ясно, как именно удалось поднять > свои привилегии в системе, судя по всему, был задействован эксплоит для > еще публично не известной уязвимости" (кстати, исправьте текст новости). В таком > случае установят с нуля уже скомпрометированную систему, содержащую уязвимость. > "В будущем планируется пересмотреть политику безопасности и методы организации доступа." > А вот это уже правильнее, организационные методы здесь эффективнее технических мер. Вы вообще читаете написанное? Или реагируете на отдельные ключевые слова? Во-первых, разумеется, сначала делается диагностика, и при переустановке учитываются её результаты. Во-вторых, переустановка делается ещё и для гарантированного (с оговоркой на руткиты в железе, да, но это отдельный разговор) вычищения всякой дряни вроде руткитов и скомпрометированных ключей.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	100. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 13:58
	>Вы вообще читаете написанное? Или реагируете на отдельные ключевые слова? Написанное читаю, реагирую на идеи и мысли, а не отдельные слова вне контекста. >Во-первых, разумеется, сначала делается диагностика, и при переустановке учитываются её результаты. Во-вторых, переустановка делается ещё и для гарантированного (с оговоркой на руткиты в железе, да, но это отдельный разговор) вычищения всякой дряни вроде руткитов и скомпрометированных ключей. Повторю написанное выше: "Организационные методы здесь эффективнее технических мер." Сильно сомневаюсь, что уже проведённая экстренная переустановка системы на скомпрометированных узлах без глубокого технического аудита и дополнительных организационных изменений в структуре работы kernel.org приведут к серьёзному повышению безопасности.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	102. "Kernel.org подвергся взлому"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Сен-11, 14:02
	> Повторю написанное выше: "Организационные методы здесь эффективнее технических мер." > Сильно сомневаюсь, что уже проведённая экстренная переустановка системы на скомпрометированных > узлах без глубокого технического аудита и дополнительных организационных изменений в структуре > работы kernel.org приведут к серьёзному повышению безопасности. Любую хорошую идею можно по-дурацки претворить в жизнь, кто ж спорит.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	105. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 14:09
	Тут коллега ниже предложил способ повышения безопасности инфраструктуры kernel.org: http://www.opennet.dev/openforum/vsluhforumID3/80067.html#21 Немного топорно, не так гибко, как хотелось бы (жёсткая привязка на шлюзе к ip подключающихся узлов), но, в целом, правильно. Заметьте, все меры - более организационные, лишь их реализация - техническая. А вы упорно чините авто, в который всё равно снова сядет пьяный водитель.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	107. "Kernel.org подвергся взлому"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Сен-11, 14:24
	> Тут коллега ниже предложил способ повышения безопасности инфраструктуры kernel.org: > http://www.opennet.dev/openforum/vsluhforumID3/80067.html#21 > Немного топорно, не так гибко, как хотелось бы (жёсткая привязка на шлюзе > к ip подключающихся узлов), но, в целом, правильно. Заметьте, все меры > - более организационные, лишь их реализация - техническая. Насчёт привязки — и вам спасибо скажут разработчики, которые регулярно перемещаются с места на место, ездящие на конференции и т.д. От атак это не защитит, только от самых слабых. > А вы упорно чините авто, в который всё равно снова сядет пьяный водитель. Ваш пример какой-то странный: если дело в водителе, то не вижу причин, чтобы не чинить авто. Ну да ладно, суть-то понятна. Во-первых, предлагаемые меры не сильно помогут. Если кто-то теряет контроль над ключом/паролем для доступа по SSH, да ещё при наличии неизвестной дыры с эскалацией привилегий, то предлагаемые меры лишь удлинят общее время взлома. Учитывая, сколько времени злоумышленники пробыли незамеченными, предлагаемое направление явно не приоритетное. Есть более серьёзные проблемы. И прежде всего — постоянный аудит сообщений подсистем безопасности. Уже после этого можно говорить о чём-то ещё. А во-вторых, работоспособность серверов восстанавливать надо. Никто не мешает производить переустановку системы (с учётом найденных проблем) и параллельно что-то ещё делать.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	122. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 14:53
	>Насчёт привязки — и вам спасибо скажут разработчики, которые регулярно перемещаются с места на место, ездящие на конференции и т.д. От атак это не защитит, только от самых слабых. Написано же выше: "Немного топорно, не так гибко, как хотелось бы (жёсткая привязка на шлюзе к ip подключающихся узлов)". Стационарные рабочие станции со статическим ip можно держать дома постоянно включенными, а уже к ним обращаться с мобильных рабочих мест (нет- и ноутбуки, планшеты и т.д.). Но опасность MitM увеличивается, доступ к kernel.org всё же усложняется, да и неэффективное это решение. А вот VPN-клиент на рабочем месте (неважно, стационарном или мобильном) и VPN-сервер на шлюзе с жёсткими политиками канальных ключей - уже теплее. >Ваш пример какой-то странный: если дело в водителе, то не вижу причин, чтобы не чинить авто. Уточню: авто - переустанавливаемая система, а пьяный водитель - это и та вероятная неизвестная (пока?) уязвимость, и оргсистема всего kernel.org. Надо не только спешно чинить авто, а и разбираться с водителем. По вашему последнему предложению соглашусь, но спешно вводить в сеть "чистые" узлы с вероятной угрозой только для восстановления работоспособности - в корне неверное решение.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	125. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Сен-11, 15:00
	>>Насчёт привязки — и вам спасибо скажут разработчики, которые регулярно перемещаются с места на место, ездящие на конференции и т.д. От атак это не защитит, только от самых слабых. > Написано же выше: "Немного топорно, не так гибко, как хотелось бы (жёсткая > привязка на шлюзе к ip подключающихся узлов)". Стационарные рабочие станции со > статическим ip можно держать дома постоянно включенными, а уже к ним > обращаться с мобильных рабочих мест (нет- и ноутбуки, планшеты и т.д.). > Но опасность MitM увеличивается, доступ к kernel.org всё же усложняется, да > и неэффективное это решение. А вот VPN-клиент на рабочем месте (неважно, > стационарном или мобильном) и VPN-сервер на шлюзе с жёсткими политиками канальных > ключей - уже теплее. Гм. А чем VPN-сервер с жёсткими политиками принципиально отличается от SSH-сервера с жёсткими политиками? :) >>Ваш пример какой-то странный: если дело в водителе, то не вижу причин, чтобы не чинить авто. > Уточню: авто - переустанавливаемая система, а пьяный водитель - это и та > вероятная неизвестная (пока?) уязвимость, и оргсистема всего kernel.org. Надо не только > спешно чинить авто, а и разбираться с водителем. По вашему последнему > предложению соглашусь, но спешно вводить в сеть "чистые" узлы с вероятной > угрозой только для восстановления работоспособности - в корне неверное решение. Смотря что понимать под «спешно». Я уже выше уточнил, что сначала, разумеется, надо убрать выявленные угрозы. Можете считать это компромиссом...
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	128. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от anonymous (??) on 01-Сен-11, 15:19
	> Гм. А чем VPN-сервер с жёсткими политиками принципиально отличается от SSH-сервера с > жёсткими политиками? :) добавляется дополнительная прослойка со своими багами и уязвимостями. очевидно, у некоторых это называется «увеличить security».
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	130. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 16:15
	Не разбираетесь в теме - не тратьте время на сообщения. VPN+IPSec ни в чём не уступает SSH-туннелированию.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	135. "Kernel.org подвергся взлому"	+/–
	Сообщение от anonymous (??) on 01-Сен-11, 16:54
	> Не разбираетесь в теме - не тратьте время на сообщения. VPN+IPSec ни > в чём не уступает SSH-туннелированию. желаю видеть демонстрацию работы этого монстра с git.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	149. "Kernel.org подвергся взлому"	+/–
	Сообщение от Michael Shigorin (ok) on 01-Сен-11, 17:17
	> Не разбираетесь в теме - не тратьте время на сообщения. Простите, Вам что-то говорят буковки ASN.1 и архивы багтрака/секунии на их тему?
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	223. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 02-Сен-11, 00:50
	Постоянно не слежу, но на уязвимости в продуктах с применением ssh натыкаюсь столь же часто, как и на VPN+IPSec уязвимости. Nothing is perfect, Mike...
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	77. "Kernel.org подвергся взлому"	+5 +/–
	Сообщение от anonymous (??) on 01-Сен-11, 12:10
	зато как минимум позволит гарантировать, что на свежей системе нет руткита. да, возможно, он появится, когда систему выпустят в сеть. с другой стороны, это позволяет наладить специализированые средства аудита, которые могут помочь в отлове зверушки, и которые не применялись в силу тормознутости, усложнения работы до совершенно неудобоваримой и так далее. база же.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	171. "Kernel.org подвергся взлому"	+/–
	Сообщение от Sem (ok) on 01-Сен-11, 19:05
	>Полная переустановка не спасёт, если "пока не ясно, как именно удалось поднять свои привилегии в системе, судя по всему, был задействован эксплоит для еще публично не известной уязвимости" (кстати, исправьте текст новости). В таком случае установят с нуля уже скомпрометированную систему, содержащую уязвимость. Я смотрю, у вас огромный опыт по расследованиям взломов :))) С машины снимается образ и после этого в эмуляторе, в безопасных условиях исследуется. А сервер возвращается в строй ASAP.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	256. "Kernel.org подвергся взлому"	+/–
	Сообщение от коксюзер on 02-Сен-11, 15:47
	> Полная переустановка — единственный надёжный способ. В любой операционной системе. Расскажите это любителям писать руткиты в память BIOS материнок и видеокарт.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	280. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 02-Сен-11, 23:53
	> Расскажите это любителям писать руткиты в память BIOS материнок и видеокарт. А можно мне дампов отсыпать с такими? Хочу на ЭТО посмотреть. CIH не предлагать.
	Ответить | Правка | ^ к родителю #256 | Наверх | Cообщить модератору

	90. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 12:56
	> Существуют как минимум 4 способа проверки целостности на изменение файлов в системе А что собственно помешает руткиту при проверке подпихнуть исправный вариант файла? > да хотя б для начала контрольные суммы собрать со всей системы, Руткит может подсунуть исправный вариант файла, но фактически все будет несколько иначе. > дату изменения конечно можно подставить свои. Вы просто не представляете себе возможности по нае...ву серьезных руткитов. Безопасник хренов! > SELinux на кой Вам ??? Отключается ядерными сплойтами.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	97. "Kernel.org подвергся взлому"	+/–
	Сообщение от ZloySergant (ok) on 01-Сен-11, 13:41
	>Руткит может подсунуть исправный вариант файла, но фактически все будет несколько иначе. В системе подгруженной, скажем с livecd, при проверке файловой системы подмонтированной с noexec,noatime,nodev,ro? UPD: Хотя, можно и не монтировать, а жестк. диск проверять сразу, если шифрования нет.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	111. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 14:29
	>>Руткит может подсунуть исправный вариант файла, но фактически все будет несколько иначе. > В системе подгруженной, скажем с livecd, при проверке файловой системы подмонтированной > с noexec,noatime,nodev,ro? > UPD: Хотя, можно и не монтировать, а жестк. диск проверять сразу, если > шифрования нет. livecd на сервере не труъ.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	174. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 19:17
	>livecd на сервере не труъ. замени на pxe
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	205. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 23:40
	> В системе подгруженной, скажем с livecd, при проверке файловой системы подмонтированной > с noexec,noatime,nodev,ro? Ну да, на CD пакость конечно физически не запишется но в памяти сможет развлекаться сколько влезет, если она попала в ОС после загрузки с CD (хотя грузить сервак с ливцд вообще непрактично, да и носитель с правами RW серваку нужен по идее). Кстати щеголяя всякими noexec,noatime,nodev,ro - не забудьте что реализует их ядро. Если его в памяти допатчили - ну это вам оно noexec. А хакеру на которого работает руткит - друг человека, который так и быть сделает скидку и забьет на все эти дурацкие флаги :). Единственный плюс: если ребутнуться - система станет чистой. Правда при этом и логи вам некуда будет писать, не так ли? :) Если вы рекавери имели в виду, когда загрузка с заведомо чистой копии ливцд - ну там то конечно можно делать что угодно и руткита не будет, если вас не хакнут снова :) > UPD: Хотя, можно и не монтировать, а жестк. диск проверять сразу, если > шифрования нет. Видимо мы не поняли друг друга - я про обычную работу сервера говорил, а вы про хардкорный вариант рекавери от руткита с ливцд.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	257. "Kernel.org подвергся взлому"	+/–
	Сообщение от ZloySergant (ok) on 02-Сен-11, 16:04
	>Видимо мы не поняли друг друга - я про обычную работу сервера говорил, а вы про хардкорный вариант рекавери от руткита с ливцд. Видимо, да. От руткита, имхо, либо снос и переустановка, либо ректальная тонсилотерапия. P.S. >Правда при этом и логи вам некуда будет писать, не так ли? :) Если live-системы - то будет, смотря что и куда подмонтирую. Обычно была какая-нить хрень, навроде iomega zip через lpt.
	Ответить | Правка | ^ к родителю #205 | Наверх | Cообщить модератору

	98. "Kernel.org подвергся взлому"	+/–
	Сообщение от aurved on 01-Сен-11, 13:46
	> А что собственно помешает руткиту при проверке подпихнуть исправный вариант файла? Ну наверное помешает ему то, что руткит не будет запущен при подключении этого "винта" к другой  чистой системе и загрузке именно с нее и проверки целостности именно из под чистой системы. Ну или проверки при загрузке с Live-CD (DVD).
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	129. "Kernel.org подвергся взлому"	–2 +/–
	Сообщение от Anonimas on 01-Сен-11, 16:05
	> А что собственно помешает руткиту при проверке подпихнуть исправный вариант файла? > Руткит может подсунуть исправный вариант файла, но фактически все будет несколько иначе. Для тех кто на бронике !!! Самый простой способ проверки системы: Устанавливаем, все настраиваем - сервак имеется в виду, Потом этот сервак загружается с загрузочной флешки на которой или линух или BSD и снимаются контрольные суммы  со всех файлов в системе, заодно можно скопировать и всю систему на всякий пожарный. Ломают сервак, всегда есть резервная копия, всегда есть контрольные суммы всех файлов Существует же какая то утилита для сверки контрольных сумм - покрайней мере в портах FreeBSD, в линухе уже не встречал пока что...
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	134. "Kernel.org подвергся взлому"	+2 +/–
	Сообщение от Аноним (??) on 01-Сен-11, 16:48
	Угу, взяли и побежали флешку в сервер втыкать, который за тридевядь земель. *facepalm*
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	137. "Kernel.org подвергся взлому"	+/–
	Сообщение от anonymous (??) on 01-Сен-11, 16:56
	> Угу, взяли и побежали флешку в сервер втыкать, который за тридевядь земель. > *facepalm* админы локалхоста атакуют.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	141. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 16:59
	заходим на ipmi консоль - говорим - вот у нас этот образ и грузимся с него. вуаля? Или нищибоды не знаю что такое ipmi ?
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	145. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 01-Сен-11, 17:12
	> заходим на ipmi консоль Вообще-то то, куда тычутся ipmiview или браузером с jws, и которое делает iKVM и virtual media -- это service processor, технически говоря.  Который сидит поверх, а сейчас обычно физически совмещён, с IPMI BMC. Кстати, там унутре SoC обычно тоже встроенный линукс. :)
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	266. "Kernel.org подвергся взлому"	+/–
	Сообщение от Клыкастый (ok) on 02-Сен-11, 19:40
	> Угу, взяли и побежали флешку в сервер втыкать, который за тридевядь земель. > *facepalm* Дай заплюсую :)
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	172. "Kernel.org подвергся взлому"	+/–
	Сообщение от Sem (ok) on 01-Сен-11, 19:07
	> Для тех кто на бронике !!! > Самый простой способ проверки системы: А обновления?
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	132. "Kernel.org подвергся взлому"	–5 +/–
	Сообщение от Аноним (??) on 01-Сен-11, 16:29
	вы кст зря гражданина bezopasnik заминусовали . все верно говорит
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	133. "Kernel.org подвергся взлому"	+2 +/–
	Сообщение от Michael Shigorin (ok) on 01-Сен-11, 16:38
	> вы кст зря гражданина bezopasnik заминусовали . все верно говорит В данном разе -- отнюдь, он в корне неправ и взялся судить человека, который в обсуждаемом вопросе обладает явно бОльшими квалификацией и/или опытом. ЕСЛИ ПРОЛОМИЛИ СИСТЕМУ И ПРЕДПОЛАГАЕТСЯ ВОЗМОЖНОСТЬ ПОЛУЧЕНИЯ EUID==0 -- ЭТУ СИСТЕМУ НЕОБХОДИМО УСТАНАВЛИВАТЬ ИЛИ ГЕНЕРИРОВАТЬ ЗАНОВО. Старый корень стоит брать на forensics, но вышенакапсанного это не отменяет.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	182. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 22:19
	> ЕСЛИ ПРОЛОМИЛИ СИСТЕМУ И ПРЕДПОЛАГАЕТСЯ ВОЗМОЖНОСТЬ ПОЛУЧЕНИЯ EUID==0 > -- ЭТУ СИСТЕМУ НЕОБХОДИМО УСТАНАВЛИВАТЬ ИЛИ ГЕНЕРИРОВАТЬ ЗАНОВО. Факт. Хотя по опыту знаю, что если нет возможности перевести на резерв, так не делают.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	208. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 23:44
	> так не делают. Ну и сидите с руткитами, кому хуже то? :) А нормальные спецалисты на авось не полагаются.
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	276. "Kernel.org подвергся взлому"	+/–
	Сообщение от Michael Shigorin (ok) on 02-Сен-11, 20:38
	>> ЕСЛИ ПРОЛОМИЛИ СИСТЕМУ И ПРЕДПОЛАГАЕТСЯ ВОЗМОЖНОСТЬ ПОЛУЧЕНИЯ EUID==0 >> -- ЭТУ СИСТЕМУ НЕОБХОДИМО УСТАНАВЛИВАТЬ ИЛИ ГЕНЕРИРОВАТЬ ЗАНОВО. > Факт. Хотя по опыту знаю, что если нет возможности перевести на резерв, > так не делают. Наверное... я делал, когда в openssh оказался remote root и возникло смутное подозрение (явных следов так и не нашли). :(
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	138. "Kernel.org подвергся взлому"	+/–
	Сообщение от anonymous (??) on 01-Сен-11, 16:57
	> вы кст зря гражданина bezopasnik заминусовали . все верно говорит ещё один админ локалхоста нарисовался.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	241. "Kernel.org подвергся взлому"	+/–
	Сообщение от Щекн Итрч (ok) on 02-Сен-11, 12:33
	>> Раскажите свой вариант, что делать. > Существуют как минимум 4 способа проверки целостности на изменение файлов в системе > да хотя б для начала контрольные суммы собрать со всей системы, дату > изменения конечно можно подставить свои. > SELinux на кой Вам ??? Хозяин бэкдора не станет коцать файло. Трипвайр на раз его запалит. Это круто, что в логе нашли сообщение неподнятого сервиса. Бэкдор, да на таком проекте, станет вести себя оооооочень незаметно.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	267. "Kernel.org подвергся взлому"	+/–
	Сообщение от Клыкастый (ok) on 02-Сен-11, 19:43
	> Хозяин бэкдора не станет коцать файло. > Трипвайр на раз его запалит. Трипвайр запалит бекдор, не подпёртый руткитом. Руткит на то и руткит, чтобы всем объяснять, что его нет.
	Ответить | Правка | ^ к родителю #241 | Наверх | Cообщить модератору

	282. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 03-Сен-11, 00:02
	> Трипвайр запалит бекдор, не подпёртый руткитом. Руткит на то и руткит, чтобы > всем объяснять, что его нет. Просто руткит в желании сныкаться иногда перемудряет и демаскирует себя как раз странными глюками. У них вон вообще тачка в панику упала + еще и срач в лог левым доступом к памяти.
	Ответить | Правка | ^ к родителю #267 | Наверх | Cообщить модератору

	304. "Kernel.org подвергся взлому"	+/–
	Сообщение от Клыкастый (ok) on 05-Сен-11, 21:59
	> Просто руткит в желании сныкаться иногда перемудряет не стоит рассчитывать что и в следующий раз попадётся криворукий автор руткита
	Ответить | Правка | ^ к родителю #282 | Наверх | Cообщить модератору

	327. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 18-Сен-11, 03:46
	> не стоит рассчитывать что и в следующий раз попадётся криворукий автор руткита А это вытекает не из кривизны рук автора руткита. Есть теорема, что нельзя написать программу, которая даст определенный ответ проанализировав другую программу, например, завершится ли анализируемая программа за конечное время или нет. Следствием является пара забавных фактов: 1) Всегда можно написать зловред, обманывающий все уже выпущенные антивирусы. 2) Тем не менее, для любого даже самого противного зловреда можно написать утилиту-нейтрализатор, который им зловредом засекается и его выпинывает.
	Ответить | Правка | ^ к родителю #304 | Наверх | Cообщить модератору

	330. "Kernel.org подвергся взлому"	+/–
	Сообщение от U (??) on 23-Сен-11, 09:01
	>> не стоит рассчитывать что и в следующий раз попадётся криворукий автор руткита > А это вытекает не из кривизны рук автора руткита. Есть теорема, что > нельзя написать программу, которая даст определенный ответ проанализировав другую программу, > например, завершится ли анализируемая программа за конечное время или нет. > Следствием является пара забавных фактов: > 1) Всегда можно написать зловред, обманывающий все уже выпущенные антивирусы. > 2) Тем не менее, для любого даже самого противного зловреда можно написать > утилиту-нейтрализатор, который им зловредом засекается и его выпинывает. Что значит выпинывает? Тут уже говорилось о восстановлении. Разное. Например, сравнение системы с этанолом гарантированно выявляет зловреда (работающая система не обязана быть изменяемой). Другое дело, что как в какой-то степени будучи знаком с буддизмом, могу спросить: каковы гарантии, что то, что вам кажется, вообще есть реальность... :-) На практике, это и вопрос о разработчиках ядра Линукс. Среди них может быть зловред(ы). Вносимые им зловредные фрагменты кода какое-то время, во всяком случае, могут быть не замечены, как зловредные... Или могут быть списаны на результаты воздействия тех же взломщиков (один из разработчиков уже обнаружил у себя ЭТО...)... В принципе, это отвечает приблизительно на вопрос, например, зачем спецслужбам столь грубо демаскировать свой захват доступа к серверу. Это даёт некоторые возможности прикрыть зловреда (прикрыться зловредам). Заодно бросить тень на других разработчиков... И в целом скомпрометировать проект и понудить "юзеров" к отказу от Линукс в пользу гораздо более подконтрольных этим спецслужбам систем... Наверно, они избрали такой путь... По-моему, в нём можно усмотреть некоторые привлекательные стороны >:-) Особенно, если предполагать, что зловреда в конце концов должны бы раскрыть...
	Ответить | Правка | ^ к родителю #327 | Наверх | Cообщить модератору

	331. "Kernel.org подвергся взлому"	+/–
	Сообщение от Michael Shigorin (ok) on 23-Сен-11, 11:47
	> Например, сравнение системы с этанолом гарантированно выявляет зловреда С этанолом, говорите... это довыясняться до зелёных зловредов, что ли? ;-)
	Ответить | Правка | ^ к родителю #330 | Наверх | Cообщить модератору

	332. "Kernel.org подвергся взлому"	+/–
	Сообщение от Клыкастый (ok) on 27-Сен-11, 23:12
	про этанол это сильно :))) этанол вообще многие проблемы решает :)
	Ответить | Правка | ^ к родителю #330 | Наверх | Cообщить модератору

	88. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 12:52
	> он мне не задумываясь ответил - переставлять систему > просто крындец, безмозглость Вот у вас - и правда безмозглость поражающая. Вы знаете что такое руткиты? И что, имеете наглость утверждать что ВСЕ их обнаружите, одной левой?
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	91. "Kernel.org подвергся взлому"	+12 +/–
	Сообщение от anonymous (??) on 01-Сен-11, 12:56
	> И что, имеете наглость утверждать что ВСЕ их обнаружите, одной левой? конечно, обнаружит. ведь он до сих пор не видел ни одного необнаруженого ним руткита!
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	209. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 23:44
	> конечно, обнаружит. ведь он до сих пор не видел ни одного необнаруженого ним руткита! Руткит он как суслик: ты его не видишь, а он есть ;))))
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	115. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 01-Сен-11, 14:35
	> просто крындец, безмозглость Меняйте ник, потому как любой специалист по безопасности информационных систем Вам подтвердит: доверять проломленной до рута системе не стоит ни после какого анализа.  Поэтому чтобы задействовать аппаратное обеспечение, программное устанавливается начисто -- с переносом только данных и, возможно, конфигурационных файлов (после надлежащей проверки и по возможности в минимальном объёме).
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	140. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от vi on 01-Сен-11, 16:59
	А если был сохранен отпечаток "системных" файлов, сделанный ну скажем в Integrit или Tripware (или как он там называется), и сохранен на CD-R в отдельном сейфе. Поле этого загружаемся с эталонного CD и проверяем на соответствие с базой, плюс проверить загрузочные скрипты (и прочее). Конечно это займет много времени и саму дыру не уберет (но так для академического интереса). Конечно проще переставить систему. Да и иногда переставлять нужно, а то забудешь, как это делается ;-) И конечно же есть "живущие в памяти" зверюшки, но должна быть дырка в которую они залетят. И есть honeypot, и запись трафика, и прочие плюшки. А вообще молодцы, в прямом смысле, следят! А то, в современном мире, уже не знаешь кому "доверять" (плюс паранойя давит ;) Хотя вопрос о "доверии" это сложный вопрос, сродни тому "А три яблока, это куча?". Или "30-ть Серебрянников" это много или нет :( А вообще, не поступай так, как ты не хотел что бы поступили с тобой! И только ограниченность человеческой жизни (и бесконечность его (чЕЛОВЕЧЕСКОЙ) же "глупости"), дает такие эффекты. Хотя может все дело в том, что если есть возможность, то должно и случится. Квантовые эффекты никто не отменял (да и "бес" попутал :( В общем все есть, так как должно быть (как нам нравится)!
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	163. "Kernel.org подвергся взлому"	+/–
	Сообщение от szh (ok) on 01-Сен-11, 18:06
	> А если был сохранен отпечаток "системных" файлов, сделанный ну скажем в Integrit или Tripware (или как он там называется), и сохранен на CD-R в отдельном сейфе. ага-ага, и после этого не обновляем никакой софт полгода, чтобы после взлома с CD-R сравнивать.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	176. "Kernel.org подвергся взлому"	+/–
	Сообщение от vi on 01-Сен-11, 20:49
	>> А если был сохранен отпечаток "системных" файлов, сделанный ну скажем в Integrit или Tripware (или как он там называется), и сохранен на CD-R в отдельном сейфе. > ага-ага, и после этого не обновляем никакой софт полгода, чтобы после взлома > с CD-R сравнивать. Да, согласен с Вами. Это добавляет несколько шагов в процесс обновления (сам конечно так не делаю, а жаль). Плюс, иногда данные шаги могут быть не приемлемы в процессе. А шаги на мой взгляд должны быть такие: Необходимо остановить систему (может быть неприемлемо). Отключить систему от сети (если обновления планируется устанавливать со сменных носителей). Достать диск из сейфа. Загрузится с эталонного диска. Проверить целостность. Если все в порядке, то продолжим! Подключить систему к сети. Загрузиться в штатный режим. Обновится. Сделать отпечаток системы и сохранить его (и молится что во время обновления к тебе не залетел зверек и не осел где ни будь в памяти (предварительно не изменив что то в "системных" файлах)). Вероятность залета очень мала. Или обновится из режима проверки, что предпочтительно (причем обновления лучше скачать отдельно, на другой машине, и перенести сюда на сменных носителях (при отключенной от сети проверяемой машине)). И сразу же сделать новый отпечаток системы. Сохранить его в надежном месте. Вероятность залета еще меньше (но она ни когда не станет равной нулю, ибо случаи бывают всякие ;-). Спать (более) спокойно! И да, лучше не дожидаться взлома, а делать такие проверки как можно чаще, даже не дожидаясь обновлений. И конечно же, нам не обойтись без "тяжелого, нудного, не престижного, итд., итп.,..." труда, с выходом в "реальность". И без "какого то" удовлетворения здесь не обойтись. Плюс спокойный, здоровый сон! Да, что бы всем!
	Ответить | Правка | ^ к родителю #163 | Наверх | Cообщить модератору

	178. "Kernel.org подвергся взлому"	+/–
	Сообщение от szh (ok) on 01-Сен-11, 21:17
	> сам конечно так не делаю, а жаль Совершенно верно, сложно/дорого > Вероятность залета очень мала. Вероятность залета вообще никакая, если грузиться в спец ранлевел в котором все сервисы не стартуют > Спать (более) спокойно! Для этого проще сходить к психологу, чем тратить полдня на каждое обновление :). Время можно с большей пользой провести в этой жизни. Вообще можно это все делать с виртуализацией удаленно (с ограничением входа на хост с 1 IP), полуавтоматически, т е попутно занимаясь другими делами, а хост систему проверять уже можно не на каждый update, а раз в полгода.
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	243. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от Щекн Итрч (ok) on 02-Сен-11, 12:40
	> А если был сохранен отпечаток "системных" файлов, сделанный ну скажем в Integrit > или Tripware(или как он там называется) Tripware или как он там называется -- КЛЮЧЕВОЕ ВЫРАЖЕНИЕ в дискуссии :) :) :)
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	299. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 05-Сен-11, 15:57
	> Tripware Он Tripwire вообще-то.
	Ответить | Правка | ^ к родителю #243 | Наверх | Cообщить модератору

	263. "Kernel.org подвергся взлому"	+/–
	Сообщение от DeadLoco (ok) on 02-Сен-11, 18:43
	> А если был сохранен отпечаток "системных" файлов, сделанный ну скажем в Integrit или Tripware Дык, если есть рут и доступ к бинарнику ядра, то можно сделать все, что угодно. Включая подмену файлов на чистые оригиналы при открытии дескрипторов. Или, например, пишешь ls -l, а стартует rm -rf. ПРОФИТ!
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	268. "Kernel.org подвергся взлому"	+/–
	Сообщение от Клыкастый (ok) on 02-Сен-11, 19:46
	> ...любой специалист по безопасности... > доверять проломленной до рута системе не стоит ни после какого анализа. возможно он виндовсятник с верой в силу и мощь Касперского?
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	144. "Kernel.org подвергся взлому"	+/–
	Сообщение от Daemontux (ok) on 01-Сен-11, 17:10
	Не существует математически доказанного способа откатить взломанную систему в безопасное состояние.Остается только востановление из бекапа или переустановка.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	165. "Kernel.org подвергся взлому"	+/–
	Сообщение от Мяут (ok) on 01-Сен-11, 18:19
	> Не существует математически доказанного способа откатить взломанную систему в безопасное > состояние.Остается только востановление из бекапа или переустановка. Запускать в Bochs и трассировать выполнение покомандно :) Ну для истинных любителей конечно :)
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	168. "Kernel.org подвергся взлому"	+/–
	Сообщение от anonymous (??) on 01-Сен-11, 18:34
	>> Не существует математически доказанного способа откатить взломанную систему в безопасное >> состояние.Остается только востановление из бекапа или переустановка. > Запускать в Bochs и трассировать выполнение покомандно :) Ну для истинных любителей > конечно :) не работает. сначала надо доказать тождественность боша и железа. и безошибочность работы железа, на котором запущен бош. и…
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	195. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 23:02
	> Не существует математически доказанного способа откатить взломанную систему в безопасное > состояние. В принципе, откат снапшотов на незараженное состояние - довольно близко к именно этому способу, особенно в реализации как у виртуализаторов, когда CoW применяется к вообще всей области диска и может быть откачено все, вплоть до бутсекторов [актуально если развивать паранойю и бояться и буткитов до кучи] :).
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

	244. "Kernel.org подвергся взлому"	+/–
	Сообщение от Щекн Итрч (ok) on 02-Сен-11, 12:43
	>> Не существует математически доказанного способа откатить взломанную систему в безопасное >> состояние. > В принципе, откат снапшотов на незараженное состояние - довольно близко к именно > этому способу Осталось понять, где в стоге лент «незараженное состояние» :) :) :)
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	245. "Kernel.org подвергся взлому"	+/–
	Сообщение от anonymous (??) on 02-Сен-11, 12:45
	> Осталось понять, где в стоге лент «незараженное состояние» :) :) :) определить по запаху.
	Ответить | Правка | ^ к родителю #244 | Наверх | Cообщить модератору

	283. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 03-Сен-11, 00:10
	> Осталось понять, где в стоге лент «незараженное состояние» :) :) :) Почему сразу лент? Можно и просто на диске. Заведомо незараженное - сразу после инсталла или если удалось понять дату взлома - до нее.
	Ответить | Правка | ^ к родителю #244 | Наверх | Cообщить модератору

	291. "Kernel.org подвергся взлому"	+/–
	Сообщение от Щекн Итрч (ok) on 03-Сен-11, 18:00
	>> Осталось понять, где в стоге лент «незараженное состояние» :) :) :) > Почему сразу лент? Можно и просто на диске. Заведомо незараженное - сразу > после инсталла или если удалось понять дату взлома - до нее. Осталось «понять дату взлома» :)
	Ответить | Правка | ^ к родителю #283 | Наверх | Cообщить модератору

	292. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 04-Сен-11, 01:21
	> Осталось «понять дату взлома» :) Ну так логи на что? Хотя можно и без разборов сразу на послеинсталляционный вариант. Беспроигрышная лотерея ;)
	Ответить | Правка | ^ к родителю #291 | Наверх | Cообщить модератору

	193. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 22:51
	> Очередной раз поражаюсь дибилизму среди луноходов Oh sh-! Капитан сообщает: вы установили новый антирекорд опеннета по зрительским симпатиям, сделав даже господина Трухина. Эпично!!! > просто крындец, безмозглость Вы не представляете себе что могут руткиты, и почему следует переставить систему в случае взлома, но при этом называетесь bezopasnik.org?! Поздравляю, вы победили в номинации "EPIC FAIL года" на опеннете! Ппцъ^2!
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

4. "Kernel.org подвергся взлому"	+/–
Сообщение от Аноним (??) on 01-Сен-11, 09:17
Совсем расслабились.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Kernel.org подвергся взлому"	+/–
Сообщение от Анонимо on 01-Сен-11, 09:25
История с титаником людей так ничему и не научила, все думали что он непотопляемый, а он взял и пустил пузыри.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	269. "Kernel.org подвергся взлому"	+/–
	Сообщение от Клыкастый (ok) on 02-Сен-11, 19:47
	> История с титаником людей так ничему и не научила, все думали что > он непотопляемый, а он взял и пустил пузыри. Чукча не читатель, чукча - писатель? Кратко о главном: люди пролюбили доступы на сервер.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

7. "Kernel.org подвергся взлому"	+2 +/–
Сообщение от Аноним (??) on 01-Сен-11, 09:27
linux уже ломают на заказ
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Kernel.org подвергся взлому"	–5 +/–
	Сообщение от Аноним (??) on 01-Сен-11, 09:52
	Не верю, что кто-то из Linux-хакеров (а кроме них некому такой взлом осуществить) станет ломать свой же родной Линукс кому-то на заказ. Скорее всего ради лулзов, ну, или потролить Торвальдса (может Гномеры обиделись:)).
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	16. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 09:59
	А кто говорит про Linux-хакеров? Тут все посерьезнее будет.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	34. "Kernel.org подвергся взлому"	+2 +/–
	Сообщение от mihon73 on 01-Сен-11, 10:34
	что вы все намеками да намеками. Есть предположения, есть что сказать - говорите. Нету, то и писать не стоит. Кому тут интересно согласны ли вы с утверждением или нет?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	40. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 10:46
	Скрытая реклама git. Хы
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	211. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 23:47
	> что вы все намеками да намеками. Есть предположения, есть что сказать - > говорите. Нету, то и писать не стоит. За любым действием стоит тот кому это нужно. Так что намеки - вполне могут быть обоснованы.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	38. "Kernel.org подвергся взлому"	–2 +/–
	Сообщение от Аноним (??) on 01-Сен-11, 10:45
	Мелкософт и иже с ним, КГБ?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	112. "Kernel.org подвергся взлому"	–2 +/–
	Сообщение от Fantomas (??) on 01-Сен-11, 14:30
	да нет, сам Сатанаил лично :-)
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	20. "Kernel.org подвергся взлому"	–4 +/–
	Сообщение от Аноним (??) on 01-Сен-11, 10:11
	> Не верю, что кто-то из Linux-хакеров (а кроме них некому такой взлом > осуществить) станет ломать свой же родной Линукс кому-то на заказ. Скорее > всего ради лулзов, ну, или потролить Торвальдса (может Гномеры обиделись:)). Родной Linux? Он им чего, мама?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	131. "Kernel.org подвергся взлому"	–3 +/–
	Сообщение от Moomintroll (ok) on 01-Сен-11, 16:27
	> Родной Linux? Он им чего, мама? Жена. Со всеми вытекающими... ;-)
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	270. "Kernel.org подвергся взлому"	–1 +/–
	Сообщение от Клыкастый (ok) on 02-Сен-11, 19:51
	Что такое "родной Линукс?" Есть задача. Или заказ. Вот они - "родные". А Маша, Петя, Линукс, Виндовс, BSD - это всё вторично.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

9. "Kernel.org подвергся взлому"	+/–
Сообщение от Аноним (??) on 01-Сен-11, 09:32
А какой дистрибутив стоял на серверах ? Не иначе RedHat в котором нет уязвимостей :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 10:10
	Уязвимостей нет, есть исправления.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	73. "Kernel.org подвергся взлому"	–3 +/–
	Сообщение от Аноним (??) on 01-Сен-11, 12:02
	> Уязвимостей нет, есть исправления. Ты еще скажи, что их не бывает, уязвимостей-то, в Линуксе священном. Только исправления - исправления ЧЕГО? Сам-то понял, какую ересь ляпнул?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	114. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 14:31
	>> Уязвимостей нет, есть исправления. > Ты еще скажи, что их не бывает, уязвимостей-то, в Линуксе священном. Только > исправления - исправления ЧЕГО? Сам-то понял, какую ересь ляпнул? КО говорит, это был сарказм.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	185. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 22:24
	Веб-сервер kernel.org обслуживает Fedora... В этом нетрудно убедиться самому.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	194. "Kernel.org подвергся взлому"	+/–
	Сообщение от crypt (??) on 01-Сен-11, 22:54
	> А какой дистрибутив стоял на серверах ? > Не иначе RedHat в котором нет уязвимостей :) На Fedora там все: и зевс1, и зевс2. Все-таки вменяемые админы на сервера Федору не ставят.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "Kernel.org подвергся взлому"	–9 +/–
Сообщение от Аноним (??) on 01-Сен-11, 09:33
> По предположению администраторов проекта проникновение было совершено через утечку параметров одного из аккаунтов. Данное предположение подтверждает обнаружение троянского ПО на машине одного из разработчиков ядра, который имел доступ к двум взломанным серверам (Hera и Odin1). А говорили под Linux троянов не бывает. Как же так ?! неужели обманывали ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Kernel.org подвергся взлому"	+/–
	Сообщение от sndev (ok) on 01-Сен-11, 09:41
	А как же руткиты ? Это в принципе троянское ПО как на него не смотри.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	57. "Kernel.org подвергся взлому"	+2 +/–
	Сообщение от СуперАноним on 01-Сен-11, 11:12
	Всё-таки, есть существенное отличие троянов от руткитов. Чаще всего, ламеры сами добровольно троянов ставят под благовидным предлогом: хранители экрана, Skype, Adobe Flash, ...
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	101. "Kernel.org подвергся взлому"	–2 +/–
	Сообщение от nuclight (ok) on 01-Сен-11, 13:58
	> А как же руткиты ? Это в принципе троянское ПО как на > него не смотри. Не бывает "доброго" и "троянского" ПО. Это всего лишь инструмент, и всё дело в целях использования - ножом можно хлеб резать, а можно и человека убить. Сниффером можно пароли воровать, но можно и проблемы сети диагностировать. Сканеры портов - типичные "хакерские инструменты" - используются для аудита безопасности, наряду со средствами, проверяющими на наличие удаленных дырок (можно сказать, ломают, но чисто технически). И так - абсолютно во всём. Каково благонамеренное применение руткитов, оставляю подумать в качестве домашнего задания.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	120. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от sndev (ok) on 01-Сен-11, 14:50
	A давайте, для начала, в качестве домашнего задания, вы прочитаете хотя бы определение слова rootkit ?
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	123. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Сен-11, 14:57
	> A давайте, для начала, в качестве домашнего задания, вы прочитаете хотя бы > определение слова rootkit ? Тёзка, начинаем подсчёт лопухов? :)
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	192. "Kernel.org подвергся взлому"	–2 +/–
	Сообщение от nuclight (ok) on 01-Сен-11, 22:34
	> A давайте, для начала, в качестве домашнего задания, вы прочитаете хотя бы > определение слова rootkit ? Выпендриться хочется, а думать не хочется? Понимаю, бывает. Ну ничего, с годами и ростом кругозора это проходит. Могу посоветовать почитать про IPS/IDS, которые сами используют rootkit-технологии (для самозащиты от злонамеренного софта). Вот на http://northsecuritylabs.com/ru/ хороший образчик, например.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	213. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от Аноним (??) on 01-Сен-11, 23:54
	> хороший образчик, например. Мне не нравится этот тип, но он тем не менее прав. Например, каспер - по сути сам руткит: заворачивает все системные вызовы которые могут ему повредить. Виртуализаторы с мониторингом гуеста их "невидимого" хоста - тоже этакий руткит наоборот. Технологии применяемые в руткитах могут и на админа работать, если превентивно "забэкдорить" систему в пользу админа но против хакера :))
	Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

	33. "Kernel.org подвергся взлому"	+2 +/–
	Сообщение от FSA (ok) on 01-Сен-11, 10:32
	Кто говорил, что не бывает? Бывают. Просто для того, чтобы написать приличный троян нужно найти уязвимость, которая позволит повысить привилегии на машине, иначе дальше домашней папки пользователя троян не уйдёт. В Windows при ограничении привилегий работать становится практически невозможно. Вылавливание всех веток реестра и каталогов, куда пишут программы, отнимает кучу времени. Поэтому все дома сидят под админами. В результате любая программа может делать всё, что хочет. Ваш КО.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	78. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 12:12
	> В Windows при ограничении привилегий работать становится практически невозможно. Там уже давно все точно так же, как в линухе. Пароль вводить надо только для установки/удаления программ или для изменения системных настроек. > Поэтому все дома сидят под админами. ССЗБ.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	79. "Kernel.org подвергся взлому"	+5 +/–
	Сообщение от anonymous (??) on 01-Сен-11, 12:17
	> Там уже давно все точно так же, как в линухе. не прошло и ста лет, угу.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	147. "Kernel.org подвергся взлому"	+/–
	Сообщение от vi on 01-Сен-11, 17:16
	>> В Windows при ограничении привилегий работать становится практически невозможно. > Там уже давно все точно так же, как в линухе. Пароль вводить > надо только для установки/удаления программ или для изменения системных настроек. А кто их там перед установкой проверяет на соответствие заявленным функциям и фактически выполняемым. Или кто то из производителей подписался "на зуб", а? Канделябры еще конечно же производить не перестали, но гонятся уж больно накладно выходит. Да еще в кутузку можно загреметь за самоуправство. Хотя иногда для профилактики это просто необходимость. > ССЗБ.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	186. "Kernel.org подвергся взлому"	+/–
	Сообщение от crypt (??) on 01-Сен-11, 22:26
	> А говорили под Linux троянов не бывает. Как же так ?! неужели > обманывали ? Трояны бывают. Массовых эпидемий под 2 миллиона не бывает.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	271. "Kernel.org подвергся взлому"	+/–
	Сообщение от Клыкастый (ok) on 02-Сен-11, 19:54
	> А говорили под Linux троянов не бывает. Как же так ?! неужели > обманывали ? Вася пролюбил ключ от квартиры. В квартиру попал Ваня и поставил жучок. "Ай, какие плохие двери". вы либо тролль, либо не вникли в суть новости. есть третий вариант, но он обидный и сообщение вытрут.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

15. "Kernel.org подвергся взлому"	+10 +/–
Сообщение от Fomalhaut on 01-Сен-11, 09:56
ПО без ошибок практически несуществует (если только "Hello world!" и то не факт, что компилятор не ступит). Но вопрос не в количестве уязвимостей (это лучший членомер для многих), а в сроках их исправления, а так же сложности, т.е. архитектурных ограничениях.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Kernel.org подвергся взлому"	+/–
Сообщение от Аноним (??) on 01-Сен-11, 10:03
>судя по всему был задействован эксплоит для еще публично не известной уязвимости. А вот это самое интересное. Тоесть есть какая то дыра про которую еще даже не знают. А хакеры активно юзают :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Kernel.org подвергся взлому"	+3 +/–
Сообщение от ioim on 01-Сен-11, 10:08
Порадовало название сервера "Odin1" :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Kernel.org подвергся взлому"	+2 +/–
	Сообщение от crunch (??) on 01-Сен-11, 10:15
	Hera тоже ничего :)
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	26. "И правда"	+3 +/–
	Сообщение от Василий (??) on 01-Сен-11, 10:23
	И правда удивительно, мешали и немецкую и древнегреческую мифологию вместе. :)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	56. "И правда"	+5 +/–
	Сообщение от Живот on 01-Сен-11, 11:12
	Вот и поплатились
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	62. "И правда"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Сен-11, 11:28
	> Вот и поплатились Египетские боги воспользовались известным принципом «разделяй и властвуй»?
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	104. "И правда"	+/–
	Сообщение от emg81 (ok) on 01-Сен-11, 14:08
	я думал, римские боги будут этим так орудовать...
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	119. "И правда"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Сен-11, 14:47
	> я думал, римские боги будут этим так орудовать... Я тоже, но их, поди, отличи от древнегреческих. С другой стороны, опыт перенимать никто не мешает. :)
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	187. "Kernel.org подвергся взлому"	+/–
	Сообщение от crypt (??) on 01-Сен-11, 22:26
	> Hera тоже ничего :) Как сервер назовешь...
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

21. "Kernel.org подвергся взлому"	+4 +/–
Сообщение от Аноним (??) on 01-Сен-11, 10:13
Больше всего удивило упоминание 448 аккаунтов. Даже предположить не мог, что ума хватит разместить хостинг для страниц обычных пользователей (userweb.kernel.org) на первичном сервере, через который раздается ядро. Судя по всему даже chroot-а отдельного не создали и все 448 могли входить по SSH и запускать что душе угодно с любых IP. На такие системы нужно пускать только нескольких ключевых администраторов только с одной шлюзовой машины внутри сети к которой пускать только с конкретных IP, а не светить SSH на весь интернет.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Kernel.org подвергся взлому"	+/–
	Сообщение от Анон on 01-Сен-11, 10:21
	Сис. Админов на них нехватает!!!
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	86. "Kernel.org подвергся взлому"	+/–
	Сообщение от Денис (??) on 01-Сен-11, 12:51
	> а не светить SSH  на весь интернет. Хотел добавить что простым пользователям, не админам нужно предоставлять доступ не на реальный сервер kernel.org а на виртуальную машину которая на этом kernel.org будет крутиться, а реальная машина уже все ip покажет. Хотя я считаю что все было случайно - никакого целенаправленного взлома не было, просто пользователь kernel.org зашел на сервер, не из дома, а из гостей, через скажем putty, а на этом компе была винда с трояном-клавиатурным-шпионом, вот и все. Все как всегда тупо и банально...
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	116. "Kernel.org подвергся взлому"	+/–
	Сообщение от Fantomas (??) on 01-Сен-11, 14:41
	У меня так было. Позвонили. Нужно было срочно залезть. Ядерного чемоданчика (лаптопа) с собой небыло. Поставил там где был на машину Путти и полез. В последствии пользуясь случившимся заодно поменял и железо.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	142. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 01-Сен-11, 17:02
	> У меня так было. Позвонили. Нужно было срочно залезть. Ядерного чемоданчика (лаптопа) > с собой небыло. Поставил там где был на машину Путти Уж лучше загрузочный телефон с собой таскать.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	146. "Kernel.org подвергся взлому"	+/–
	Сообщение от Andrey Mitrofanov on 01-Сен-11, 17:14
	>загрузочный телефон Джеймс Бонд... ботинок-телефон... Или это был не Бонд? Ж)
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

24. "Kernel.org подвергся взлому"	–6 +/–
Сообщение от Атребатов on 01-Сен-11, 10:21
я уверен что взлом осуществлял сотрудник спецслужбы... им щас мало платят, они ведут скрытый шпионаж с целью получения информации о финансовых возможностей пользователей и место дислокации оных... потом дожидаются удобное время, например день получки или поход разрабатываемого лоха к банку и грабят используя черную рабочую силу в виде запуганных прежде завербованных агентов с криминальной архитектурой психики... я уверен в этом на 100%.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Kernel.org подвергся взлому"	+3 +/–
	Сообщение от FractalizeR (ok) on 01-Сен-11, 10:24
	Еще одна теория заговора...
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	220. "Kernel.org подвергся взлому"	+/–
	Сообщение от askh (ok) on 02-Сен-11, 00:28
	Люди, которые видят во всём теории заговора, выглядят, мягко говоря, странно. Однако не менее странно выглядят и люди, которые уверены, что никаких заговоров в принципе не существует. Видимо это две крайности — излишнее усложнение ситуации, и излишнее упрощение её же. А здравый смысл — он где-то между ними. Конкретно в данной ситуации странно отвергать версии о возможной причастности спецслужб — возможности у них есть, мотивы — есть (они касаются не только Linux, но и Windows, и другого софта — любая разведка высоко оценила бы возможность внедрить известный только им бэкдор в софт, который использует "вероятный противник"). Конечно, если в деле замешаны спецслужбы, вряд ли это откроется, то есть это такая ситуация, когда доказать наличие явления достаточно сложно, но при этом догадаться о его существовании достаточно легко. Если бы ты был сотрудником какой-нибудь спецслужбы, от которого зависело, быть или не быть попыткам внедрить свой бэкдор в массово используемые системы, как бы ты поступил?
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	222. "Kernel.org подвергся взлому"	+/–
	Сообщение от anonymous (??) on 02-Сен-11, 00:33
	заслуженый ветеран секретных операций Вещает.
	Ответить | Правка | ^ к родителю #220 | Наверх | Cообщить модератору

	231. "Kernel.org подвергся взлому"	+/–
	Сообщение от askh (ok) on 02-Сен-11, 08:57
	> заслуженый ветеран секретных операций Вещает. Нет, просто человек со здравым смыслом. Если у кого-то есть возможность, есть мотив, и если этот кто-то может действовать скрытно, что это означает? Что он не действует? Нелогично ведь, но примерно это и имеют в виду те, кто скептически пишут "очередная теория заговора".
	Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

	237. "Kernel.org подвергся взлому"	+/–
	Сообщение от FractalizeR (ok) on 02-Сен-11, 10:56
	> Люди, которые видят во всём теории заговора, выглядят, мягко говоря, странно. Однако > не менее странно выглядят и люди, которые уверены, что никаких заговоров > в принципе не существует. А кто все эти люди? :) > любая разведка высоко оценила бы возможность внедрить известный только им бэкдор в софт Конечно. Только пост, на который я отвечал, вовсе не об этом. Прочитайте его снова и оцените, о чем там речь идет. А внедрять супер-функциональный-никому-неизвестный-бекдор в файлы, лежащие в Git и думать, что это не обнаружится, может кто угодно, только не сотрудники спецслужб. Во всяком случае, я искренне надеюсь, что они не настолько тупы.
	Ответить | Правка | ^ к родителю #220 | Наверх | Cообщить модератору

	238. "Kernel.org подвергся взлому"	+/–
	Сообщение от askh (ok) on 02-Сен-11, 11:46
	> Конечно. Только пост, на который я отвечал, вовсе не об этом. Прочитайте его снова и оцените, о чем там речь идет. Ага, я сам не согласен с тем постом, но не согласен и с вашим аргументом "Еще одна теория заговора...". Та конкретная теория заговора выглядит маловероятной. Однако недостаточно назвать что-то теорией заговора чтобы считать версию опровергнутой. Суть моих возражений в том, что вы использовали некорректный аргумент, а если говорить о теме дискуссии, я так же несогласен с вашим оппонентом. > А внедрять супер-функциональный-никому-неизвестный-бекдор в файлы, лежащие в Git и думать, что это не обнаружится, может кто угодно, только не сотрудники спецслужб. Во всяком случае, я искренне надеюсь, что они не настолько тупы. Представим такой вариант: кто-то делает коммит, он подменяется, у автора коммита что-то случается с компьютером (воруют например), и он заново скачивает исходники ядра, не обнаружив разницы между тем, что он на самом деле сделал и тем, что находится в репозитории. Просто вносить бэкдор — это конечно было бы глупо, но почему мы должны считать, что спецслужбы действуют примитивно и прямолинейно? И, кстати, я не настаиваю на том, что обсуждаемый инцидент — это дело рук спецслужб. Какая разница в смысле последствий инцидента, спецслужбы это были или нет?
	Ответить | Правка | ^ к родителю #237 | Наверх | Cообщить модератору

	251. "Kernel.org подвергся взлому"	+/–
	Сообщение от FractalizeR (ok) on 02-Сен-11, 14:14
	> Ага, я сам не согласен с тем постом, но не согласен и > с вашим аргументом "Еще одна теория заговора...". Та конкретная теория заговора > выглядит маловероятной. Однако недостаточно назвать что-то теорией заговора чтобы считать версию опровергнутой. Суть моих возражений в том, что вы использовали некорректный > аргумент, а если говорить о теме дискуссии, я так же несогласен > с вашим оппонентом. "Еще одна теория заговора" - это уж конечно не аргумент вовсе. Почитайте http://ru.wikipedia.org/wiki/Аргумент_%28логика%29 Это просто осуждение содержания поста с моей стороны. Причем очень конкретного содержания. Я пренебрежительно высказался о КОНКРЕТНОМ содержании поста и о КОНКРЕТНОЙ "теории заговора", которая ТАМ описана. Не стоит придавать моим словам другой смысл и спорить со мной о том, чего я не подразумевал. > Представим такой вариант: кто-то делает коммит, он подменяется, у автора коммита что-то > случается с компьютером (воруют например), и он заново скачивает исходники ядра, > не обнаружив разницы между тем, что он на самом деле сделал > и тем, что находится в репозитории. Насколько мне известно, в Git невозможно подменить коммит задним числом. Можно только новый провести от чьего-то имени. А засовывать бекдор в новый коммит это как-то рискованно. Хотя бы из-за review коммитов. > И, кстати, я не настаиваю на том, что обсуждаемый инцидент — это дело рук спецслужб. Какая разница в смысле последствий инцидента, спецслужбы это были или нет? В смысле фразы Теория заговора, к которой вы прицепились :) http://ru.wikipedia.org/wiki/Теория_заговора Если внедрение бекдора провел Вася Пупкин, то вряд ли можно говорить о "теории заговора". Я не спорю, что спецслужбам бы не помешал бекдор в Линуксе. Однако чтобы он предназначался для, цитирую "скрытый шпионаж с целью получения информации о финансовых возможностей пользователей и место дислокации оных" - мне представляется сомнительным. Для того, чтобы внедрить бекдор, проще кого-нибудь из разработчиков пошантажировать или самому стать доверенным разработчиком. Человеку из службы, не обделенному интеллектом, я думаю, это будет несложно. Долго - да. Но цель того стоит, наверное. А действовать так прямолинейно - ломать сервер, что-то подменять, да еще в Git, который обладает собственной защитой... Ну, возможно, конечно. Но как-то уж не слишком вероятно. Я бы действовал по-другому. Да я бы вообще постарался это в Windows проделать :)). Там код закрыт. Внедри что-нибудь хитрое - код видит гораздо меньшее количество людей. Больше шансов, что прокатит. Смотря какая цель, конечно.
	Ответить | Правка | ^ к родителю #238 | Наверх | Cообщить модератору

	252. "Kernel.org подвергся взлому"	+/–
	Сообщение от anonymous (??) on 02-Сен-11, 14:20
	> Для того, чтобы внедрить бекдор, проще кого-нибудь из разработчиков пошантажировать > или самому стать доверенным разработчиком. кроме этого — заставить молчать *всех*, кто может прочитать (и читает, и иногда патчит) ядро. в каждой из стран, где такие есть. согласен, некоторое время оно может жить. а потом неизбежно всплывёт, и будет скандал. нет, даже СКАНДАЛ. именно поэтому вряд ли кто-то будет трогать подобные вещи, это слишком топорно. и если это понимаю я, то вне сомнения понимают и работники спецслужб. которые вовсе не тупые солдафоны.
	Ответить | Правка | ^ к родителю #251 | Наверх | Cообщить модератору

	258. "Kernel.org подвергся взлому"	+/–
	Сообщение от FractalizeR (ok) on 02-Сен-11, 16:07
	> согласен, некоторое время оно может жить. а потом неизбежно всплывёт, и будет > скандал. нет, даже СКАНДАЛ. именно поэтому вряд ли кто-то будет трогать > подобные вещи, это слишком топорно. и если это понимаю я, то > вне сомнения понимают и работники спецслужб. которые вовсе не тупые солдафоны. Да, все верно. Хотя, может быть, принципиально возможно оставить уязвимость, которую будет сложно найти. А если ее обнаружат - притвориться, что ты оставил ее по глупости.
	Ответить | Правка | ^ к родителю #252 | Наверх | Cообщить модератору

	29. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 10:26
	Бред. Сам ты псих. Это очередной just for fun.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

30. "Kernel.org подвергся взлому"	+/–
Сообщение от Аноним (??) on 01-Сен-11, 10:26
так что там за дистрибутив был? у меня c такими же симптомами центос пару лет назад ломали. вот тут обсуждалось http://www.webhostingtalk.com/showthread.php?t=873301 но с тех пор ничего не поменялось, увы
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	190. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 22:31
	> так что там за дистрибутив был? у меня c такими же симптомами > центос пару лет назад ломали. вот тут обсуждалось Админский сайт, е-мае... Не могут зайти на http://kernel.org и посмотреть. Fedora там.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	215. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 23:59
	> Админский сайт, е-мае... Не могут зайти на http://kernel.org и посмотреть. Fedora там. Что настораживает - перец подозревал openssh 0day но его кажется с тех пор никто не нашел. А что если openssh не настолько уж и S, и матрица нас все-таки имеет?
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

32. "Kernel.org подвергся взлому"	+3 +/–
Сообщение от Tito (??) on 01-Сен-11, 10:29
на Kernel.org написано: "We have notified authorities in the United States and in Europe to assist with the investigation" Почемуто думается что как раз "authorities"  и организаторы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	39. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 10:46
	Тем легче им будет "to assist"
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

37. "Kernel.org подвергся взлому"	–1 +/–
Сообщение от centosuser (ok) on 01-Сен-11, 10:41
>Кроме того, было инициировано несколько проверок целостности кода с задействование других, параллельно созданных, хэшей, а также проведение детального аудита всех последних изменений в коде. Чем то они похожи на нашу милицию, тех пока за яйца не прижмут, они будут врать, что мы не виноваты. А когда появятся неопровержимые факты, что отмазываться уже будет глупо - появляется козёл отпущения. Какое там ядро было до 12 августа ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	166. "Kernel.org подвергся взлому"	–1 +/–
	Сообщение от szh (ok) on 01-Сен-11, 18:20
	> Чем то они похожи на нашу милицию какие больные ассоциации
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

45. "Kernel.org подвергся взлому"	–1 +/–
Сообщение от lalolim on 01-Сен-11, 10:56
А собственно зачем ломать? Исходники и так доступны. Или там хотели незаметно внедрить код чтобы 1% пользователей таки можно было вирусами заражать?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	58. "Kernel.org подвергся взлому"	+8 +/–
	Сообщение от Frank (ok) on 01-Сен-11, 11:14
	Ну это же очевидно - хотели иксы туда поставить!
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	191. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 22:32
	> А собственно зачем ломать? Исходники и так доступны. > Или там хотели незаметно внедрить код чтобы 1% пользователей таки можно было > вирусами заражать? Ты забыл про 60% веб-серверов...
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

69. "Kernel.org подвергся взлому"	–5 +/–
Сообщение от Аноним (??) on 01-Сен-11, 11:47
> судя по всему был задействован эксплоит для еще публично неизвестной уязвимости. Ядро стало таким большим и содержит столько дыр что такие новости уже не удивляют. Печально... Единственный плюс, можно смело обновлять свой Android и быть уверенным что и для новой прошивки можно будет получить root :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	70. "Kernel.org подвергся взлому"	+/–
	Сообщение от x on 01-Сен-11, 11:56
	> ... быть уверенным что и для новой прошивки можно будет получить root. Ну пока еще не совсем понятно как его получать. Пока только избранные могут поюзать любой Linux-сервер в своих целях и всего-то. Интересно DigiNotar тоже на Linux крутился?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	167. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от Аноним (??) on 01-Сен-11, 18:33
	>> ... быть уверенным что и для новой прошивки можно будет получить root. > Ну пока еще не совсем понятно как его получать. Пока только избранные > могут поюзать любой Linux-сервер в своих целях и всего-то. > Интересно DigiNotar тоже на Linux крутился? Вряд ли. HTTP/1.1 200 OK Content-Length: 437 Content-Type: image/gif Last-Modified: Mon, 31 Aug 2009 12:59:08 GMT Accept-Ranges: bytes Etag: "07699d33a2aca1:117e" Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Date: Thu, 01 Sep 2011 15:44:59 GMT
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	169. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от anonymous (??) on 01-Сен-11, 18:46
	> Server: Microsoft-IIS/6.0 > X-Powered-By: ASP.NET и вот *это* было «довереным центром»? правильно, правильно я их все превентивно выкидываю, не разбираясь, где кто.
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	284. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 03-Сен-11, 00:14
	Ну вот их хакеры тоже не оставили без внимания.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

82. "Kernel.org подвергся взлому"	+/–
Сообщение от user (??) on 01-Сен-11, 12:28
>проникновения было выявлено после того, как администраторы заметили в логе упоминание ошибки доступа к /dev/mem со стороны Xnest, в то время как Xnest не был установлен на серверах Прелесть какая.... а сколько там еще троянов необнаруженых висит... Опубликуйте ВСЕЬ список установленного на сервере софта, чтоб в следующий раз парням не палицца так по глупому...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	204. "Kernel.org подвергся взлому"	+/–
	Сообщение от crypt (??) on 01-Сен-11, 23:31
	>>проникновения было выявлено после того, как администраторы заметили в логе упоминание ошибки доступа к /dev/mem со стороны Xnest, в то время как Xnest не был установлен на серверах > Прелесть какая.... а сколько там еще троянов необнаруженых висит... Да уж, было сложно не заметить, что что-то не так: http://www.spinics.net/lists/kernel/msg1229170.html
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	207. "Kernel.org подвергся взлому"	+/–
	Сообщение от crypt (??) on 01-Сен-11, 23:42
	http://www.spinics.net/lists/kernel/msg1229170.html 20110823.log:Aug 23 17:22:52 console1 port05  RXDATA: [   70.626511] Program Xnest tried to access /dev/mem between 0->8000000. 20110823.log:Aug 23 17:22:53 console1 port05  RXDATA: [   71.610908] Xnest[4485]: segfault at 7f51210dfaa8 ip 000000000040c544 sp 00007fffdadb5970 error 6 in .p-2.5f[400000+15000] 20110823.log:Aug 23 17:22:54 console1 port05  RXDATA: Fedora release 14 (Laughlin) 20110823.log:Aug 23 17:22:54 console1 port05  RXDATA: Kernel 3.1.0-rc2+ on an x86_64 (/dev/ttyS0) 20110823.log:Aug 23 17:22:55 console1 port05  RXDATA: hera.kernel.org login: Xnest (pid 4485) попытался обратиться по запрещенному адресу и упал. Запущен был из .p-2.5f - это признак руткита phalanx 2.5f , который не детектится rkhunter
	Ответить | Правка | ^ к родителю #204 | Наверх | Cообщить модератору

	217. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 02-Сен-11, 00:03
	Ы, походу руткит себя паниками палил :).Странно что его сразу тогда же и не поймали.
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

99. "Kernel.org подвергся взлому"	+/–
Сообщение от hummermania (ok) on 01-Сен-11, 13:47
Ну и что? Ситуацию проанализируют, разрабам софта через который был взлом дадут Pull Request - те поправят и никто не получит вероятно модифицированное ядро. Если его вообще удалось как-то испортить. Кроме того на месте с кернел.org мог бы быть любой сервер в мире. И взлом линукс серверов чаще всего происходит из-за уязвимостей в софте-окружении, и где недоглядели админы. Вот и все. Инцидент исчерпает себя через пару дней. Обычная рабочая обстановка.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

106. "Kernel.org подвергся взлому"	–11 +/–
Сообщение от nuclight (ok) on 01-Сен-11, 14:11
Какая наивная уверенность, что Git обеспечивает защиту. Совершенно никто не мешал злоумышленникам модифицировать Git так, чтобы левый патч внедрился в коммит незаметно от разработчика _перед_ подсчетом хэша. Всё, хэш будет корректен, никаких изменений задним числом (зачем править старое, когда можно внести новое? они не так уж мало времени там торчали) не требуется - чего инструменту подсунули, то он и посчитал-подписал.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	109. "Kernel.org подвергся взлому"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Сен-11, 14:26
	> Какая наивная уверенность, что Git обеспечивает защиту. Совершенно никто не мешал злоумышленникам > модифицировать Git так, чтобы левый патч внедрился в коммит незаметно от > разработчика _перед_ подсчетом хэша. Всё, хэш будет корректен, никаких изменений задним > числом (зачем править старое, когда можно внести новое? они не так > уж мало времени там торчали) не требуется - чего инструменту подсунули, > то он и посчитал-подписал. Имелось в виду, что при попытке обновиться из «подправленного» репозитория, о факте изменений узнали бы все, кто уже ранее его загружал.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	180. "Kernel.org подвергся взлому"	+/–
	Сообщение от nuclight (ok) on 01-Сен-11, 22:06
	>> Какая наивная уверенность, что Git обеспечивает защиту. Совершенно никто не мешал злоумышленникам >> модифицировать Git так, чтобы левый патч внедрился в коммит незаметно от >> разработчика _перед_ подсчетом хэша. Всё, хэш будет корректен, никаких изменений задним >> числом (зачем править старое, когда можно внести новое? они не так >> уж мало времени там торчали) не требуется - чего инструменту подсунули, >> то он и посчитал-подписал. > Имелось в виду, что при попытке обновиться из «подправленного» репозитория, > о факте изменений узнали бы все, кто уже ранее его загружал. Так репозиторий-то "подправлять" и не требуется. Достаточно пропатчить working copy в начале фазы коммита, и скрыть эти изменения в выводе. Задел на будущее, старое править - смысл?..
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	197. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 23:16
	> Так репозиторий-то "подправлять" и не требуется. Достаточно пропатчить working copy в начале > фазы коммита, и скрыть эти изменения в выводе. Задел на будущее, > старое править - смысл?.. Ключевое выражение "и скрыть эти изменения в выводе". Это физически невозможно так как будет новый коммит, соответственно все новые коммиты проходят полностью аудит сотнями глаз. Скрыть в нем закладку от имени уважаемого разработчика не получится, даже если коммит в несколько тысяч строк, он ранее проходит достаточно длительный процесс утверждения и обсуждения, после его принятия все внесенные изменения сразу будут видны, так как diff с ранее обсуждаемой версией все покажет. PS. На какой-то конференции Линус хвастался, что ему не нужны бэкапы и достаточно периодически сохранять на флешку контрольный хэш SHA. Если что случиться он может загрузить любую копию репозитория из вне, идентичность которой до времени копирования SHA можно гарантировать.
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	206. "Kernel.org подвергся взлому"	+/–
	Сообщение от nuclight (ok) on 01-Сен-11, 23:41
	>> Так репозиторий-то "подправлять" и не требуется. Достаточно пропатчить working copy в начале >> фазы коммита, и скрыть эти изменения в выводе. Задел на будущее, а >> старое править - смысл?.. > Ключевое выражение "и скрыть эти изменения в выводе". Это физически невозможно так > как будет новый коммит, соответственно все новые коммиты проходят полностью аудит > сотнями глаз. Скрыть в нем закладку от имени уважаемого разработчика не > получится, даже если коммит в несколько тысяч строк, он ранее проходит > достаточно длительный процесс утверждения и обсуждения, после его принятия все внесенные > изменения сразу будут видны, так как diff с ранее обсуждаемой версией > все покажет. Неубедительно. Так радужно описывается, причем с довольно нехилой такой бюрократией, и на _каждый_-то коммит? Торвальдс меж тем жалуется на раздутость ядра и падение качества кода. Кто даст гарантию, что такой сценарий внесения закладки действительно невозможен, при условии, что и обычные-то дырки находят всё чаще (кто-то их при таком аудите значит проморгал)?..
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	218. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от Аноним (??) on 02-Сен-11, 00:04
	> (кто-то их при таком аудите значит проморгал)?.. Почему-то все дыры имеют такое свойство: их кто-то проморгал :)
	Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

	232. "Kernel.org подвергся взлому"	+/–
	Сообщение от Michael Shigorin (ok) on 02-Сен-11, 09:41
	> Кто даст гарантию, что такой сценарий внесения закладки действительно невозможен Working copy не живёт на сервере.  Там живёт bare repo.  Не чекаутнутый. (можно и не bare, но это именно что добавляет возможностей нечаянно "сделать вторжение" со всеми вытекающими в плане отказа удалённых клиентов pull/push'ить) PS: Вадим, стыдно объяснять Вам _настолько_ элементарные вещи.  Уже ж все нужные ссылки дали, а Вы вроде бы как способный к RTFM специалист.
	Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

	314. "Kernel.org подвергся взлому"	+/–
	Сообщение от nuclight (ok) on 09-Сен-11, 14:53
	>> Кто даст гарантию, что такой сценарий внесения закладки действительно невозможен > Working copy не живёт на сервере.  Там живёт bare repo.   > Не чекаутнутый. (можно и не bare, но это именно что добавляет > возможностей нечаянно "сделать вторжение" со всеми вытекающими в плане отказа удалённых > клиентов pull/push'ить) > PS: Вадим, стыдно объяснять Вам _настолько_ элементарные вещи.  Уже ж все > нужные ссылки дали, а Вы вроде бы как способный к RTFM > специалист. Михаил, опять гордыню включаете, не замечая, что именно с чьей стороны было (guts от меня), а что нет (оргвопросы, где именно working copy) ? Ваше дело, конечно, но можно же было бы и подумать тогда - а зачем последние коммиты таки перепроверяют, если всё реально надежно? Вы дадите гарантию?
	Ответить | Правка | ^ к родителю #232 | Наверх | Cообщить модератору

	322. "Kernel.org подвергся взлому"	+/–
	Сообщение от Michael Shigorin (ok) on 09-Сен-11, 20:47
	>> Working copy не живёт на сервере.  Там живёт bare repo. > Михаил, опять гордыню включаете, не замечая, что именно с чьей стороны было > (guts от меня), а что нет (оргвопросы, где именно working copy)? Извините, если не по адресу.  Но.  Я понял Ваш комментарий #206 так, что "такой сценарий внесения закладки" -- это модификацией некоей working copy на сервере, постулированной Вами в #197.  Если злобные хаксоры изменили Ваши сообщения по дороге до опеннета -- даже не знаю, чем помочь. Ну или выключите трафарет и попытайтесь либо честно сказать, что чушь ляпнули и упорно её защищаете -- либо говорить по существу вопроса, а не "а вот если там вдруг". Документированная (в user-manual.txt) рекомендованная практика -- это именно bare repo _без_ рабочей копии на той стороне, куда выполняют push.  И поскольку проблемы с наличием этой самой копии при push прекрасно известны, а польза от неё на сервере крайне сомнительна (это вам не *BSD, на компилятор рассчитывать не приходится) -- то предположение о её наличии здравым назвать не получается. Но чтоб не сравнивать даже здравость _предположений_, могу попробовать поискать или спросить, как обстояло на самом деле.  Пока что на глаза не попадалось не то что обсуждений, а даже предположений о том, что на kernel.org для разработки использовались бы non-bare repo -- Вы можете не верить, но это именно настолько дико звучит. > а зачем последние коммиты таки перепроверяют, если всё реально надежно? Потому что не идиоты, полагаю.  Доверяй, но проверяй. > Вы дадите гарантию? Нет, конечно.  А если бы и был каким жидом да занимался страхованием рисков, то у Вас бы денег не хватило на такой зуб, думаю.  Как и у меня as is, впрочем. :)
	Ответить | Правка | ^ к родителю #314 | Наверх | Cообщить модератору

	242. "Kernel.org подвергся взлому"	+/–
	Сообщение от anonymous (??) on 02-Сен-11, 12:38
	показательное выступление товарища из стана BSD с номером «демонстрация обычного стиля общения товарища из стана BSD». в программе: безапелляционность, невежественность, хамство, игнорирование указаний на ошибки в рассуждениях, нежелание изучать предмет, о котором идёт речь. в принципе, можно не спешить смотреть, они всегда такие. кто пропустил — увидите в следующий раз.
	Ответить | Правка | ^ к родителю #206 | Наверх | Cообщить модератору

	248. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 02-Сен-11, 13:31
	> показательное выступление товарища из стана BSD с номером «демонстрация обычного > стиля общения товарища из стана BSD». в программе: безапелляционность, невежественность, > хамство, игнорирование указаний на ошибки в рассуждениях, нежелание изучать предмет, о > котором идёт речь. > в принципе, можно не спешить смотреть, они всегда такие. кто пропустил — > увидите в следующий раз. показательное выступление товарища из стана Linux с номером «демонстрация обычного стиля общения товарища из стана Linux». в программе: безапелляционность, невежественность, хамство, игнорирование указаний на ошибки в рассуждениях, нежелание изучать предмет, о котором идёт речь. в принципе, можно не спешить смотреть, они всегда такие. кто пропустил — увидите в следующий раз.
	Ответить | Правка | ^ к родителю #242 | Наверх | Cообщить модератору

	249. "Kernel.org подвергся взлому"	+/–
	Сообщение от anonymous (??) on 02-Сен-11, 13:39
	попытка не то, чтобы плохая — глупая просто. но группа поддержки набигает, ага. и пофигу, что поддерживаемого уже повозили мордочкой в его же бяках.
	Ответить | Правка | ^ к родителю #248 | Наверх | Cообщить модератору

	259. "Kernel.org подвергся взлому"	+/–
	Сообщение от vle (ok) on 02-Сен-11, 17:19
	Каждый Линуксоид радуется как дится, когда у *BSD возникают какие-нибудь проблемы, не важно где и какого характера. Каждый BSD-ик не упустит шанса пнуть Линупсоидов мордой в грязь, когда в их ядре находят 100500-ую дыру в ядре. А смысл?
	Ответить | Правка | ^ к родителю #248 | Наверх | Cообщить модератору

	260. "Kernel.org подвергся взлому"	+/–
	Сообщение от anonymous (??) on 02-Сен-11, 17:21
	> А смысл? это весело, к тому же дисциплина Специальной Олимпиады.
	Ответить | Правка | ^ к родителю #259 | Наверх | Cообщить модератору

	261. "Kernel.org подвергся взлому"	+/–
	Сообщение от vle (ok) on 02-Сен-11, 17:31
	>> А смысл? > это весело, к тому же дисциплина Специальной Олимпиады. Да все и так знают, что русскоязычные в этой олимпийской дисциплине безоговорочные лидеры. Только это тупо, а не смешно.
	Ответить | Правка | ^ к родителю #260 | Наверх | Cообщить модератору

	300. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 05-Сен-11, 16:06
	> Да все и так знают, что русскоязычные в этой олимпийской дисциплине > безоговорочные лидеры. Только это тупо, а не смешно. В остальном мире на BSD как-то так дружно забили уже и олимпиады не получается по техническим причинам. Какая же это олимпиада, если противник не вышел на старт?
	Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

	214. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Сен-11, 23:55
	>> Так репозиторий-то "подправлять" и не требуется. Достаточно пропатчить working copy в начале >> фазы коммита, и скрыть эти изменения в выводе. Задел на будущее, >> старое править - смысл?.. > Ключевое выражение "и скрыть эти изменения в выводе". Это физически невозможно так > как будет новый коммит Не поэтому. Новый коммит как раз палится на раз. Когда речь идёт о подмене исходников, пытаются подправить старый коммит. Но при обновлении с такого репозитория, git там, _куда_ идёт обновление, заорёт.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	315. "Kernel.org подвергся взлому"	+/–
	Сообщение от nuclight (ok) on 09-Сен-11, 15:17
	> Не поэтому. Новый коммит как раз палится на раз. Когда речь идёт > о подмене исходников, пытаются подправить старый коммит. Но при обновлении с > такого репозитория, git там, _куда_ идёт обновление, заорёт. Что ж вас всех так прицепило-то к "подправить старый коммит" ?.. Не единственный способ же. А недооценивать врага (злоумышленников), считая, что таки единственный (или что-нибудь еще считая) - скажем так, в перспективае чревато.
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	324. "Kernel.org подвергся взлому"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Сен-11, 20:22
	>> Не поэтому. Новый коммит как раз палится на раз. Когда речь идёт >> о подмене исходников, пытаются подправить старый коммит. Но при обновлении с >> такого репозитория, git там, _куда_ идёт обновление, заорёт. > Что ж вас всех так прицепило-то к "подправить старый коммит" ?.. Не > единственный способ же. А недооценивать врага (злоумышленников), считая, что таки единственный > (или что-нибудь еще считая) - скажем так, в перспективае чревато. Не единственный. Но подумайте сами, что и зачем можно было подправить: - Код в репозитории, для создания закладки? Как уже сказано выше, не имеет смысла. - Код Git, чтобы отдавал код с закладкой "на лету"? Тоже не имеет смысла, проверки ведь работают на машине разработчика, а не на сервере. Так что максимум, что можно сделать - подменить код для кого-то конкретного, исходя из IP-адреса подключающегося и, возможно, каких-то служебных данных. - Остаётся только мониторинг на самой машине и попытки дальнейшейго проникновения куда-либо. Кража паролей и бог знает что ещё. Может, Bitcoin-добыча. Площадка для DDoS. Всё, что можно ожидать от любой другой взломанной машины. Так ведь?
	Ответить | Правка | ^ к родителю #315 | Наверх | Cообщить модератору

	233. "Kernel.org подвергся взлому"	+/–
	Сообщение от Andrey Mitrofanov on 02-Сен-11, 09:45
	> Так репозиторий-то "подправлять" и не требуется. Достаточно пропатчить working copy в начале > фазы коммита, и скрыть эти изменения в выводе. Фантазёр, чесслово. Какие нафинг воркинг копи на kernel.org?.....
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	286. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 03-Сен-11, 00:22
	> Фантазёр, чесслово. Какие нафинг воркинг копи на kernel.org?..... Этот шутник запалился на том что не понимает как работает git. Обалдеть, линуксные технологии настолько ушли вперед что разработчик бсд не способен понять 1 простую вещь: это РАСПРЕДЕЛЕННАЯ система. В ней все равноправны. У всех есть история коммитов. Сервер - лишь один из, чисто для удобства. А не единственный и неповторимый. Чтобы вбросить в гит левак - надо или синхронно пропатчить базы гита у ВСЕХ участников или синхронно заменить им всем гит на пробэкдореный, что возможно в теории, но совершенно нереально сделать на практике.
	Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

	317. "Kernel.org подвергся взлому"	+/–
	Сообщение от nuclight (ok) on 09-Сен-11, 15:41
	>> Фантазёр, чесслово. Какие нафинг воркинг копи на kernel.org?..... > Этот шутник запалился на том что не понимает как работает git. Обалдеть, > линуксные технологии настолько ушли вперед что разработчик бсд не способен понять > 1 простую вещь: это РАСПРЕДЕЛЕННАЯ система. В ней все равноправны. У > всех есть история коммитов. Сервер - лишь один из, чисто для > удобства. А не единственный и неповторимый. > Чтобы вбросить в гит левак - надо или синхронно пропатчить базы гита > у ВСЕХ участников или синхронно заменить им всем гит на пробэкдореный, > что возможно в теории, но совершенно нереально сделать на практике. Этот аноним запалился на том, что не понимает, как технические решения не могут служить панацеей. Обалдеть, линуксные фанатеги настолько ушли вперед в красноглазости, что не видят, как разработчики бсд тоже используют git и рассказывают уже на шаг вперед, а не назад. Анонимы не способны понять, что безопасность - МНОГОСТОРОННЯЯ штука. В ней все звенья и варианты могут дать слабину. Технический момент - лишь один из, чисто самый заметный. А не единственный и неповторимый. Чтобы сделать линукс неломаемой системой - надо синхронно пропатчить головы ВСЕХ разработчиков, что возможно в теории, но совершенно нереально сделать на практике.
	Ответить | Правка | ^ к родителю #286 | Наверх | Cообщить модератору

	318. "B3DKernel.org "	+/–
	Сообщение от Andrey Mitrofanov on 09-Сен-11, 15:50
	> что не видят, как разработчики бсд тоже используют git [.] > Чтобы сделать линукс неломаемой системой - надо синхронно пропатчить головы ВСЕХ разработчиков, > что возможно в теории, но совершенно нереально сделать на практике. За безопасность б3д мы спокойны! Её разработчики проходят лоботомию в обязательном порядке. :D
	Ответить | Правка | ^ к родителю #317 | Наверх | Cообщить модератору

	320. "B3DKernel.org "	+1 +/–
	Сообщение от vle (ok) on 09-Сен-11, 17:00
	> За безопасность б3д мы спокойны! Её разработчики проходят лоботомию в обязательном порядке. > :D Воздержитесь, Митрофанов, воздержитесь, от обобщений подобного рода. Не пять же тебе годков!
	Ответить | Правка | ^ к родителю #318 | Наверх | Cообщить модератору

	325. "B3DKernel.org "	+/–
	Сообщение от Andrey Mitrofanov on 12-Сен-11, 12:03
	> Воздержитесь, Митрофанов, воздержитесь, от обобщений подобного рода. > Не пять же тебе годков! Слова вашего приятеля, повёрнутые в вашу сторону, говорят о _моей_ невоздержанности? Да, утрировал. Литературный приём, б6бнать. Но про "головы ВСЕХ разработчиков" начал не я. Ах, дааааа, тэги же не расставил. Ввёл в заблуждение неадекватной разметкой? За это извиняюсь. ---Троли из бздешников никакие. Чё ни ляпнут, потом сами же и разобиженные ходят.
	Ответить | Правка | ^ к родителю #320 | Наверх | Cообщить модератору

	326. "B3DKernel.org "	+1 +/–
	Сообщение от vle (ok) on 13-Сен-11, 11:32
	> Слова вашего приятеля, повёрнутые в вашу сторону, > говорят о _моей_ невоздержанности? Он мне не приятель, мы не знакомы. > Но про "головы ВСЕХ разработчиков" начал не я. Тебе обязательно опускаться до его уровня?
	Ответить | Правка | ^ к родителю #325 | Наверх | Cообщить модератору

	323. "Kernel.org подвергся взлому"	+/–
	Сообщение от Michael Shigorin (ok) on 09-Сен-11, 20:52
	> безопасность - МНОГОСТОРОННЯЯ штука. Может, Вы наконец порадуете мир proof of concept'ом вместо безудержного пустого трёпа? > Чтобы сделать линукс неломаемой системой ...и таких вот съездов с инфраструктуры на содержимое. > надо синхронно пропатчить головы ВСЕХ разработчиков Это утверждение тоже неверно, что самое смешное.  Рекомендую пустырник, работает. :)
	Ответить | Правка | ^ к родителю #317 | Наверх | Cообщить модератору

	113. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 14:30
	дядя на сервер заливается уже подписанное
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	117. "Kernel.org подвергся взлому"	+/–
	Сообщение от Вова on 01-Сен-11, 14:41
	я хоть и не фанат гита, но как можно обновиться из репозитария и не заметить этого? В конце концов, даже если предположить, что были молча обновлены какие-то файлы, но ведь при сборке-то этого никак не пропустишь, исключая вариант make >/dev/null/ 2>errors
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	121. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от Andrey Mitrofanov on 01-Сен-11, 14:52
	> я хоть и не фанат гита, но как можно обновиться из репозитария и не заметить этого? Более того, даже при push-е в изменённый реп. это _очень заметно. http://git-blame.blogspot.com/2011/08/how-to-inject-maliciou... +++ Id головы является хешем _всей _истории. Студентам смотреть видео с Торвальдсом на Гугле Коде (первое, не второе -- во втором про ветки-мержи, маленьким рано ещё).
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	139. "Kernel.org подвергся взлому"	+/–
	Сообщение от Michael Shigorin (ok) on 01-Сен-11, 16:59
	> Какая наивная уверенность *sigh* Сейчас: http://lwn.net/Articles/417856/ На досуге: http://los-t.livejournal.com/tag/git%20guts (особенно part 7) Не спешите опростоволоситься.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	181. "Kernel.org подвергся взлому"	+/–
	Сообщение от nuclight (ok) on 01-Сен-11, 22:18
	>> Какая наивная уверенность > *sigh* > Сейчас: http://lwn.net/Articles/417856/ > На досуге: http://los-t.livejournal.com/tag/git%20guts (особенно part 7) > Не спешите опростоволоситься. Михаил, ну уж Вы-то могли бы не уподобляться красноглазым крикунам и понять, что имелось в виду. Неужели Вы думаете, я не знаком с git guts (а равно и с форматами и hg, и svn)? Суть очень проста: предположим, что злонамеренный разработчик вливает свой троянский патч в дерево вместе с очередным коммитом чего-то еще. Кто его заметит? Никто, механизм ведь совершенно штатный, что git'у в working directory положили, то он и коммитит. Это вовсе не изменение репозитория со старой историей, а добавление во время обычной работы. Такое никаким механизмом обойти в принципе нельзя. Ну и теперь, допустим, взломщик пропатчил git ничего не подозревающему разработчику, чтобы такая модификация проводилась "на лету" перед обычным коммитом, и скрыл вывод дополнительных измененных файлов от этого разработчика. Куда проще, чем пытаться править хэши.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	183. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от anonymous (??) on 01-Сен-11, 22:21
	> Ну и теперь, допустим, взломщик пропатчил git ничего не подозревающему разработчику …а теперь предположим, что высадился недружественный десант марсиан…
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	235. "Kernel.org подвергся взлому"	+/–
	Сообщение от Andrey Mitrofanov on 02-Сен-11, 09:49
	>> Ну и теперь, допустим, взломщик пропатчил git ничего не подозревающему разработчику > …а теперь предположим, что высадился недружественный десант марсиан… +1 А ещё говорят Конецц Света на носу и вообще Солнце взорвётся!!! Как старшно жить, девочки-и-и-и!!?
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	198. "Kernel.org подвергся взлому"	+2 +/–
	Сообщение от Аноним (??) on 01-Сен-11, 23:20
	> Ну и теперь, допустим, взломщик пропатчил git ничего не подозревающему разработчику, чтобы Здесь есть одно НО. Чтобы это сработало, git-должен быть пропатчен у всех разработчиков. Кстати, это идея ! Аудит кода Git проводится не так интенсивно, как аудит кода ядра. Внедрить туда троянский код куда проще. А потом уже можно скрыто провести троян для ядра.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	200. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 01-Сен-11, 23:24
	Кстати, это открывает интересные горизонты. Достаточно при определенных обстоятельствах поменять логику проверок по SHA или хэш считать не над всеми данными. А затем под видом какого-нибудь обновления бинарного firmware продвинуть троян.
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	203. "Kernel.org подвергся взлому"	+/–
	Сообщение от nuclight (ok) on 01-Сен-11, 23:29
	>> Ну и теперь, допустим, взломщик пропатчил git ничего не подозревающему разработчику, чтобы > Здесь есть одно НО. Чтобы это сработало, git-должен быть пропатчен у всех > разработчиков. Кстати, это идея ! Аудит кода Git проводится не так > интенсивно, как аудит кода ядра. Внедрить туда троянский код куда проще. > А потом уже можно скрыто провести троян для ядра. Зачем у всех? Остальным достаточно доверять нашему разработчику и не заметить некоторые мелочи. Тут социальные факторы работают больше технических. Хотя идея внедрить код в git для таких сокрытий тоже неплоха.
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	216. "Kernel.org подвергся взлому"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 02-Сен-11, 00:02
	>>> Ну и теперь, допустим, взломщик пропатчил git ничего не подозревающему разработчику, чтобы >> Здесь есть одно НО. Чтобы это сработало, git-должен быть пропатчен у всех >> разработчиков. Кстати, это идея ! Аудит кода Git проводится не так >> интенсивно, как аудит кода ядра. Внедрить туда троянский код куда проще. >> А потом уже можно скрыто провести троян для ядра. > Зачем у всех? Остальным достаточно доверять нашему разработчику и не заметить некоторые > мелочи. Нет. Не забывайте, это DVCS. Разработчик работает с _собственным_ репозиторием, из которого накатывает обновления на данный. Поэтому, если только git не «подправлен» и на машине у разработчика, и на сервере с центральным репозиторием, то будет наличествовать различие в коммитах между личным репозиторием разработчика и центральным. Что будет выявлено при следующем коммите или обновлении этого же разработчика. (а если взломан центральный сервер, но он подправляет на лету коммиты при сливании с него обновлении, то как бы и вреда он не принесёт, раз отдаёт чистые файлы... Разве что прямо из репозитория будет собираться конечный проект, без checkout'а, но это уже клиника, ИМХО) > Тут социальные факторы работают больше технических. Хотя идея внедрить код > в git для таких сокрытий тоже неплоха. Угу, или в любую другую VCS. Это будет, возможно, пострашнее, чем внедрение паразита в код SSH...
	Ответить | Правка | ^ к родителю #203 | Наверх | Cообщить модератору

	219. "Kernel.org подвергся взлому"	+/–
	Сообщение от myself on 02-Сен-11, 00:25
	На самом деле, такую фиговину прокрутить (т.е. внедриться на уровне исходников, перехватив момент коммита) можно запросто, вопрос в том, что это достаточно нетривиально на уровне модификации самих исходников -- т.е. это контекстно-зависимая модификация, сама по себе достаточно сложная. Более того, такую вставку надо делать очень аккуратно, ибо запалят. Но теоретически... конечно можно.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	221. "Kernel.org подвергся взлому"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 02-Сен-11, 00:32
	> На самом деле, такую фиговину прокрутить (т.е. внедриться на уровне исходников, перехватив > момент коммита) можно запросто, вопрос в том, что это достаточно нетривиально > на уровне модификации самих исходников -- т.е. это контекстно-зависимая модификация, сама > по себе достаточно сложная. Если только не воспользоваться наработками какого-нибудь coccinelle :) > Более того, такую вставку надо делать очень аккуратно, ибо запалят. Во многих языках достаточно сделать после разделителя операций (точка с запятой, или что там ещё) много-много пробелов, и дальше писать что угодно. Главное, чтобы код использовался часто, а менялся редко. > Но теоретически... конечно можно.
	Ответить | Правка | ^ к родителю #219 | Наверх | Cообщить модератору

	224. "Kernel.org подвергся взлому"	+/–
	Сообщение от myself on 02-Сен-11, 00:58
	Тут надо хитр0 работать, такие хреновины типа точки с запятой ловятся на раз-два и привет (можешь прогнать тест самолично, благо git grep -E позволяет).
	Ответить | Правка | ^ к родителю #221 | Наверх | Cообщить модератору

	225. "Kernel.org подвергся взлому"	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 02-Сен-11, 01:02
	> Тут надо хитр0 работать, такие хреновины типа точки с запятой ловятся на > раз-два и привет (можешь прогнать тест самолично, благо git grep -E > позволяет). Так я и говорю: если код (плюс-минус три строчки) не меняется, то в патчах он светиться не будет. С отладчиком сложнее, но опять таки — если этот кусок кода не правится, значит, он уже отлажен, и трассировать его вряд ли кто-то будет. Вот в Whitespace (да и Brainfuck с компанией) таки да, закладки выявить будет проблематично. :)
	Ответить | Правка | ^ к родителю #224 | Наверх | Cообщить модератору

	227. "Kernel.org подвергся взлому"	+/–
	Сообщение от myself on 02-Сен-11, 01:12
	Угу. Правда поскольку взлом относительно недавно произошел (будем считать априори), то проревьювить патчи просто (их немного было). А вот если руткит там давно сидит, то это может быть пипец, потому как отследить модификации -- достаточно трудоемкая процедура. Я, впрочем, сомневаюсь что там все настолько сурово.
	Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

	234. "Kernel.org подвергся взлому"	+/–
	Сообщение от Michael Shigorin (ok) on 02-Сен-11, 09:47
	> Неужели Вы думаете, я не знаком с git guts (а равно и с форматами и hg, и svn)? Читая, надеялся, что незнакомы. Как бы это попроще объяснить... Попробуйте подменить меня, на котором отложились все предыдущие поколения, подконтрольным двойником -- так, чтобы среди множества знакомых со мной людей ни один этого не заметил. PS: технически говоря: > что git'у в working directory положили, то он и коммитит Предлагаю при установленном гите выполнить следующие действия: mkdir git-test cd git-test git init echo "123" > file; git status git commit -am "initial state"; git status echo "456" >> file; git status git add file; git status echo "789" >> file; git status После чего наконец понять, что есть три состояния изменения существующего с точки зрения  git файла -- "сделано в рабочей копии" (unstaged), "добавлено в будущий коммит" (staged) и "закоммичено".  Да, можно продолжать рассусоливать о том, как бы врезаться между git status и git add/commit -a, но это в принципе race даже при возможности снупать ssh-сессии. И это всё -- в ответ на предположение, что кто-то что-то правит "прям на сервере" в репо с чекаутнутой рабочей копией, что само по себе звучит немножко дико для git repo, в который пушат.  А при нормальном рабочем воркфлове подделывать придётся pack'и со всеми вытекающими.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	316. "Kernel.org подвергся взлому"	+/–
	Сообщение от nuclight (ok) on 09-Сен-11, 15:26
	>[оверквотинг удален] > cd git-test > git init > echo "123" > file; git status > git commit -am "initial state"; git status > echo "456" >> file; git status > git add file; git status > echo "789" >> file; git status > После чего наконец понять, что есть три состояния изменения существующего с точки > зрения  git файла -- "сделано в рабочей копии" (unstaged), "добавлено > в будущий коммит" (staged) и "закоммичено".   Я это даже комментировать не буду. Просто запишу в образчик гордыни, номер очередной. Рассказывать с надменным видом собесденику то, что он давно знает, при этом не прислушиваясь, что же он, собственно, имел в виду, уже пойдя дальше. > Да, можно продолжать рассусоливать > о том, как бы врезаться между git status и git add/commit > -a, но это в принципе race даже при возможности снупать ssh-сессии. Hint: это предположение основано на том, что используется stock git, без закладок > И это всё -- в ответ на предположение, что кто-то что-то правит > "прям на сервере" в репо с чекаутнутой рабочей копией, что само > по себе звучит немножко дико для git repo, в который пушат. Зависит от организации рабочего процесса там на месте. Для одного "git repo, в который пушат" хватило бы и одного мастер-сервера (плюс еще несколько из-за высокой нагрузки). А там сотни, с разными аккаунтами на разных серверах. Что наводит на мысли (при неизвестности, как там именно обстоят дела), что всё не так тривиально, возможны варианты. >  А при нормальном рабочем воркфлове подделывать придётся pack'и со всеми > вытекающими. Опять же. Вы так уверены, что это единственно возможный вариант? Ну не буду мешать, жизнь со временем научит.
	Ответить | Правка | ^ к родителю #234 | Наверх | Cообщить модератору

	321. "Kernel.org подвергся взлому"	+/–
	Сообщение от Michael Shigorin (ok) on 09-Сен-11, 20:23
	>> После чего наконец понять, что есть три состояния > Я это даже комментировать не буду. Да сделайте уж скидку на скудоумие, прокомментируйте по существу, а не лирикой.  Из более ранней лирики совершенно неочевидно, что конкретно Вы имели в виду. >> Да, можно продолжать рассусоливать [...] > Hint: это предположение основано на том, что используется stock git, без закладок Hint: _где_? >> И это всё -- в ответ на предположение, что кто-то что-то правит >> "прям на сервере" в репо с чекаутнутой рабочей копией, что само >> по себе звучит немножко дико для git repo, в который пушат. > Зависит от организации рабочего процесса там на месте. Да, причём ровно в обратную сторону от той, на которую Вы пытаетесь вытянуть свою никчемную аргументацию: пока у меня один репо и полтора разработчика, можно и подрожать над ним, синхронизируясь.  А когда их сотни на сотни -- уже в голову не влезет.  Сюрприз?  Или, может, я с такими случаями просто на практике знаком не первый год? :) >> рабочем воркфлове подделывать придётся pack'и со всеми вытекающими. > Опять же. Вы так уверены, что это единственно возможный вариант? Нет, конечно.  Это было бы самонадеянным. > Ну не буду мешать, жизнь со временем научит. Почитайте, что ли, http://git-blame.blogspot.com/2011/08/how-to-inject-maliciou... и более обще http://lwn.net/Articles/457142/ -- вдруг удастся таким образом помочь Вашей жизни в её нелёгком деле.
	Ответить | Правка | ^ к родителю #316 | Наверх | Cообщить модератору

	285. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 03-Сен-11, 00:16
	> Какая наивная уверенность, что Git обеспечивает защиту. Совершенно никто не мешал злоумышленникам > модифицировать Git так, чтобы левый патч внедрился в коммит незаметно Угу. Осталось всего-то синхронно его заменить всем юзерам, чтобы они не заметили подвоха. Как вы себе это представляете на практике?
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

175. "Kernel.org подвергся взлому"	–3 +/–
Сообщение от Ктожеев on 01-Сен-11, 19:20
просто почаще надо бекапы делать... зачем переустанавливать? сделал вовремя снимок файловой системы и спи спокойно... Но я все равно уверен что это диверсия ФСБ...!!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	196. "Kernel.org подвергся взлому"	+3 +/–
	Сообщение от evgeny_t (ok) on 01-Сен-11, 23:16
	почему не фбр ?
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	199. "Kernel.org подвергся взлому"	+2 +/–
	Сообщение от bircoph (ok) on 01-Сен-11, 23:23
	скорее АНБ
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	212. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok) on 01-Сен-11, 23:50
	> почему не фбр ? ФБР — контрразведка. Внешней разведкой занимается ЦРУ, ну и военные. Плюс АНБ обеспечивает техническую поддержку.
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

226. "Kernel.org подвергся взлому"	+3 +/–
Сообщение от Аноним (??) on 02-Сен-11, 01:02
Я наверное из вымиряющих видов. Если б мне упали рут доступы серверов kernel.org я бы нацарапал письмо админам этих серверов..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	230. "Kernel.org подвергся взлому"	+2 +/–
	Сообщение от тигар (ok) on 02-Сен-11, 08:17
	>  Я наверное из вымиряющих видов. Если б мне упали рут доступы > серверов kernel.org я бы нацарапал письмо админам этих серверов.. а не проще ли в motd и wall написать p0wnd by anonymous_from_opennet.ru?;)
	Ответить | Правка | ^ к родителю #226 | Наверх | Cообщить модератору

236. "Kernel.org подвергся взлому"	+/–
Сообщение от vitlva on 02-Сен-11, 10:12
при этом как минимум 17 дней злоумышленники оставались незамеченными. ---- А скриптик на проверку контрольных сумм для системных файлов было конечно слабо написать.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

247. "Kernel.org подвергся взлому"	+/–
Сообщение от z (??) on 02-Сен-11, 13:18
>А скриптик на проверку контрольных сумм для системных файлов было конечно слабо написать. т.е. пытаться перехитрить руткит из юзерспейса? продолжайте =)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	273. "Kernel.org подвергся взлому"	+/–
	Сообщение от Клыкастый (ok) on 02-Сен-11, 19:55
	> т.е. пытаться перехитрить руткит из юзерспейса? продолжайте =) вы взываете к разуму. в данном случае - это наивность ;)
	Ответить | Правка | ^ к родителю #247 | Наверх | Cообщить модератору

294. "Kernel.org подвергся взлому"	+/–
Сообщение от Аноним (??) on 04-Сен-11, 09:08
Много странного в этой истории. Слишком явны и нескрыты некоторые вещи. Такое ощущение, что rootkit, ssh-бэкдор и ругань про xnest в логе лишь отвлекающий маневр, чтобы сбить администраторов с толку и вселить уверенность в контроле за ситуацией. Хотя не исключено, что это сделано преднамеренно, чтобы могли  вычислить примерную дату атаки и не углубляться в более ранний период. Атак могло быть две - одна скрытая и осторожная, а вторая, через несколько месяцев после того как все задачи атакующих выполнены, заметная и путающая следы.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

295. "Kernel.org подвергся взлому"	+/–
Сообщение от colibrys (ok) on 04-Сен-11, 16:16
Развлекаются ребята)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

296. "Kernel.org подвергся взлому"	+/–
Сообщение от uldus (ok) on 04-Сен-11, 22:15
Бьюсь об заклад, пароль утянули во время LinuxCon в середине августа. По времени очень хорошо совпадает с датой взлома. На пару недель раньше на Black Hat очень весело демонстративно сниффили пароли и ломали ноутбуки участников этой конференции. Халявный Wifi на конференциях - зло.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	301. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 05-Сен-11, 16:11
	> Халявный Wifi на конференциях - зло. Он просто должен использоваться с включением мозга. Вы выстреливаете данные в эфир, это следует понимать.
	Ответить | Правка | ^ к родителю #296 | Наверх | Cообщить модератору

	302. "Kernel.org подвергся взлому"	+/–
	Сообщение от uldus (ok) on 05-Сен-11, 17:46
	>> Халявный Wifi на конференциях - зло. > Он просто должен использоваться с включением мозга. Вы выстреливаете данные в эфир, > это следует понимать. От ошибки никто не застрахован, а суета конференции очень сильно способствует таким ошибкам. А тем кто сниффит достаточно одно оплошности. Проверил почту без шифрования, скопировал по FTP, залез в свой аккаунт без HTTPS и все, под колпаком. Хоть один из нескольких сотен разработчиков да споткнётся.
	Ответить | Правка | ^ к родителю #301 | Наверх | Cообщить модератору

	303. "Kernel.org подвергся взлому"	+1 +/–
	Сообщение от anonymous (??) on 05-Сен-11, 18:08
	поэтому надо готовиться заранее. пароли не вводить. браузер нулёвый без кукишей. если надо что-то и куда-то — ssh до «домашнего» сервера, оттуда уже совершать все действия. и пусть снифят до посинения. взрослые, вроде бы, люди, а как дети: лишь бы сунуть, о предозранении думать нет желания.
	Ответить | Правка | ^ к родителю #302 | Наверх | Cообщить модератору

	309. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 07-Сен-11, 20:09
	> От ошибки никто не застрахован, а суета конференции очень сильно способствует таким > ошибкам. Единственной ошибкой тут является туго работающий мозг. Если вы стреляете чувствительные данные в эфир, при том что сеть открытая и не шифрует данные, а вокруг толпа продвинутого народа сидит - вы сами себе злой буратино. Подсказываю: чуть проще будет встать на трибуну и проорать логин и пароль оттуда, так уж точно все заметят и запишут. > А тем кто сниффит достаточно одно оплошности. Проверил почту без > шифрования, скопировал по FTP, залез в свой аккаунт без HTTPS и > все, под колпаком. Хоть один из нескольких сотен разработчиков да споткнётся. Разработчики - не первоклассники. Поэтому им скидок на тупость и отсутствие опыта не полагается. Как пример кардинального решения проблемы: ставится сервак с openvpn в более-менее доверяемой локации где нет парней с снифферами, на нем настраиваем нат. На свои девайсы ставится openvpn клиент. Давим на них фаером весь трафф через открытые каналы кроме единственного адреса - сервака openvpn. Остальное - только через него. Хаксоры выкусывают по полной, да и у вас облажаться не получится особо. Это может работать практически на автомате а вы всегда будете выстреливать пароли по ssl туннелю до своего хоста, независимо от природы доступа в интернет.
	Ответить | Правка | ^ к родителю #302 | Наверх | Cообщить модератору

	312. "Kernel.org подвергся взлому"	+/–
	Сообщение от Ы on 08-Сен-11, 10:38
	Чего только народ не наплетет лишь бы не признавать, что в Linux есть дыры. :-)
	Ответить | Правка | ^ к родителю #302 | Наверх | Cообщить модератору

305. "Kernel.org подвергся взлому"	+/–
Сообщение от Alan (??) on 07-Сен-11, 00:44
>Атакующим удалось получить root-доступ к серверам, модифицировать системное >программное обеспечение и организовать перехват паролей разработчиков. Тем не >менее, пока не ясно как именно удалось поднять свои привилегии в системе, судя >по всему был задействован эксплоит для еще публично неизвестной уязвимости. По скорее бы узнать, что это за хитрую и непубличную уязвимость в системе нашли злоумышленники, что-бы поднять права доступа. Вот это заслуживает любых аплодисментов.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	307. "Kernel.org подвергся взлому"	+/–
	Сообщение от Andrey Mitrofanov on 07-Сен-11, 09:47
	#255 выше: | На kernel.org написано | | >>>> how they managed to exploit that to root access is currently unknown and is being investigated. | | За фантазии про "публично неизвестной уязвимости" скажите отдельное спасибо автору текста новости и больше не повтооряйте ерунду. | | Разницу-то осилите?
	Ответить | Правка | ^ к родителю #305 | Наверх | Cообщить модератору

	310. "Kernel.org подвергся взлому"	+/–
	Сообщение от Аноним (??) on 07-Сен-11, 20:56
	> | За фантазии про "публично неизвестной уязвимости" скажите отдельное спасибо автору > текста новости и больше не повтооряйте ерунду. > | > | Разницу-то осилите? На kernel.org недоговаривают. В рассылках был разбор, что удалось перехватить сессию взлома и воссоздать эксплоит, который работает для последнего релиза ядра.
	Ответить | Правка | ^ к родителю #307 | Наверх | Cообщить модератору

	313. "Kernel.org подвергся взлому"	+/–
	Сообщение от Andrey Mitrofanov on 08-Сен-11, 11:48
	>> | Разницу-то осилите? > На kernel.org недоговаривают. Допускаю. Но скорее просто молчат, пока расследование не закончено, до опубликования полного отчёта. > В рассылках был разбор, что удалось перехватить сессию взлома > и воссоздать эксплоит, который работает для последнего релиза ядра. Не верю.** Подробнее? Пруф? Линк?? ** =что опубликовали и это ещё не на всех новостных сайтах, и что опубликовали до окончания расследования.
	Ответить | Правка | ^ к родителю #310 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема