но ведь… питух_ос - неуязвима… а дырки в ней латают быстрее возникновения поноса от поедания килограмма протухшей черешни…
>>1006957
Тут больше анонов увидит.
Тут больше анонов увидит.
У нас админ прыщеблядь-анимешник, щас забанит.
>>1006936
Да это ж год линуксоида
Да это ж год линуксоида
Это опасная хуйня?
А я давно уже об этом говорил, но пердосектанты мне всё равно не верят.
После недавнего отсоса с WannaCry спермоклоунам лучше вообще не отсвечивать.
>>1008848
Алсо, больше всего заразилось компьютеров под управлением Windows 7, а XP падала в BSOD и тем самым спасалась от заражения.
Алсо, больше всего заразилось компьютеров под управлением Windows 7, а XP падала в BSOD и тем самым спасалась от заражения.
почему я не заразился если даж сбер с его мегоадминоме с з/п 10000000 в месяц позаражало?
>>1008964
Вероятно у тебя роутер с NAT, который прячет твои открытые порты.
Вероятно у тебя роутер с NAT, который прячет твои открытые порты.
ничего у меня не роутер. всё открыто для всех.
дисятка сама всё ставит жи. вообще ниразу не ловил никаких вирусов. хз откуда все эти люди заражаются. я хз где надо лазить чтобы ловить всё это говно.
>>1009054
Просто вирусы видят на какой убогой оси ты сидишь и не хотят шквариться об нее.
Просто вирусы видят на какой убогой оси ты сидишь и не хотят шквариться об нее.
>>1008964
>почему я не заразился
Потому что не используешь древнее говно мамонта smb 1, и/или накатываешь вовремя обновления.
>если даж сбер с его мегоадминоме
Мегоадминоме на работе бывает два часа в неделю, и нихуя не делает, потому что друзяшка руководства. Вся работа на низовых, которые пашут за 25к в месяц, дрочат на пингвинов и путают вилан с вилами.
И вообще, тхрэад про питухов, а не про вендоблядей (которые не сосут).
>почему я не заразился
Потому что не используешь древнее говно мамонта smb 1, и/или накатываешь вовремя обновления.
>если даж сбер с его мегоадминоме
Мегоадминоме на работе бывает два часа в неделю, и нихуя не делает, потому что друзяшка руководства. Вся работа на низовых, которые пашут за 25к в месяц, дрочат на пингвинов и путают вилан с вилами.
И вообще, тхрэад про питухов, а не про вендоблядей (которые не сосут).
>>1009110
>(которые не сосут)
"Роснефть" сообщила об атаке на свои серверы
https://twitter.com/interfax_news/status/879676972200230912
Масштабная вирусная #атака на Украину: Новая почта, ДТЭК, Укртелеком, Эпицентр, УЗ и другие компании-жертвы
https://twitter.com/news112ua/status/879675495587164161
И двух месяцев не прошло, как насосались по-новому.
>(которые не сосут)
"Роснефть" сообщила об атаке на свои серверы
https://twitter.com/interfax_news/status/879676972200230912
Масштабная вирусная #атака на Украину: Новая почта, ДТЭК, Укртелеком, Эпицентр, УЗ и другие компании-жертвы
https://twitter.com/news112ua/status/879675495587164161
И двух месяцев не прошло, как насосались по-новому.
В чём дело:
В 2005 году Gaël Delalleau показывает наличие уязвимости в управлении памятью в linux 2.6 и ряде других unix-based ОС (FreeBSD, OpenBSD – не удаётся эксплуатировать разве что в Solaris 9/10). Дело в отсутствии защиты от stack gap – которая [защита] присутствует в Windows NT уже давно, поэтому такой трюк не проходит даже на Windows XP SP1, вызывая 0xC0000005.
В качестве временного костыля предлагается всё, собранное с gcc, пересобирать с -fstack-check, что с возмущением воспринимается “опенсорсной общественностью”, ведь “всё ж тормозить будет, и целый нулевой байт на каждую страницу в 4К тратится”.
Несмотря на работоспособные PoC, все забивают и проблема тянется до августа 2010 года, когда Rafal Wojtczuk обнаруживает очередной способ эксплуатации данной уязвимости.
У Microsoft в это время уже есть не только защита от таких атак, но целая гибкая система управления для предотвращения подобных классов атак – доступный бесплатно EMET.
Становится понятно, что с уязвимостью надо что-то делать, потому что уязвимы все системы на базе linux и атакующий может не вызывая segmentation fault записывать в чужие регионы памяти произвольные данные.
Выпускается заплатка и ситуация на время затихает. Ну, что такого – 6 лет можно было ломать линукс-системы – это ещё не рекорд по забиванию на исправление дырок в ядре, в линуксе и подольше бывало. Ответственных же нет, есть же “полупрозрачное огромное коммьюнити супер-экспертов, которые постоянно идеально пишут код, а любую ошибку молниеносно видят миллионы глаз и сразу исправляют, ведь если у миллионов глаз есть теоретическая возможность что-то увидеть, то они это обязательно увидят, обязательно изучат, обязательно разберутся и обязательно исправят”, а значит делать ничего не надо, надо просто подождать да скачать готовенькое. Что ж, подождали и скачали – 6 лет прошло, экая ерунда.
Новая серия начинается 19 июня 2017 года. Выясняется, что патч-то уязвимость недозакрывал и эксплуатировать её всё это время было возможно – просто чуть иначе, “перепрыгнув” stack guard page и получив доступ к чужой памяти (обычно это “куча”), не вызвав при этом ошибки. Добавление -fstack-check, таким образом, решало проблему только частично. Исправления на данный момент нет.
Что делать?
Ждать патчей, которые опять “в принципе поправят”, но т.к. это будет уже третий раз, то относиться к этому можно изначально с некоторым подозрением.
Снизить вероятность атаки можно, увеличив размер stack guard от одной страницы (4 КБ, например) до 1 МБ, что сделает использование уязвимости более сложным (но не уберёт возможность целиком).
Также возможны манипуляции с ограничением выделения памяти при обработке LD_AUDIT, LD_HWCAP_MASK и LD_PRELOAD, но они будут привязаны к используемому ПО и конкретной системе, поэтому какие-либо числа назвать затруднительно.
Какие масштабы?
Судя по краткому списку PoC, всё очень весело:
To illustrate our findings, we developed the following exploits and proofs-of-concepts:
– a local-root exploit against Exim (CVE-2017-1000369, CVE-2017-1000376) on i386 Debian;
– a local-root exploit against Sudo (CVE-2017-1000367, CVE-2017-1000366) on i386 Debian, Ubuntu, CentOS;
– an independent Sudoer-to-root exploit against CVE-2017-1000367 on any SELinux-enabled distribution;
– a local-root exploit against ld.so and most SUID-root binaries (CVE-2017-1000366, CVE-2017-1000370) on i386 Debian, Fedora, CentOS;
– a local-root exploit against ld.so and most SUID-root PIEs (CVE-2017-1000366, CVE-2017-1000371) on i386 Debian, Ubuntu, Fedora;
– a local-root exploit against /bin/su (CVE-2017-1000366, CVE-2017-1000365) on i386 Debian;
– a proof-of-concept that gains eip control against Sudo on i386 grsecurity/PaX (CVE-2017-1000367, CVE-2017-1000366, CVE-2017-1000377);
– a local proof-of-concept that gains rip control against Exim (CVE-2017-1000369) on amd64 Debian;
– a local-root exploit against ld.so and most SUID-root binaries (CVE-2017-1000366, CVE-2017-1000379) on amd64 Debian, Ubuntu, Fedora, CentOS;
– a proof-of-concept against /usr/bin/at on i386 OpenBSD, for CVE-2017-1000372 in OpenBSD’s stack guard-page implementation and CVE-2017-1000373 in OpenBSD’s qsort() function;
– a proof-of-concept for CVE-2017-1000374 and CVE-2017-1000375 in NetBSD’s stack guard-page implementation;
– a proof-of-concept for CVE-2017-1085 in FreeBSD’s setrlimit() RLIMIT_STACK implementation;
– two proofs-of-concept for CVE-2017-1083 and CVE-2017-1084 in FreeBSD’s stack guard-page implementation;
– a local-root exploit against /usr/bin/rsh (CVE-2017-3630, CVE-2017-3629, CVE-2017-3631) on Solaris 11.
Говоря проще, любое приложение на уязвимой системе может получить локального рута.
Плохо, когда в середине 2017го года, в позиционируемой как “безопасная серверная ОС” живут ошибки 12ти летней давности, делающие возможными такие уязвимости, которые невозможны (в силу дизайна ОС) в настольной Windows XP с первым сервис-паком.
Ещё хуже, когда эту ошибку “абы как” исправляли дважды, но не исправили.
Показательна и история с “родословной” данной уязвимости. По всей видимости ошибка, допущенная изначально в SUN’овской операционке, была тупо скопирована вместе с кодом управления памятью везде, где только можно – и в BSD системы, и в linux. Несмотря на сказки о “экспертном сообществе, которое, благодаря открытости, постоянно вычитывает код, и ни одна ошибка не проскользнёт”, несмотря на двукратное напоминание о данной проблеме – в 2005 и в 2010 году – всё обходилось подходом “да вроде и так сойдёт”, либо созданием откровенных костылей типа “надо на уровне системы ограничить ресурсы жёстко” или “надо пересобрать со специальными ключами”.
Так как первый вариант с ограничением требовал интеллектуальных усилий по точному подбору значений RLIMIT_STACK / RLIMIT_AS, а второй требовал пересборки и мог приводить к потенциальному падению производительности (крохотному, но всё же), то экспертное сообщество решило просто забить на это. Сколько систем было взломано за эти 12 лет – неизвестно.
Полупрозрачные СПО-эксперты, имеющие теоретический доступ к исходным кодам, и теоретическую возможность всё исправить и написать в сто раз лучше самостоятельно, в очередной раз наглядно показывают унылый результат одного из самых громких провалов в IT-отрасли – концепции Открытость и свободность* автоматически приводят к улучшению качества кода и появлению более безопасного, более технологичного и более надёжного ПО.
Результат этот состоит в том, что появление возможности “дайте списать” приводит лишь к снижению активности по разработке чего-то своего, а аудит чужого кода – не то чтобы до уровня “могу доработать”, а хотя бы до “понятно, что оно и зачем делает” становится возможностью всё меньшего процента участников – ведь остальные только и умеют, что копипастить чужое с аргументом “оно же открытое, а значит внутри там всё уже проверено и надёжно”.