В ядре Linux выявлена (http://www.openwall.com/lists/oss-security/2017/11/30/1) критическая уязвимость (https://medium.com/bindecy/huge-dirty-cow-cve-2017-1000405-1...) (CVE-2017-1000405 (https://security-tracker.debian.org/tracker/CVE-2017-1000405)), которая манипулирует недоработкой в прошлогодних патчах, устраняющих нашумевшую уязвимость Dirty COW (https://www.opennet.ru/opennews/art.shtml?num=45354) (CVE-2016-5195), но, как оказалось, закрывающих не все векторы атаки. Проблема проявляется в ядрах с 2.6.38 по 4.14 и позволяет поднять свои привилегии в системе. Для проверки своих систем на наличие уязвимости доступен (https://github.com/bindecy/HugeDirtyCowPOC) рабочий прототип эксплоита.
Уязвимость присутствует в подсистеме управления памятью (в функции pmd_mkdirty) в реализации режима Transparent HugePage (THP). К функции touch_pmd() можно получить доступ через вызов get_user_pages() и добиться изменения содержимого PMD (Page Medium Directory) без выполнения цикла copy-on-write (COW) при попытке записи (в нормальных условиях при изменении общих страниц происходит "write fault" и для пытающегося выполнить запись процесса создаётся копия страницы памяти, в которую и вносятся изменения). В итоге, появляется возможность изменения содержимого больших страниц памяти, находящихся в режиме только для чтения, в том числе нулевой страницы виртуального адресного пространства процессов.
В отличие от уязвимости Dirty COW отсутствует возможность изменения содержимого произвольных файлов, так как в Ext4 не поддерживается маппинг обычных файлов в память с применением THP-страниц. При этом можно добиться перезаписи THP в режиме read-only, например перезаписать содержимое памяти привилегированного процесса или файлов, привязанных к разделяемой памяти (файлы в shmem могут отражаться в память с использованием THP).Проблема пока остаётся неисправленной в Debian (https://security-tracker.debian.org/tracker/CVE-2017-1000405), Ubuntu (https://usn.ubuntu.com/usn/), openSUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2017-1000405), Gentoo (https://bugs.gentoo.org/show_bug.cgi?id=CVE-2017-1000405). Обновления уже выпущены для Fedora 26 и 27 (https://bugzilla.redhat.com/show_bug.cgi?id=1519115).
Штатные ядра SUSE Linux Enterprise (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2017-1000405) и RHEL/CentOS (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-1000405) проблеме не подвержены.
Для ядра Linux подготовлен патч (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...). В качестве обходного пути защиты можно отключить THP или запретить маппинг нулевой страницы в режиме THP:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo 0 > /sys/kernel/mm/transparent_hugepage/use_zero_page
URL: http://www.openwall.com/lists/oss-security/2017/11/30/1
Новость: https://www.opennet.ru/opennews/art.shtml?num=47672
>Проблема пока остаётся неисправленной в Debian, Ubuntu, openSUSE, Gentoo.
>Обновления уже выпущены для Fedora 26 и 27.Весьма яркий пример разницы в поддержке сообществом и организацией.
убунту и сусе поддерживаются организациями
Убунтологи заняты переносом кнопок закрытия окна в другую сторону, а SUSE скорее мёртв, чем жив. Красношляпа же - мощнейший коммерческий колосс.
> Убунтологи заняты переносом кнопок закрытия окна в другую сторону, а SUSE скорее
> мёртв, чем жив. Красношляпа же - мощнейший коммерческий колосс.если первоисточник меня не обманывает - они как-то прошли мимо предыдущего фикса (не очень понятно, как, и некогда рыться в гите) и только по этой причине не унаследовали от него проблему.
при этом в разрекламированной красношляпе для arm64 ведро поновее и проблема в наличии. Исправления - пишуть.
так что нам не хватает в этом празднике энтерпрайзов Миши с заявлением что "кто говорил что в альте ядро 2.6.14 слишком старое?!"
;-)
> так что нам не хватает в этом празднике энтерпрайзов Миши с заявлением
> что "кто говорил что в альте ядро 2.6.14 слишком старое?!" ;-)В вариации "кто говорил, что 2.6.33 для e2k слишком старое", ага :-]
МЦСТ, когда скорей-скорей выкатывали 3.14, не?
> В вариации "кто говорил, что 2.6.33 для e2k слишком старое", ага :-]Окаменелости даже зараза не берет.
а, у suse забавнее - "мы и сами нифига не помним, почему не втянули тот фикс - кажется, там что-то ломалось в s390 ? Да и хрен с ним, кому оно надо, это ведро 3.0!"
> SUSE скорее мёртв, чем живАргументы будут?
>> SUSE скорее мёртв, чем жив
> Аргументы будут?Вы слишком многого требуете от набросчика.
Конечно, причём в стиле "от обоснуя слышу". :)
Лол. То есть организации, которые поддерживают хуже сообщества -- это не организации? При такой методологии проведения исследования можно даже не проводить исследования кто лучше поддерживает, конечный ответ вытекает непосредственно из этой методологии и никак не связан причинно-следственными связями с реальностью.
>SUSE скорее мёртв, чем жив.После пробы более десятка дистрибутивов я пришол к выводу шо openSUSE наиболее наближеная к совершенству ОС. Все остальные в роли доганяющего.
Не знаю чо так мало людей ее используют...
SUSE все хоронят и хоронят, а она прямо как птица Феникс из пепла...
Как упырь из могилы, ты хотел сказать
и чо, много твоей крови всосала?По мне так какой там упырь, лежит себе в гробу, изредка ворочается и чешется, по ночам не воет...
А жаль. (для вас исполняется композиция Armata strigoi, хотя они, наверное, все же имели в виду волколаков, а не традиционных упырей)
Это типичный пример построения теории на единичном факте.
Нет, это яркий пример так называемого вранья.
Поддерживаю! Весьма яркий пример, кто занимается действительно поддержкой и развитием, а кто это только имитирует.
Толсто.
> Весьма яркий пример разницы в поддержке сообществом и организацией.Тебе троян это доброе сообщество вкорячит, а ты и писаешься от щастья,
что апдейты через минуту после обнаружения дыры :D
>>Проблема пока остаётся неисправленной в Debian, Ubuntu, openSUSE, Gentoo.
>>Обновления уже выпущены для Fedora 26 и 27.
> Весьма яркий пример разницы в поддержке сообществом и организацией.Поясни, скачать патч с Гитхаба и выкатить без тестирования это чей подход?
Это типичный пример построения теории на единичном факте.
> Это типичный пример построения теории на единичном факте.Ты про свой первый комент?
Нетривиальный патч, вмерженный в stable через полтора дня тестирования двумя с половиной анонимами?Ну, не знаю, в чем тут пример. :-)
У кого-нибудь оно вообще работает? Изрядно нагружает процессор, разгоняет кулер до верхних оборотов, жрёт гиг оперативки. И всё. Ubuntu 16.04, ядро 4.10.0-40-generic. Через десять минут прибил, т.к. надоело.
> У кого-нибудь оно вообще работает? Изрядно нагружает процессор, разгоняет кулер до верхних
> оборотов, жрёт гиг оперативки. И всё. Ubuntu 16.04, ядро 4.10.0-40-generic. Через
> десять минут прибил, т.к. надоело.while (true) do ./exploit &; done;
да, slackware-current:...
[*] Done 0x1fd000 bytes
[*] Done 0x1fe000 bytes
[*] Done 0x1ff000 bytes
[*] Done 0x200000 bytes
[*] Success!
...
Скажи мне, друг, почему в -current Патрик сначала впихнул 4.14.[1,2], а сегодня обратно 4.9?
Неисповедимы пути Его.
https://www.linuxquestions.org/questions/slackware-14/strang...
>Скажи мне, друг, почему в -current Патрик сначала впихнул 4.14.[1,2], а сегодня обратно 4.9?Патамушто он бох.
> Скажи мне, друг, почему в -current Патрик сначала впихнул 4.14.[1,2], а сегодня
> обратно 4.9?У патрика отпала какая-нибудь железка. Он офигел и вернул как было.
Прототип эксплоита написал success, и после него система стала работать нестабильно, некоторые проги стали вылетать на ровном месте, пришлось перезагружаться; аккуратнее там с экспериментами
После запуска экспоита ядра, который попытался это самое ядро хакнуть, система стала работать нестабильно? Не может такого быть, я не верю!Ну и анонимы пошли...
Не всякий хак обязан нарушать стабильность ядра.
> Не всякий хак обязан нарушать стабильность ядра.Зато грамотно скормленный неудачникам эксплойт может повесить довольно стабильный бэкдор, как это делал эксплойт от AcidBitchez.
> Прототип эксплоита написал success, и после него система стала работать нестабильно, некоторые
> проги стали вылетать на ровном месте, пришлось перезагружаться; аккуратнее там с
> экспериментамиНа будущее научись запускать эксплойты в виртуалке, чудак. Даже если она и упадет, невелика потеря. В каждом линуксе KVM встроен, так что неумению пользоваться виртуалками у линуксоида нет прощения.
> На будущее научись запускать эксплойты в виртуалке, чудак. Даже если она иэмм.. я бы вот на вашем месте не был так уверен в надежности kvm ;-)
(в моем не встроен, что я делаю не так?)
> эмм.. я бы вот на вашем месте не был так уверен в надежности kvm ;-)Эксплойты пробивающие KVM на KVM проверять разумеется не стоит. Хотя с nested virtualization можно попробовать. Но если матрица все-же завалится, вас предупреждали.
> (в моем не встроен, что я делаю не так?)
Являешься неисправимым ретардом с бсдшным или солярочным бэкграундом, переклиненым на контрпродуктивной упертости. Уж прости за честность, но твой профессионализм по заточке каменных топоров из тебя так и прет. Я же советовал человеку, который возможно подозревает что уже изобрели электропилы. А если не подозревает - вот, информируем, что с каменным топором можно уже и не сношаться, как некоторые.
> Эксплойты пробивающие KVM на KVM проверять разумеется не стоит.а откуда ты знаешь, что тебе там не два сразу завернули? ;-) Шелл-код-то проверял, прогрессивный ты наш?
Вот и получается, что считаешь себя грамотным и прогрессивным, а на деле - ничем не отличаешься от товарища, запустившего эксплойт прямо на домашнем десктопе. Или хуже него - потому что он-то сейчас ресет ткнет, и как с гуся вода, а ты без колебаний запустишь подобное нечто на рабочей системе с рабочими виртуалками - даже не подумав, что в случае чего - хрен потом поймаешь разбегающуюся вирусню. "Мне ж сказали что оно содержит эксплойт только для одного ядра, я и ведусь".
> а откуда ты знаешь, что тебе там не два сразу завернули? ;-)Это будет заметно по куче логики.
> Шелл-код-то проверял, прогрессивный ты наш?
Вот в конкретно этом эксплойте шелкода вообще нет, мистер эксперт.
> и как с гуся вода, а ты без колебаний запустишь подобное
> нечто на рабочей системе с рабочими виртуалками - даже не подумав,
> что в случае чего - хрен потом поймаешь разбегающуюся вирусню.Ага, на тестовом компе, где файлуха заснапшочена и при малейшем подозрении будет откачена. С парой уровней виртуализации, так что оно даже и не поймет когда и куда прорубилось. А встраивать искуственный интеллект в мелкий кусочек асма с кучей ограничений - несколько напряжно. О чем ты бы мог и догадаться, если бы хоть иногда пользовался мозгом по назначению.
> "Мне ж сказали что оно содержит эксплойт только для одного ядра, я и ведусь".
Несомненно, там мощный искусственный интеллект, который не сломается на довольно нестандартной конфигурации и обойдет все капканы и сюрпризы. Нисколько не сомневаюсь.
> Ага, на тестовом компе, где файлуха заснапшочена и при малейшем подозрении будет откачена.утипусеньки, какие мы осторожные и предусмотрительные... а откатим - вместе с данными, да? А, ну да, там же нет данных... только зачем тогда ждать подозрений? (они могут позновато появиться, ага)
> С парой уровней виртуализации
и еще сверху надет презерватив.
Но при этом мы считаем себя охрененными экспертами и смеемся над людьми, которые просто запустили всю хрень у себя на локалхосте, без лишней паранойи и без, надо заметить, большого риска.
> утипусеньки, какие мы осторожные и предусмотрительные... а откатим - вместе с данными, да?Утипусиньки, на тестовой машине не то чтобы много ценных данных. И они в отдельных btrfs subvolume валяются, вне системных дел, поэтому не откатятся.
> А, ну да, там же нет данных... только зачем тогда
> ждать подозрений? (они могут позновато появиться, ага)Там бывают данные, но не ценные и transient по природе своей. И даже для них отдельные снапшоты, если надо.
> и еще сверху надет презерватив.
Знаешь, лаборанты когда имеют дело с серьезной инфекцией и прочей отравой не брезгуют надеть как минимум двое перчаток. Элементарная техника безопасности.
> Но при этом мы считаем себя охрененными экспертами и смеемся над людьми,
> которые просто запустили всю хрень у себя на локалхосте, без лишней
> паранойи и без, надо заметить, большого риска.Небольшой такой риск, всего лишь память кернела превратилась в труху. Правда что будет дальше никто не знает. Запишется труха в структуру файлухи - и удачных вам приключений с хексэдитором и море радости от немного (или много)побитых файлов.
Экспериментировать с концептом эксплоита на живой системе, а не в виртуалочке... ну удачи, чо :)
бубунта 16.04.3 LTS, 4.10.0-40-generic :...
[*] Done 0x1fd000 bytes
[*] Done 0x1fe000 bytes
[*] Done 0x1ff000 bytes
[*] Done 0x200000 bytes
[*] Success!
...
"security problems are just bugs"Продолжай повторять это как мантру, Линус!
> "security problems are just bugs"А что, разве не так? Образцовая ошибка в логике работы фичи.
В некоторых случаях так это вообще фича. Только представь себе, сколько народа сейчас получит рут на андроидах, не спрашивая ослиного позволения всяких копирасов :)
Нисколько. Все кто хотел, давно уже воспользовались предыдущими.
> Нисколько. Все кто хотел, давно уже воспользовались предыдущими.Думаешь, с тех пор продали 0 устройств и никто не выпустил секурити фиксы? Маловероятно.
>> "security problems are just bugs"
> А что, разве не так? Образцовая ошибка в логике работы фичи.Нет, это не так. Вот ЭТОГО:
"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")."быть не должно, как мне кажется.
> В некоторых случаях так это вообще фича. Только представь себе, сколько народа
> сейчас получит рут на андроидах, не спрашивая ослиного позволения всяких копирасов
> :)Круто, если какие-то хорошие люди получат от этой дыры сиюминутную выгоду. Но, как мне кажется, это не отменяет того, что имеет место проблема: неправильная политика по отношению к уязвимостям со стороны разработчиков ведра.
А то, что андроидов понарутают - да ради бога, кто ж против. Всё равно через год-полтора-два понесут на помойку и купят новый сверкающий зонд (как обычно, поначалу без рута, ага) - какое счастье быть потребителем!
> Круто, если какие-то хорошие люди получат от этой дыры сиюминутную выгоду. Но,
> как мне кажется, это не отменяет того, что имеет место проблема:Зато остальные как раз пропатчатся в темпе вальса. А кто будет хлопать ушами, станет источником сиюминутной выгоды. И не сказать что это Торвальдс придумал или кто там еще.
Для генты еще предстоит скомпилировать?)
ждем ебилда!
ты точно гентушник?
Калько-юзер.
> Калько-юзер.Т.е. у тебя ненастоящая, надувная-резиновая гента?
только закончил компилировать
Да
> В отличие от уязвимости Dirty COW отсутствует возможность изменения содержимого произвольных файлов, так как в Ext4 не поддерживаетсяДАНИФИГАЖСЕБЕТО, а Ext4-то это ведь у нас единственная файловая система в линуксе, и все пользуются только ею. Поэтому если в ней что-то не поддерживается, ну значит можно выдохнуть спокойно, "возможность отсутствует" сразу везде и для всех.
Ubuntu 16.04.3 LTSLinux laptop 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
...
[*] Done 0x1fd000 bytes
[*] Done 0x1fe000 bytes
[*] Done 0x1ff000 bytes
[*] Done 0x200000 bytes
[*] Success!ubuntu дырка.
С таким подходом к безопасности как у Линуса, неудивительно что подобные баги вылезают
И что у него с безопасностью ?
Взаимная ненависть.
Сейчас дособирается новая версия 4.14.3.а-1 ядра linux-hardened-apparmor, на нём и протестирую эксплоит.
Дяденька, ты идиот? Фикс вышел 26 ноября, чо ты тестить собрался? :D
Дебиан без возни с конфигами:Linux wst_copy 4.9.0-3-686-pae #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) i686 GNU/Linux
Не пашет :-) Ну и /sys/kernel/mm/transparent_hugepage/enabled стоит в never по дефолту
> Дебиан без возни с конфигами:
> Linux wst_copy 4.9.0-3-686-pae #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) i686 GNU/Linux
> Не пашет :-) Ну и /sys/kernel/mm/transparent_hugepage/enabled стоит в never по дефолтуА ты подыми сервак со 100 вируалками без MADVISE/ALWAYS transparent_hugepage
Да даже если так, то эксплойт, в том виде, в котором он существует сейчас никуда не годится. Уже пол-часа пытается пройти этот цикл в 200,000 этираций при этом нагружая всю систему.
Жизнь script-kiddy сложна и не выносима, експлоеты ещё надо затачивать под жертву...
Нивазможна работать.
Ты про того, кто написал эту программу? Я в ней сильно не разбирался, хотел свою систему проверить, но понял, что даже если кто-то умудрится у меня её выполнить, то ничего не добьётся даже на непропатченом, ванильном Дебьяновском ядре. Можно спать спокойно и пожовывая попкорн смотреть как возгорает.
> Ты про того, кто написал эту программу?Там частный, но популярный случай, однозначная работа зависит от того как часто проц лезет в L2/L3 кэш.
У мня в этом примере треды взаимно блокируются на madvise
1) С ним тоже не пашет, если не ясно из моего сообщения выше
2) 32 бита - какие 100 виртуалок?
> 1) С ним тоже не пашет, если не ясно из моего сообщения выше
> 2) 32 бита - какие 100 виртуалок?А накой ляд те на 32 битах новые ядра. 3.2.16 хватит на всё.
> А ты подыми сервак со 100 вируалками без MADVISE/ALWAYS transparent_hugepageВсе мы знаем что вирус сначала надо скачать, скомпилировать, запустить под рутом, и вот тогда может быть получится гордиться тем что теперь и у тебя вирусы есть.
>> А ты подыми сервак со 100 вируалками без MADVISE/ALWAYS transparent_hugepage
> ... гордиться тем что теперь и у тебя вирусы есть.Гордиться надо тем, что есть собранное ядро без HUGE_PAGES.
КПД это этой фичи,только тоговцам кластерами. Ну или компик с 128Гб оперативки и
запущенным десятком виртуалок иль MySQL гоняет BLOBы по оптоволокну.
У меня на десктопе довольно много виртуалок. Так прикольнее. Сейчас мы эту шматрицу запатчим...
> У меня на десктопе довольно много виртуалок. Так прикольнее. Сейчас мы эту
> шматрицу запатчим...MADVISE, KSM и пр. попытки дедупов эффективны при работе 2-х и более КЛОНОВ!
Если одна виртуалка Генту, вторая Free БДСM, Винтуз 10, ... то не знаю, что там общего :)
> Если одна виртуалка Генту, вторая Free БДСM, Винтуз 10, ...
> то не знаю, что там общего :)hosts? :]
> MADVISE, KSM и пр. попытки дедупов эффективны при работе 2-х и более КЛОНОВ!Мне бзды с десятками и не требуются.
А если почитать здесь: https://wiki.debian.org/Hugepages то
> Standard Debian Kernel have HUGETLB enabledА эксплойт таки не работает всё-равно.
Странно, что у тебя в never по дефолту, у меня madvise. Но, подтверждаю, не фурычит.
Особенности 32-битного ядра? разбираться не с руки сейчас, да и смысла нет
> Особенности 32-битного ядра?Можно и 32 бита, но смысл стремиться к нулю
Нужно было написать ядро на Rust.
Завсегда можно переписать
https://github.com/redox-os/redox
ужо написано.
> MicrokernelНифига подобного.
> # CONFIG_TRANSPARENT_HUGEPAGE is not setИ проблемы нет :)
> CONFIG_TRANSPARENT_HUGEPAGE:
>
> Transparent Hugepages allows the kernel to use huge pages and
> huge tlb transparently to the applications whenever possible.
> This feature can improve computing performance to certain
> applications by speeding up page faults during memory
> allocation, by reducing the number of tlb misses and by speeding
> up the pagetable walking.
>
> If memory constrained on embedded, you may want to say N.Эта фича нужна исключительно для жирного софта написанного на java :)
А еще для виртуалок (
> Проблема проявляется в ядрах с 2.6.38 по 4.14…Весело, конечно.
Обновляться с 2.6.18 и 2.6.32, похоже, всё ещё «пока рано».
Ты уже перешел с 2.4?! Чертов авангардизм...
> Ты уже перешел с 2.4?! Чертов авангардизм...:)
я думал этот эксплоит рут дает, а он всего лишь success пишет.
> я думал этот эксплоит рут дает, а он всего лишь success пишет.dirty cow тоже рут не даёт. Чтобы его раскрутить до рута на ведре народ конкретно за364лся с двумя перезагрузками и патчингом рекавери.
интересно, в ГосЛинуксе исправили?
>Штатные ядра RHEL/CentOS проблеме не подвержены.