В ядре Linux выявлена опасная уязвимость (https://github.com/dirtycow/dirtycow.github.io/wiki/Vulnerab...) CVE-2016-5195 (https://security-tracker.debian.org/tracker/CVE-2016-5195), которой присвоено кодовое имя "Dirty COW (http://dirtycow.ninja/)", позволяющая непривилегированному локальному пользователю повысить свои привилегии в системе. Проблема отмечена некоторыми изданиями как одна из наиболее опасных уязвимостей в ядре, чему способствовали наличие рабочего прототипа эксплоита (https://github.com/dirtycow/dirtycow.github.io/blob/master/d...), простота проведения атаки и сведения об использовании данной уязвимости злоумышленниками до выявления и исправления проблемы добросовестными исследователями безопасности (проблема была выявлена на основе изучения перехваченного эксплоита). Проблема присутствует с 2007 года и проявляется в ядрах Linux, начиная с выпуска 2.6.22.
Уязвимость вызвана состоянием гонки при обработке copy-on-write (COW) операций в подсистеме управления памятью и позволяет нарушить работу маппинга памяти в режиме только для чтения. С практической стороны, проблема позволяет осуществить запись в области памяти, отражённые в режиме только для чтения. Например, в прототипе эксплоита показано (https://github.com/dirtycow/dirtycow.github.io/blob/master/d...) как использовать данную проблему для изменения содержимого файла, принадлежащего пользователю root и доступного только на чтение. В том числе, при помощи предложенного метода атаки непривилегированный злоумышленник может изменить исполняемые системные файлы, обойдя штатные механизмы управления доступом.$ sudo -s
# echo this is not a test > foo
# chmod 0404 foo
$ ls -lah foo
-r-----r-- 1 root root 19 Oct 20 15:23 foo
$ cat foo
this is not a test$ gcc -lpthread dirtyc0w.c -o dirtyc0w
$ ./dirtyc0w foo m00000000000000000
mmap 56123000
madvise 0
procselfmem 1800000000$ cat foo
m00000000000000000
Уязвимость устранена (https://git.kernel.org/linus/19be0eaffa3ac7d8eb6784ad9bdbc7d...) в выпусках ядра Linux 4.8.3, 4.7.9 и 4.4.26. Обновления пакетов с ядром уже сформированы для дистрибутивов Debian (https://security-tracker.debian.org/tracker/CVE-2016-5195), Ubuntu (https://www.ubuntu.com/usn/usn-3107-1/), Mageia (https://advisories.mageia.org/MGASA-2016-0347.html), SUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-5195), Fedora (https://bodhi.fedoraproject.org/updates/FEDORA-2016-c8a0c7eece). Для openSUSE (https://lists.opensuse.org/opensuse-security-announce/2016-10/), CentOS (https://lists.centos.org/pipermail/centos-announce/2016-Octo...) и RHEL (https://rhn.redhat.com/errata/rhel-server-7-errata.html) исправления пока не выпущены (в RHEL/CentOS 5 и 6 представленный эксплоит не работает из-за закрытия /proc/self/mem на запись, но в RHEL/CentOS 7 такого ограничения нет).URL: http://openwall.com/lists/oss-security/2016/10/21/1
Новость: http://www.opennet.me/opennews/art.shtml?num=45354
Сейчас полезут ненавистники опенсорса, мол, 9 лет не могли исправить...
9 лет не могли исправить... open sores...
В OpenSource уязвимости хотя-бы находят. В проприетарщине еще бы 9 лет висела и всем было пофиг.
> В проприетарщине еще бы 9 лет висела и всем было пофиг.Ну естественно, нет. Заинтересовываются лишь в том, что имеет бызнес отдачу.
Открытость/закрытость кода тут не причём вообще.
Ты хотел сказать СПЕЦСЛУЖБО отдачу. :D
Ну в том числе. Любая заинтересованность годится.
Никто не будет искать дырки в заборе к заброшенному разваленному дому. Как и никто не будет этот забор латать.
А лицензия... Её в карман не положишь.
PS: какие здесь фанатики смешные, популизм и только :D
В проприетарщине не находят, там закладывают!
Учите матчасть :)
А то в православном опенсорсе нет. Торвальдс и кто в теме скорее всего на своих, "особых" ядрах сидят.
Там в теме более 1000 разработчиков из разных стран и контор, так что все не сговорятся. А, вы используете уже собраное ядро из дистра одной отдельно взятой конторы? Ну так собирайте сами из исходников.
99% пользователей не являются ни программистами, ни специалистами в безопасности, что бы по исходному коды дырки находить.
ДБ!(С) Лавров.
Прочти внимательно на что отвечаешь. Впрочем - не поможет :(
> 99% пользователей не являются ни программистами, ни специалистами в безопасности, что бы
> по исходному коды дырки находить.ну дак и сиди ровно на жопе, что ты влез в дискуссию?
Глупости пишете. Вы просто не понимаете, как обеспечивается секретность того или иного дела, в котором задействовано много людей. Прежде всего к делу подпускаются только те, кто не испытывает потребности чесать языком. И таких очень много.
О том, что англичане захватили лодку с шифровальной машиной, отбуксировали ее к себе, знали более 8 тысяч человек и никто не сказал. В результате нагличане несколько лет втихаря расшифровывали обмен Рейха с подлодками и выиграли войну на море.
ПАК-ФА Т-40 разрабатывался с 80-х годов и был явлен публике почти через 30 лет. Задействовано народу было более 40 тысяч и никто ни слова не произнес из чего, какие характеристики и т.д. и т.п. И вообще, что такие работы ведутся.
Так что какое-то ядро запросто.
в православном -- нет, а вот в остальном еще неизвестно
отступление от принципа KISS делает открытокод неправославным
А моно-копролит ядра это уже отступление от принципа KISS или еще нет?
Потому что ему уж очень мало програмных продуктов соответствуют.
Из массово используемы, может быть seL4, MINIX или ThreadX подойдут под описание.
Откуда такая уверенность? Учитывая, что клосед сорс бы не упомянул вообще об этой уязвимости даже после ее исправления?
> Откуда такая уверенность? Учитывая, что клосед сорс бы не упомянул вообще об
> этой уязвимости даже после ее исправления?Ну почему. Вон как оракл в соседней новости -- с "плановым" обновлением, нацеленным на "на устранение критических проблем и уязвимостей"
> В октябрьском обновлении в сумме устранено 253 уязвимости.Ходят слухи, что у них с Адобом на этот счет соревнования в лучших традициях "даешь пятилетку за три дня!".
Пока что побеждает дружба (по общему количеству дырок в продуктах Оракл на втором месте сразу после МСца. Но по количеству дыр в единичном продукте -- флеш давно и надежно ушел в отрыв) :)
> В OpenSource уязвимости хотя-бы находят. В проприетарщине еще бы 9 лет висела
> и всем было пофиг.Статью не читай
@
Каменты пишиВас не смутило, что уязвимость нашли не потому, что OpenSource, а потому, что случайно обнаруженный рабочий эксплойт изучили? Или вы имеете в виду, что злоумышленникам проще найти уязвимости в OpenSource - и потом их использовать, пока (если?) не прикроют, когда в проприетарщине такой номер не прошёл бы? =)
А чего должно смущать? Для поиска уязвимостей надо пользоваться всеми доступными средствами.
> А чего должно смущать? Для поиска уязвимостей надо пользоваться всеми доступными средствами.Смущает, что мысль в целом получилась такая: уж лучше пусть уязвимостью пользуются злоумышленники (а потом разработчики как-нибудь её нескоро закроют), чем она будет висеть никому не известная (а потом разработчики как-нибудь её нескоро закроют).
А ведь исходники открыты, миллионы программистов....казалось бы какая тут может быть дыра)))
а я то думаю, кто правит мои файлы?
pussy.exe
У меня pussy.exe требует все пароли от всех учётных записей, и если не давать, выполняет brainfuck.exe. Видимо, её взломали с самого начала... А говорит, что я - первый пользователь.
> Видимо, её взломали с самого начала... А говорит, что я - первый пользователь.Pussy.exe - все такие. И ты - отнюдь не первый её пользователь.
> pussy.exeИ это правильно! Накосорезили разрабы линуха, но во всем виноваты разрабы (и пользователи) pussy.exe!
А у идиотов всегда так, благо их на опеннете все больше и больше.
.. и скоро им никто не будет мешать.
Это уже случилось. Опеннет давно превратился в виндозный междусобойчик.
Плохо что ли? Хорошо (с)Минусы: Как-будто на форуме умственно отсталых.
Плюсы: Зато не скучно. Можно найти собеседника любого интелектуального уровня.
че-т у меня в центоси 7 не работает.
Зачем в центось ставить семерку? Только десятку!
У меня в RHEL7 работает
ох ёёёёёё...
copy-on-write - это один из базовых компонентов Linux, дыры в нём - непозволительная роскошь... хорошо что прикрыли.как чувствовал, на своих системах доступ всяким анонимусам прикрыл :)
> как чувствовал, на своих системах доступ всяким анонимусам прикрыл :)и сидишь от рута?
зачем? в отличии от не-unix-like систем в Линуксе система разграничения прав очень простая и понятная, пользую обычную учётку...просто по дефолту был открыт доступ с гостевой сессии, который я зачем-то придавил... как чувствовал :)
>система разграничения прав очень простая и понятнаяНастройка selinux mls и mcs - это же интуитивно понятная процедура, ага
подразумеваются грамотные пользователи, естессно.
А зачем так паниковать? Ну нашли и нашли. Главное, что нашли и исправили. Уязвимости - штука из серии соревнование брони и ядра. Это вечно. Мне другое интересно - а для штатных ядер Debian 8 будут исправления? Чтобы не обновлять ядро. Или без этого никак и нужно ставить то, свежайшее?
Когда-то я пробовал SLES 11 SP3, 60-дневный бесплатный период. Вернее, его десктопную редакцию. Мне часто приходили обновления, всё фиксилось, всё правилось.Потом я включил "белый IP" - нужно было поднять сервак, чтобы поиграть с друзьями. Поиграли, сервак я отключил, но "белый IP" остался.
Решил я попробовать Bitcoin Wallet в связке с белым IP - помню раньше на ADSL было что-то около 200 соединений с пирами, а как перешёл на оптику, так за NAT больше 8-ми не было. Сколько ни пердолься с пробросом портов и uPNP.
Ну я скачал официальный релиз - он к счастью подходил по Glibc. Запустил. 12 соединений. Блин ну как так. IP же "белый"! Открыл порт 8332 в SUSE Firewall. Нифига. Отрубил Bitcoin.
На следующий день включаю компьютер, ввожу логин пароль, и вижу инфу о неудачных логинах. Пока не закрыл фаерволлом SSH, их могло быть много, но с тех пор - нет. Так вот - после экспериментов с Bitcoin система мне сказала "Не удаётся прочитать инфу о неудачных логинах. Файл lastb удалён". Вот это нихрена себе.
Репортить я не стал - к этому моменту я не покупал SUSE, да и сейчас у меня самая дешёвая версия с self-support. Я просто снёс систему и вернул NAT.
Это я к чему. "Ну нашли и нашли, исправили же" - в новости же ясно сказано, что дырой активно пользовались продолжительное время. Может и меня ломали именно через неё. Может и тебя ломали
Сам себе поставил пароль на рута вида 1234, а разработчики ядра виноваты в том, что тебя взломали через local privilege escalation? Как? Через libastral.so ?
Научись настраивать фаерволы и SSH, прежде чем что-то говорить.
> Сам себе поставил пароль на рута вида 1234, а разработчики ядра виноватыв том и дело, что не на рута, а на непривиллегированного юзера для однократного теста - и даже не 1234, а посложнее (ssh'шный червяк подбирает довольно непростые, если дать ему достаточно времени). А потом в текучке- замотался и забыл его заблокировать, или "временное" превратилось в постоянное.
Альтернативный вариант - шелл-ескейп в вебне, которую разрабатываешь и поддерживаешь не ты.
И вроде бы ты даже оградил всеми возможными и невозможными способами эту хрень, так что из этого шелла вроде как только delete * в ее же sql'ной таблице можно сделать, и спишь почти спокойно.А потом оно в две секунды становится у тебя рутом, причем ты так и не понимаешь - каким образом и что именно у тебя уязвимо (то есть вычистив пакость - продолжаешь либо жить как на вулкане, либо на всякий случай делаешь массу бесполезных и мешающих работе действий,
пытаясь закрутить гайки). И через десять лет, ВНЕЗАПНО - узнаешь.> Научись настраивать фаерволы и SSH, прежде чем что-то говорить.
научись админить не только локалхост, где кроме рута других пользователей нет, прежде чем давать с таким апломбом советы.
>ssh, белый IP, парольВ списке либо что-то лишнее, либо чего-то не хватает.
Ну против брута ssh есть довольно простые средства вроде denyhosts. У меня так в неделю больше 100 ip попадало в черный список. denyhosts - довольно простая но действенная штука, ИМХО без нее вообще нельзя ssh открывать наружу.Насчет уязвимостей в вебне сейчас можно заюзать тот же docker. Я лет 5 назад делал виртуалку через libvirt для внешних служб и прокидывал туда хранилище с хост-системы. Я к тому, что нужно подобные вырианты учитывать с самого начала, а не только когда пароль на рута тебе сменят.
> Ну против брута ssh есть довольно простые средства вроде denyhosts.главное, иметь запасного админа, когда оно тебя же и заденаит, ага.
(кстати, кто проводил аудит этого денайхоста и нет ли там уязвимости похлеще - ну типа каких-нибудь "интересных" юзернеймов ему скормить или еще чего-нибудь, что можно записать в логи?)> Насчет уязвимостей в вебне сейчас можно заюзать тот же docker.
если тебе платят за то что крутится внутри - совершенно все равно, что твой мега-секьюрный хост не поломали вместе с контейнером - при правильной системе архивов, даже восстанавливать не сложнее.
А вот поддерживать в актуальном и попатченном состоянии сто контейнеров _в_довесок_ еще к десятку хостов - уже довольно задалбывающе.
И это только два вектора атаки, а их еще можно придумать мильен с тыщами.
Понятно, что есть много разных способов уменьшить поражаемую площадь, и ими приходится пользоваться, но это совсем не повод расслабляться с мыслью "а-а, эксплойт локальный, не чешусь".
P.S. кстати о векторах - что-то я не уверен за счастливых пользователь rhel. Есть подозрение, что там именно доступ через /proc перекрыт, а race остался.
>> Ну против брута ssh есть довольно простые средства вроде denyhosts.
>главное, иметь запасного админа, когда оно тебя же и заденаит, ага.Эй школота!, там WL как бе есть, впрочем слишком сложно для таких :)
Остальное даже читать не стал :-р
Сынок, ты правда думаешь, что по твоим комментариям окружающим не понятно сколько тебе лет?
> Ну против брута ssh есть довольно простые средства вроде denyhosts.против брута ssh есть iptables, аж 2 команды:
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource
-A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 120 --hitcount 3 --rttl --name SSH --rsource -j DROPкуда проще?
Для эксплуатации этой уязвимости нужно сначала залогиниться. Да, плохо конечно, когда рута могут получить те юзеры, которые не должны его получать. Но взломать рамдомный сервак используя эту уязвимость не получится. А так - уязвимостей с повышением привилегий хватает на любой ОС.
Существуют шаред хостинги
> Существуют шаред хостингишаред по определению думед ту дай, даже при том что там, обычно, если оно сразу не сдохло, и ядра не самые стандартные, и много еще чего понапилено, из-за чего даже в принципе работающий эксплойт может обломаться просто из-за необычности системы. Все равно периодически что-нить да поломают, все в общем привыкли и чудес не ждут.
А тут проблемка шире, она может вылезти боком даже на локалхосте, если там не только порнуху с понями смотреть.
> Для эксплуатации этой уязвимости нужно сначала залогиниться. Да, плохо конечно, когда рутаНет. В вебне полно remote execution-ов. Вы ничего не понимаете в эксплуатации.
Новость читал? В 3.16.36-1+deb8u2 исправлено
>для штатных ядер Debian 8 будут исправления? Чтобы не обновлять ядро. Или без этого никак и нужно ставить то, свежайшее?А? Ты хочешь обновить ядро не обновляя ядро?
Я х.з. что ты спросил, но на всякий случай отвечу -- забей, с ближайшим апдейтом придёт фикс этой проблемы. Просто запускай apt иногда.
Ну зачем же нервничать?
Вероятно, человек имел ввиду временную заплатку до ближайшего апдейта с фиксом.
>А зачем так паниковать?чёт я пока не наблюдаю паники, что необычно для опеннета. наверно ИБ-истерички ещё не проснулись
> А зачем так паниковать? Ну нашли и нашли.проблема в том, что нашли - давным-давно. Но не те, которые сейчас исправили.
И да, заняно что редхат в очередной раз успел подстелить соломку даже не задумываясь о ней (как было и с рейсом в pty) - но успешно забыл об этом.
P.S. или задумываясь? ;-)
> Мне другое интересно - а для штатных ядер Debian 8 будут исправления?У меня сегодня прилетело.
Если стремиться к идеалу совсем по фен-шую, то самое лучшее ядро - это ядро <= 2.6.22. Потому что в 2.6.23 появилось это: https://en.wikipedia.org/wiki/Completely_Fair_Scheduler взамен этого: https://en.wikipedia.org/wiki/O(1)_scheduler
Кружок занимательной археологии дальше по коридору.
Можете зайти ещё в клуб молодых психиатров. Там помогут.
человек намекает что в угоду cgroups - шедулер ухудшили - из-за чего он начал лагать на большом списке задач, и достаточно большом списке cgroups.
«состоянием гонки»:face palm:
RTFM. Если не разбираешься в терминологии, лучше промолчать, а не выставлять себя в глупом виде.
Умник, я хорошо знаю, что такое "race condition", "out of the box" и "seamless roaming". Но по-русски "состояние гонки", "из коробки" и "бесшовный роуминг" звучат крайне отвратно. О чём и было мной высказано.
Но правильный вариант перевода ты так и не предложил.
Тут предлагай — не предлагай, а как "бесшовничали" с "искаропками", так и будут продолжать. Остаётся только уныло констатировать.
Ага, "о чем высказано". Рассказывай нам теперь про хороший стиль в русском языке.
А какой твой вариант перевода "race condition", ммм?
раса условия?
Nigger if?
Людей, которые находят такие вещи - надо награждать хорошей пачкой бабла. Его наградят?
> Людей, которые находят такие вещи - надо награждать хорошей пачкой бабла.не переживай, они с 2007го уже неплохо самонаградились.
Те кто первыми нашли, разумеется.
Debian,
Linux amd64 4.7.0-1-amd64 #1 SMP Debian 4.7.2-1 (2016-08-28) x86_64 GNU/LinuxНе рабит ='(
Linux 4.7.0-1-amd64 #1 SMP Debian 4.7.6-1 (2016-10-07)
робит
Debian,
Linux 4.7.7-custom #1 SMP
Робит, к сожалению. Собирал ядро just for fun.
Интересно, а если бы код ядра был написан на Modula3, а не C, то такого рода уязвимости в принципе остались бы возможны?
> Интересно, а если бы код ядра был написан на Java, а не C, то такого рода уязвимости в принципе остались бы возможны?Поправил, не благодари.
> если бы код ядра был написан на Java, а не C,То все равно можно было бы пропустить lock/wait или что там используется...
synchronized конечно не обойдешь, но там тоже могут быть баги в компиляторе/vm и код превратиться в однопроцессорный в критических участках.
это был сарказм, ваш кэп :)
> А если бы код ядра был написан на любом другом языке, то такого рода уязвимости всё равно были бы, ничего бы не изменилось.fix #2
> Интересно, а если бы код ядра был написан на Modula3, а не
> C, то такого рода уязвимости в принципе остались бы возможны?Ты эпический дурак. Или опять увидел "уязвимость", "linux" и сразу подумал про buffer overflow? Уязвимость вызвана race condition, этот твой модуля хоть в треды то умеет. Если нет, то и проблем там таких нет, а если да - то у меня для тебя плохие новости.
А вот раст умеет.
> А вот раст умеет.Раст лучше чем Изя. Без вопросов!
> этот твой модуля хоть в треды то умеетТа реализация M2, которой я ещё на досе пользовался -- умела сопроцессы.
>> этот твой модуля хоть в треды то умеет
> Та реализация M2, которой я ещё на досе пользовался -- умела сопроцессы.Михаил, небольшой вопрос: Почему iZen-a можно невозбранно обсирать любому форумчанину, а любые посты в его защиту удаляются даже если они были нейтральны?
P.S. Не считаю Изю за специалиста вообще, но травля его со стороны модерации ресурса - откровенный перебор. Opennet.ru и так уже занял бывшее место ЛОР-а по количеству троллинга в комментариях, но сейчас уже, похоже, стремится к SU.KASCHENKO!
Закономерный вопрос: Куда дальше?
> Почему iZen-a можно невозбранно обсирать любому форумчанину,Я не совсем правильно выразился с первого раза. Не обсирать, а оскорблять. Но сути это не меняет: Модерация в полной заднице и занимается разжиганием.
Если Вы считаете, что при программировании на Си проблемы могут быть только из-за переполнения буферов, то у меня для вас плохие новости.
Но это частично можно поправить:
-fsanitize=undefined
-fsanitize=address
-fsanitize=kernel-addressИ что особенно важно в контексте новости
-fsanitize=thread - Enable ThreadSanitizer, a fast data race detector.Поскольку всё это приклеено к Си изолентой, то оно изрядно тормозит и, к сожалению, многими рассматривается исключительно как отладочная возможность. В других языках многие проблемы попытались решить на уровне дизайна языка и поэтому оно может работать лучше. Что-то получилось, что-то нет. Поэтому само по себе задавание таких вопросов не является преступлением и поводом для кидания камней со стороны Си-праведников.
> И что особенно важно в контексте новости
> -fsanitize=thread - Enable ThreadSanitizer, a fast data race detector.и чем это помогло?
> Ты эпический дурак. Или опять увидел "уязвимость", "linux" и сразу подумал про buffer overflowПоходу ты - эпический "умный", если увидел впосте iZen-а слово "linux".
ну у тебя проблемы со зрением - пора проверяться, зайди на kernel.org
> Интересно, а если бы код ядра был написан на Modula3, а не
> C, то такого рода уязвимости в принципе остались бы возможны?А что, на этом языке написано что-то, кроме cvsup?
На modula-2 пишут софт для спутников, специализированный промсофт и прочие интересные вещи. Т.е. используется там, где языки, ставшие трендом только по причине американского национализма, совершенно непригодны.
Я правильно понял что вы про фобос-грунт? :-)
Интересно, а если бы код ядра был написан на Modula3, а не C, то ядро бы существовало?
> Интересно, а если бы код ядра был написан на Modula3, а не C, то ядро бы существовало?в гугле забанили? Оно есть. но вопрос всегда в возможностях
> Интересно, а если бы код ядра был написан на Modula3, а не CНу так напишите же. Только руки не сотрите обо все IMPLEMENTATION MODULE.
// интересно, сколько у меня там .mod и .def понаписато было...
>> Интересно, а если бы код ядра был написан на Modula3, а не C
> Ну так напишите же. Только руки не сотрите обо все IMPLEMENTATION
> MODULE.
> // интересно, сколько у меня там .mod и .def понаписато было...http://www-spin.cs.washington.edu/external/overview.html - посчитай )))
noexec для /home и др. не?
не. эксплоит можно и на питоне написать, это лишь вопрос умения.
так что только noexec на / :)
> noexec для /home и др. не?Нет, лучше отрубить питание и перерезать ethernet кабеля. Лучшая защита, я гарантирую это!
404 в правах разрешает чтение остальным
> 404 в правах разрешает чтение остальнымРазрешение чтения не должно разрешать демонстрируемую эксплоитом запись.
Офигеть! УМВР!
Только собираем с: $ gcc -pthread -lpthread dirtycow.c -o dirtyc0w
идейка хороша, но
swiftdev@pgdb1:~$ gcc -pthread -lpthread dirtyc0w.c -o dirtyc0w
dirtyc0w.c: In function ‘procselfmemThread’:
dirtyc0w.c:64:5: warning: implicit declaration of function lseek’ [-Wimplicit-function-declaration]
lseek(f,map,SEEK_SET);
^
dirtyc0w.c:65:8: warning: implicit declaration of function write’ [-Wimplicit-function-declaration]
c+=write(f,str,strlen(str));
^
dirtyc0w.c: In function ‘main’:
dirtyc0w.c:82:3: warning: implicit declaration of function fstat’ [-Wimplicit-function-declaration]
fstat(f,&st);
^
dirtyc0w.c:96:10: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘void *’ [-Wformat=]
printf("mmap %x\n\n",map);
^
>[оверквотинг удален]
> ^
> dirtyc0w.c: In function ‘main’:
> dirtyc0w.c:82:3: warning: implicit declaration of function fstat’ [-Wimplicit-function-declaration]
> fstat(f,&st);
> ^
> dirtyc0w.c:96:10: warning: format ‘%x’ expects argument of type ‘unsigned
> int’, but argument 2 has type ‘void *’ [-Wformat=]
> printf("mmap %x\n\n",map);
> ^
>
Нельзя тебе эксплойты собирать, покалечишься еще ненароком.
> Нельзя тебе эксплойты собирать, покалечишься еще ненароком.Бла-бла-бла... Ты осилил прочитать процитированные варнинги или не понял о чём они?
Они вообще-то указывают на полную хрень, типа использования 32-х битного спецификатора printf при попытке вывести указатель, который в современных intel'овских системах (с вероятностью близкой к единице) 64-х битный. Это, по-идее, не критично с hi-ending порядком байтов -- самые интересные в данном случае младшие биты будут выведены, но всё равно неприятно. Так же как и неуказание unistd.h в списке инклюдов, что приводит ко всем этим варнингам вокруг использования open/fstat/lseek.
Я то прекрасно понимаю почему у него компиляция не прошла. А вот дятел, к-й не разбирается в программиронии, но пытается собрать ЭКСПЛОЙТ, опасен в первую очередь для себя. Такому rm -rf /* подсунут, дак он с телефона потом напишет, что фигня какая-то, а не эксплойт... теперь вообще комп не загружается.
> Я то прекрасно понимаю почему у него компиляция не прошла.Объясни мне, почему ты это понимаешь? Вот я не понимаю: я не вижу ни одной ошибки компиляции, исключительно варнинги. Из чего я делаю вывод, что компиляция прошла.
Вот это
> dirtyc0w.c:64:5: warning: implicit declaration of function lseek’ [-Wimplicit-function-declaration]
> lseek(f,map,SEEK_SET);как бы говорит нам, что мы задекларировали функцию lseek и должны сами написать её реализацию (либо подключить библиотеку с её реализацией).
Я очень сомневаюсь что Аноним смог написать реализацию lseek или подключить библиотеку.
> Вот это ... как бы говорит нам...Если без "как бы", а "на самом деле", то это говорит о том, что в коде используется функция lseek, но она нигде не объявлена. Это варнинг, а не ошибка, потому что сишный компилятор пытается угадать прототип функции по тому, как эта функция используется, и компилирует код на основании своих догадок. Как правило это работает.
Функция lseek, да будет вам известно, наряду с open, close, read и write -- одна из базовых функция для *nix систем. Можете взять и повтыкать в man 2 lseek. Там в варнингах еёщ упомянуты write и fstat -- это всё сисколлы, точнее прототипы glibc'овых обёрток к сисколлам. Эти прототипы-декларации лежат в файлике unistd.h. И, как вы можете заметить, промежь инклюдов нет #include <unistd.h>, и именно поэтому и лезут такого рода варнинги. Это не становится ошибкой, потому что libc.so, по-любому, линкуется к бинарю, и линкер находит в libc.so все эти функции.
> Объясни мне, почему ты это понимаешь? Вот я не понимаю: я не
> вижу ни одной ошибки компиляции, исключительно варнинги. Из чего я делаю
> вывод, что компиляция прошла.Потому что он может видеть будущее, а ты нет.
И в этом будущем он увидел ошибку линковки.
>> Объясни мне, почему ты это понимаешь? Вот я не понимаю: я не
>> вижу ни одной ошибки компиляции, исключительно варнинги. Из чего я делаю
>> вывод, что компиляция прошла.
> Потому что он может видеть будущее, а ты нет.
> И в этом будущем он увидел ошибку линковки.Нет, там не будет ошибки линковки. Выше я даже объяснил почему. Я гораздо лучше могу видеть будущее: если ты попробуешь хоть иногда писать на C, то ты будешь знать его гораздо лучше, и не будешь писать бреда в комментах. Ты б хотя бы попробовал бы сам скомпилять этот "сплоет", и посмотрел бы как у тебя вылезут эти варнинги, но бинарь всё равно соберётся, слинкуется и даже сможет запуститься. Не надо гадать, не надо говорить о том, чего не знаешь.
Да ты оказывается дилетант, C в глаза не видевший!
Я рад, что ты скатился в аргументацию уровня ad hominem. Это очень соответствует по уровню прочим твоим комментариям.
что то с моими руками не так ...
swiftdev@pgdb1:~$ gcc -lpthread dirtyc0w.c
dirtyc0w.c: In function ‘procselfmemThread’:
dirtyc0w.c:64:5: warning: implicit declaration of function lseek’ [-Wimplicit-function-declaration]
lseek(f,map,SEEK_SET);
^
dirtyc0w.c:65:8: warning: implicit declaration of function write’ [-Wimplicit-function-declaration]
c+=write(f,str,strlen(str));
^
dirtyc0w.c: In function ‘main’:
dirtyc0w.c:82:3: warning: implicit declaration of function fstat’ [-Wimplicit-function-declaration]
fstat(f,&st);
^
dirtyc0w.c:96:10: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘void *’ [-Wformat=]
printf("mmap %x\n\n",map);
^
/tmp/ccFdI7nc.o: In function `main':
dirtyc0w.c:(.text+0x1a4): undefined reference to `pthread_create'
dirtyc0w.c:(.text+0x1c0): undefined reference to `pthread_create'
dirtyc0w.c:(.text+0x1d1): undefined reference to `pthread_join'
dirtyc0w.c:(.text+0x1e2): undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
>[оверквотинг удален]
> int’, but argument 2 has type ‘void *’ [-Wformat=]
> printf("mmap %x\n\n",map);
> ^
> /tmp/ccFdI7nc.o: In function `main':
> dirtyc0w.c:(.text+0x1a4): undefined reference to `pthread_create'
> dirtyc0w.c:(.text+0x1c0): undefined reference to `pthread_create'
> dirtyc0w.c:(.text+0x1d1): undefined reference to `pthread_join'
> dirtyc0w.c:(.text+0x1e2): undefined reference to `pthread_join'
> collect2: error: ld returned 1 exit status
>Нельзя тебе эксплойты собирать, покалечишься еще ненароком.
man CFLAGS
gcc -pthread dirtyc0w.c
дурачок, ёпт! на 78 строке должен быть %p а не %x
и комилить надо так: gcc -pthread -o test test.c
Твою ошибку исправляет опция -pthread. А так, эксплоит собирается криво, не завершается самостоятельно, грузит ЦП на 100 пудов, но свою грязную работу делает идеально.
Простите за любопытство, но что у вас за платформа/тулчейн, что вам нужна опция -pthread? В манах к gcc эта опция упомянута применительно к каким-то экзотическим платформам, типа PowerPC и чего-то ещё, короче я не думаю, что это имеет отношение к данному случаю. Но вам помогает... Поэтому любопытно.
Может вместо glibc что-нибудь экзотическое? Или версия gcc 2.95? Или что вообще?
- Linux localhost.localdomain 4.4.0-43-lowlatency #63-Ubuntu SMP PREEMPT Wed Oct 12 14:41:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
- gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2)Всё слишком обычно, без этой опции была именно та же ошибка, описанная Анонимом свыше.
> - Linux localhost.localdomain 4.4.0-43-lowlatency #63-Ubuntu SMP PREEMPT Wed Oct 12 14:41:17
> UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
> - gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2)
> Всё слишком обычно, без этой опции была именно та же ошибка, описанная
> Анонимом свыше.Да, странно... Судя по убунте и libc тут стандартная glibc, без всяких наворотов. Разве что какие-то убунтопатчи повлияли. Загадка.
Эта опция нужна чуть менее чем на любых версиях gcc если тебе нужно работать с тредами.
Начиная с 3.x и сейчас вплоть до gcc-4.9.x я никогда не использовал -pthread. Вот -lpthread иногда пригождалась для линковки. И именно поэтому я и спрашиваю, мне непонятно. И твои слова типа "чуть менее чем на любых" демонстрируют твоё владение интернет-сленгом, но на поставленный вопрос не отвечают и непонятки мои не снимают.
Да, она одно время пропадала для большинства платформ, но не теперь, они, видимо, решили всё унифицировать. Теперь опция используется на большинстве платформ
То есть, может быть, это особенность gcc-5.x? Это бы всё объяснило.
Судя по "gcc -dumpspec" -pthread выставляет флаг -lpthread и декларирует макрос _REENTRANT для крестов. Так-что, в принципе, -lpthread и -pthread на интеловских архитектурах взаимозаменямы. Для каких-нибудь экзотических архитектур он может делать что-то другое.
$ ./dirtyc0w foo m00000000000000000
mmap 38e46000
madvise 0
procselfmem -100000000
$ cat foo
this is not a test
$ uname -r
4.1.7-hardened-r1
Даже не буду обновляться.
у меня на убунту 14.04 тоже не сработало: Linux 3.13.0-98-generic x86_64
> $ uname -r
> 4.1.7-hardened-r1
Один не работающий эксплоит не означает отсутствия в COW в вашем ядре состояния гонки.
$ ./dirtyc0w /tmp/foo m00000000000000000
mmap f06e9000
madvise 0
procselfmem -100000000
$ cat /tmp/foo
This is a test...
$ uname -r
4.4.6-hardened-r2
Таки да не работает, PaX сделал свое черное дело.
> PaX сделал свое черное дело.В PaX нет гонки на CoW или там просто /proc/self/mem закрыт?
>> PaX сделал свое черное дело.
> В PaX нет гонки на CoW или там просто /proc/self/mem закрыт?Гонка и уязвимость есть.
> $ ./dirtyc0w foo m00000000000000000
> mmap 38e46000
> madvise 0
> procselfmem -100000000
> $ cat foo
> this is not a test
> $ uname -r
> 4.1.7-hardened-r1Рано радуетесь.
ryona> does that mean grsec did not mitigate it?
spender> nothing could
spender> it's a low level logic bug
ryona> damn
spender> i mean, with TPE etc you can prevent someone from running an exploit binary or whatever
ryona> ok that's nasty
spender> but you can't prevent the flaw itself
ryona> kernelmode access or just to root?
spender> to root, but that'll give you kernelmode :p
> Рано радуетесь.МЫ ВСЕ УМРЁМ!!!1111111
/sLinux 4.7.7, лень обновлять.
Где те 100 тыс миллионов глаз которые должны были смотреть?.. вот бага тянется 10 лет - а никто ее не заметил :)
> Где те 100 тыс миллионов глаз которые должны были смотреть?.. вот багато есть как это, где?
> тянется 10 лет - а никто ее не заметил :)как никто? А эксплойт сам зародился от грязного белья? Просто не все заметившие рвутся улучшать мир. Ну или точнее, есть разные способы его улучшения.
> Где те 100 тыс миллионов глаз которые должны были смотреть?.. вот бага
> тянется 10 лет - а никто ее не заметил :)Напрягись! Вспомни!! Сколько лет было обещано и гарантировано там --- ну про глаза?
//100млрд глаз... 7млрд+- хуманов... Вы, рептилоиды, палитесть или митингуете от партии мух?..
фиксили ещё 11 лет назад, а потом откатили фикс и забили.
This is an ancient bug that was actually attempted to be fixed once
(badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
get_user_pages() race for write access") but that was then undone due to
problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").
> $ gcc -lpthread dirtyc0w.c -o dirtyc0w
> $ ./dirtyc0w foo m00000000000000000
> mmap 56123000
> madvise 0
> procselfmem 1800000000
> $ cat foo
> m00000000000000000а может кто то пояснить, что оно делает и как интерпретировать результат?
Только что проверил на CentOS 6
$ ./dirtyc0w foo m00000000000000000
mmap 8f004000
madvise 0
procselfmem -100000000$ cat foo
this is not a test$ uname -r
2.6.32-642.6.1.el6.x86_64
сказано же в новости что на центоси 6 не работает
Сказано и не работает - это таки две больших разницы.
оно файл переписывает, у меня сработало.
> а может кто то пояснить, что оно делает и как интерпретировать результат?оно записывает строку m00000000000000000 в файл foo, хотя оно не имеет необходимых для этого прав
у меня есть этот "перехваченный эксплойт". реально выдаёт рутовый шелл на всех ядрах новее, примерно, 3.2, но ему требуется определённый рут-суидный бинарник в системе (ping6, umount, етц), которые не везде суидный. кому интересно, тесты на убунтах и дебианах:UBUNTU 12.04 === 3.2.0-111-generic === NON-VULN, too old kernel
UBUNTU 12.04.5 === 3.13.0-32-generic === VULN
UBUNTU 14.04 === 3.13.0-98-generic === VULN
UBUNTU 14.04.5 === 4.4.0-31-generic === VULN
UBUNTU 16.04 === 4.4.0-21-generic === VULN
UBUNTU 16.04.1 === 4.4.0-31-generic === VULN
UBUNTU 16.04.1 === 4.4.0-43-generic === VULN
UBUNTU 16.10 === 4.8.0-22-generic === VULN, kernel is vulnerable, but no needed suid-binary
DEBIAN 6.0.10 === 2.6.32-5-amd64 === NON-VULN, too old kernel
DEBIAN 7.11.0 === 3.2.0-4-amd64 === NON-VULN, too old kernel
DEBIAN 8.6 === 3.16.0-4-amd64 === VULN, kernel is vulnerable, but no needed suid-binary
Он меняет содержимое суидного бинарника, по идее этот лишь один из множества способов. С тем же успехом можно /etc/shadow поменять или любую программу периодически запускаемую от рута.
ты такой умный, тебе череп не жмёт? если любой бинарник и файл, ну так напиши эксплойт который рутовый пароль в "123" ставит.
> ты такой умный, тебе череп не жмёт?ну кто же тебе виноват, что ты дурак, и тебе даже человек, говорящий очевидные вещи, кажется недостижимой высотой гениальности?
> у меня есть этот "перехваченный эксплойт".выложи уж. один фиг бага запатчена
>no needed suid-binaryкитайцы что-ли писали?
выложь пожалуйста. было б неплохо неручёные телефоны рутить
Забавный эффект происходит на 3.19.7-200.fc21.x86_64 : после запуска коровы она как будто бы зависает и ничего не печатает после "mmap ********", но при этом файл изменяется... Вообще это очень хорошо что открыли - может помочь в получении рутовских возможностей на телефонах которые залочили тупые производители (где рута пока нету)
Вот бы и мне мой андроид наконец-то освободить.
Fedora 25 4.8.2-300.fc25.x86_64 замораживается напрочь даже SysRq не отвечает.А вот на RHEL 7.2 3.10.0-327.36.2.el7.x86_64 замечательно работает. Жопа то какая!
Осталось проверить линуксатор FreeBSD. Там база CentOS 6.8 и 7.2, а вызовы ядра естественно эмулируются FreeBSD.
Если тебе, то WSL лучше проверить.
JFYI
На openvz-ядре 2.6.32-042stab108.8 не воспроизводится.
На proxmox 3.4 с ядром 2.6.32-45-pve не воспроизводится.
Сайт прекрасен. Нет, это не очередная выпендрежная поделка на бутстрапе, здесь наоборот, концентрированный сарказм и высмеивание хипстоты:>we created a website, an online shop, a twitter account, and used a logo that a professional designer created
> Сайт прекрасен. Нет, это не очередная выпендрежная поделка на бутстрапе, здесь наоборот,
> концентрированный сарказм и высмеивание хипстоты:
>>we created a website, an online shop, a twitter account, and used a logo that a professional designer createdУгу, с шутками и прибаутками, явно не профессионал делал.
> сказано же в новости что на центоси 6 не работаетточно, упустил этот момент
4.8.2-1-ARCH долго работало и в итоге получилось
$ ./dirtyc0w /tmp/foo m00000000000000000
mmap 7e85e000madvise 0
procselfmem 1800000000
$ cat /tmp/foo
m000
На предпоследнем ядре стабильного дебиана прекрасно работает.
*Побежал обновлять все пэкарни*
5и6 - наше все.
Отлично теперь можно рутовать любой андроид :)
Дальше через через SELinux не проберешься
Школота на гитхабе: http://itmages.ru/image/view/5061906/0598c457
Дожили, епрст.
> Школота на гитхабе: http://itmages.ru/image/view/5061906/0598c457
> Дожили, епрст.как будто шитхаб создан не для хипсторов и школоты.
> как будто шитхаб создан не для хипсторов и школоты.Как будто хипстота и школота не считает, что всё в мире создано для них.
Linux im 4.6.0-0.bpo.1-amd64 #1 SMP Debian 4.6.4-1~bpo8+1 (2016-08-11) x86_64 GNU/Linux
Linux hetzner5 4.5.0-0.bpo.2-amd64 #1 SMP Debian 4.5.4-1~bpo8+1 (2016-05-13) x86_64 GNU/Linux
не сработалоLinux imho 4.7.0-0.bpo.1-amd64 #1 SMP Debian 4.7.5-1~bpo8+2 (2016-10-01) x86_64 GNU/Linux
сработалоКроме как от ядра от чего еще может зависить?
https://dirtycow.ninja10 коров из 10 за такой FAQ :D
> 10 коров из 10 за такой FAQ :DПрисоединяюсь! Для предотвращения подобных ситуевин в будущем, там предлагается донатить во фряху!
Отставить, во время неудачны тестов отсутствовал доступ на чтение (для группы тестера)
не пашет exploit, слакварь :Linux Dao 4.4.7 #2 SMP Tue Apr 12 15:45:52 CDT 2016 x86_64 AMD FX(tm)-8150 Eight-Core Processor AuthenticAMD GNU/Linux
держи нас в курсе
У криворуких 80го левела даже эксплойты не работают.
Не послушал Линус Танненбаума, вот и расхлёбывают теперь.
> Не послушал Линус Танненбаума, вот и расхлёбывают теперь.Вместо того, чтобы гонять весь такой правильный миникс на ворованой vmare из-под вантуза.
"уже эксплуатируемая злоумышленниками
Например, в прототипе эксплоита показано как использовать данную проблему"
На опеннет журналисты из федеральных каналов России... Где пример эксплуатации, например взлом rhel или googla?
> На опеннет журналисты из федеральных каналов России...
> Где пример эксплуатации, например взлом rhel или googla?Что Вы, потерь нет, а боевой экземпляр сдали повинившиеся блэкхеты.
Что Вы, о чем Вы? О том что автор статьи не привел конкретных способов эксплуатации и взломов конкретных систем. С давних времен используется человеками гипноз, но фактов его использования нет, но зато он есть, кто исправил эту воображаемую уязвимость мозга? Конкретных примеров нет, кроме подсадных уток... В данном случае даже уток нет(я про статью)
если ты из приведённого демонстрационного кода не способен сделать полноценную пробивалку — просто молча проходи мимо, не отсвечивай своим идиотизмом. потому что это тривиальная задача.
О конкретика, примеры, в ваших словах я их прямо вижу, может вам в бойцовский клуб? Нет вам в клуб знатоков идиотов, ведь вы же не идиот...
да зватит уже свою глупость демонстрировать, все поняли.
зватит, зватит и та сойдет
виноват, извиняюсь.
Эх, во раньше были времена. Ну, там античат и прочие сайты, где "умников" фильтровали. Все пропало и вот, теперь ОНИ приходят и ТРЕБУЮТ. Требуют! Совсем обнаглели.
#32643 - м?
воблин, обновлятьсянадо
Подскажите, каким образом обычный пользователь может подвергнуться такой атаке? Например, посетив заражённый сайт?
Я что-то не понимаю - если файл отражен только для чтения,
зачем вообще "синхронизировать" память с диском?Ну записали в read-only страницы, но зачем эти страницы помещать в список страниц которые "грязные" и их нужно на диск скидывать?
Разве нельзя считать read-only всегда "чистыми"?
Используется уязвимость в copy-on-write с помощью незаметного нагружения всего процессора на полминуты для создания гоночек, но все админы вокруг поголовно не замечают дерзкой активности процессоров, такие дела... И никто не заметил и ничего не сделал... Всем нравится как повышают права не заметно, всего лишь загрузив на 100% проц с одного аккаунта, мы имеем пример уязвимости для котов, которые научились ставить убунту...
В OpenSUSE 42.1 прилетело обновление 4.1.34-33-default
Сабж уже не работает.
Чёт не работает на PaX:
‰ ./dirtyc0w foo m00000000000000000
mmap 8827c000madvise 0
procselfmem -100000000
Интересно, для андроида рутовалку можно на этом сделать?
Скорее да, чем нет.
Было бы превосходно
> Интересно, для андроида рутовалку можно на этом сделать?Говорят, http://forum.xda-developers.com/general/security/dirty-cow-t... можно.
Какое-то там совсем теоретическое "можно". Да, наверняка, можно перезаписать какой-нибудь бинарник. Но какой, чтобы потом какой-нибудь рутовский процесс его собственно и запустил, ни слова. (А там ещё этот SELinux сидит, сторожит.)
Тем временем там уже появились более знающие люди.
опять ребутится...
Тьфу, опять сайт сочинили, опять логотип, да когда ж уймутся уже эти пиарщики багов в открытом софте-то! Где такой же пиар для дыр в винде, где такой же пиар для дыр в макоси, где такой же пиар для дыр в разных закрытых RTOS вроде QNX/VxWorks??? Доколе?
так займись! видишь, какое поле непаханое.
Да куда уж теперь без уязвимостей. Молодцы что нашли и устранили. А если параноик то собирай и компилируй ядро сам уязвимостей будет меньше. И вообще все переходим на gentoo. Черт ногу потом сломает что и как взламывать. У каждого-же свои сборки ядра.