Ну альт-линуксом, например, пользуются.

altlinux.ru - не вижу ни новостей об обновлениях безопасности, ни ссылки на мейллисты где как-то отслеживаются подобные проблемы.

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

спасибо, явный плюс альтовцам за оперативность

wan admin

админка в wan вообще не должна быть открыта

кто тебе сказал такую глупость?

зачем?

Такие уязвимости всегда используются до публикации. 0day жесток и беспощаден. http://www.exploit-db.com/papers/18074/

автор эксплоита пишет что для gentoo и прочих систем где нету прав на чтение /bin/su можно воспользоваться ptrace

proof тут: http://git.zx2c4.com/CVE-2012-0056/tree/ptrace-offset-finder.c и тут: http://blog.zx2c4.com/749 - Update3

ptrace

значит он допилил таки, класс

не вижу ни новостей об обновлениях безопасности

http://sisyphus.ru/en/security/

ни ссылки на мейллисты где как-то отслеживаются подобные проблемы.

ты тоже сделал echo 127.0.0.1 google.com >>/etc/hosts ?

PS альтом не пользуюсь и видел его пару раз в жизни

http://sisyphus.ru/en/security/

Ага, они у rhel скопипастили дырку.

ты тоже сделал echo 127.0.0.1 google.com >>/etc/hosts ?

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

Сравни: http://www.debian.org/

На gentoo hardened в исходном виде не воспроизводится. su запрещён для чтения и выполнения юзерами. Однако objdump юзерам был доступен, т.ч. на всякий случай выставил ему 700ку, хотя это тоже не панацея - захотят - протащат свой и найдут таки смещение.

автор эксплойта выложил утилиту http://git.zx2c4.com/CVE-2012-0056/tree/ptrace-offset-finder.c

Update 3: Gentoo is smart enough to remove read permissions on SUID binaries, making it impossible to find the exit@plt offset using objdump. I determined another way to do this, using ptrace. Ptrace allows debugging of any program in memory. For SUID programs, ptracing will drop its privileges, but that’s fine, since we simply want to find internal memory locations. By parsing the opcode of the binary at the right time, we can decipher the target address of the next call after the printing of the error message. I’ve created a standalone utility that returns the offset, as well as integrating it into the main mempodipper source.

Хех. Ну тогда только отрубать оба сервера от сети и ждать патчей получается :)

Птаху тут уже забыли или те, кто его помнил, уже ушли с ресурса. :) Возвращаться он не будет, потому что некоторые условия этого никогда не будут выполнены.

Птаху тут уже забыли или те, кто его помнил, уже ушли с ресурса. :)

Ну как минимум я ещё помню. :)

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

Я помню, что была какая-то teh drama, но сути уже вспомнить не могу. О каких условиях речь?

Так может через другую уязвимость залезть могли? Почему бы в роутерах не быть удалённым уязвимостям? :)

карму он хотел и еще какой то бред

и постоянно пишет, что от своего ника больше писать не будет, тем не менее постоянно что-то постит

потому что ботнет был с открытых админок, а раздули до мифических уязвимостей

Сравни: http://www.debian.org/

единственное что мне нужно это чтобы на почту падали уведомления о проблемах с безопасностью и только для тех пакетов которые у меня установлены (например, при помощи debsecan какого-нить). Ходить на debian.org и смотреть что там закрыли а потом смотреть что из этого для меня актуально я не буду, это неоптимальный алгоритм.

wan

что зачем? или у тебя 1 рецепт на все случаи жизни? или ты как на железке полагаешь что лучший FW - ето 15 см воздуха?;)

noptrace

можно воспользоваться ptrace

а если нельзя? если кто забыл, то есть такая штука:
https://gist.github.com/1216637
Kernel module to disable the ptrace() system call
до этого был и другой модуль
нафик вообще ptrace нужен на рабочем серваке?

lcap

и опять же - man lcap -> lcap CAP_SYS_PTRACE

потому что ботнет был с открытых админок, а раздули до мифических уязвимостей
Да ладно?! «Your username and password combinations are weak, OR the daemons that your firmware uses are exploitable.»

примеры будут? это надутая теория

Поддержка PSYB0T 2.9L роутеров на базе OpenWRT и DD-WRT тоже теория?

Gentoo Hardened, hardened-sources 3.1.6-hardened, amd64. mempodipper.c не работает. Без -o вообще зависает (на «Ptracing su to find next instruction without reading binary.»), пока не жмякнешь ^C, а если ему дать смещение, отрабатывает, но рутового шелла всё равно не даёт.

Дал ему даже права на чтение /bin/su - всё равно првисает, сука.

поддержка позволяет ему запуститься на них, так что там про

OR the daemons that your firmware uses are exploitable.

? так и не будет примеров?

из вики

The primary attack vector is SSH or telnet access. Using brute-forcing, it tries to gain access from over 6000 usernames and 13000 passwords.

primary attack vector
Уже из этого вы должны были сделать вывод о том, что он не единственный. Какие примеры вам ещё нужны?

Установка sysctl kernel.randomize_va_space=0 тоже не помогает. Что делать?

Упс, таки сработало, получился root. Без параметра -o, через ptrace. С параметром не работает.

я же писал, что это в теории
а на практике нет ничего

На практике ваш роутер не ломали, поэтому этого ботнета не существует. Довольны?

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

Как-то до сих пор на Слаке ни один из этих «эксплойтов» не сработал.

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

Ну погуглите вы, если так неймётся. Например у WAP54Gv3 открыт доступ к страницам Debug_command_page.asp и debug.cgi по логину и паролю Gemtek/gemtekswd вне зависимости от того, какой пароль указали вы. Или вот весёлая дыра в D-Link. И так далее, и тому подобное.

Помогите с канпеляцией ведра. make oldconfig мне сходу выдал:

  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --oldconfig Kconfig
*
* Restart config...
*
*
* Group CPU scheduler
*
Group CPU scheduler (CGROUP_SCHED) [Y/?] y
  Group scheduling for SCHED_OTHER (FAIR_GROUP_SCHED) [Y] y
    CPU bandwidth provisioning for FAIR_GROUP_SCHED (CFS_BANDWIDTH) [N/y/?] (NEW)

Читаю что это на Опеннете:

Система гибкого распределения ресурсов CPU (Process bandwith controller). В планировщик задач CFS добавлена возможность ограничения времени потребления CPU для группы процессов, например, если система не нагружена, подобная возможность позволит выделить больше ресурсов процессам, которые в иной ситуации были бы ограничены более жёстко. Разделяя текущие ресурсы CPU (процессорное время) между всеми процессами, планировщик задач ранее не имел механизмов адресного распределения свободных ресурсов CPU, так как все процессы потенциально заинтересованы получить как можно больше времени CPU.

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

Раз это полезная опция, то почему она по-умолчанию «N»?

ну а где их принадлежность к Psyb0t? =)

ну и какой идиот админку в wan открывает?

А поздно :)

Нам и руками пропатчить не проблема в отличие от...
Ну и сегодня прилетело:

23 Jan 2012; Michael Pagano <mpagano@gentoo.org>
+gentoo-sources-3.1.10.ebuild, +gentoo-sources-3.2.1-r1.ebuild:
Clean up and fix /proc/<pid>/mem handling, prevent local privilege escalation

Как-то до сих пор на Слаке ни один из этих «эксплойтов» не сработал. А «вирусы-трояны» зачастую даже не компилируются, не то что не работают...

При чем тут слака? Если експлойт не работает на слаке значит его нет? Странный подход. Уязвимость ядра затрагивающая абсолютное большинство пользователей линукс. Да, не удаленная, иначе вообще был бы эпик фейл, а так просто локальный фейл :))). Надо смотреть правде в глаза, а не пытаться что-то оправдать. В убунте кстати уже исправили, обрывается на «Executing su with shellcode».

Я тоже уже не помню, кажется, он модератором хотел стать.

Я не знаком с теми, кто использует пиратский windows. Сейчас это не 10 лет назад.

Да ты похоже вообще ни с кем ни знаком

И самое смешное что у меня в генту без sudo не получить
смещение потому что у su нету влага чтения, только исполнение.

Его не нужно «получать». Его можно элементарно подобрать на системе без ASLR. Всего делов перебрать несколько тысяч ардесов начиная с 0x400000.

ну а где их принадлежность к Psyb0t? =)
Ну, извините, за неимением сорцев проверить принадлежность не могу. Однако, что-то мне подсказывает, что поддержках таких общеизвестных дыр наверняка была реализована.
> ну и какой идиот админку в wan открывает?
Для заражения роутера не обязательно открывать её в WAN. Это может сделать дроппер из локальной сети, с ШINDOШS-PC.

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

ок, ну ты не в теме просто

p.s. с ВЫканьем - на хабру

Да, не удаленная, иначе вообще был бы эпик фейл, а так просто локальный фейл :)))

как ты представляешь remote root exploit в ядре?:)

ок, ну ты не в теме просто
Это похоже вы не в теме - даже не предположили вариант использования дропперов.

единственное что мне нужно это чтобы на почту падали уведомления о проблемах с безопасностью

Телепатически что-ли адрес вашей почты рассылки узнали?

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

Ходить на debian.org и смотреть что там закрыли а потом смотреть

Это вам никто и не предлагает. Но то, что такая информация доступна на сайте дистрибутива, а не запихнута бог весть куда - элементарный критерий для отсева всякой муры.

Телепатически что-ли адрес вашей почты рассылки узнали?

я не про рассылки. Я же сказал что получать все уведомления просто не интересно.

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

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

Я же сказал что получать все уведомления просто не интересно.

Поверьте, проще читать debian-security*@ полностью, чем получать/фильтровать/мержить уведомления от сотен серверов с разным ПО.

Кстати, посмотрев на debsecan - вижу что она для stable не работает (без разницы какой --suite указать). Показывает информацию из баз тестинга, а не с http://security-tracker.debian.org/tracker/status/release/stable

Т.е. она бесполезна, если вы, конечно, не тестинг используете.