Исследователи из Вустерского политехнического института представили новый тип атаки Mayhem, использующий метод искажения битов в динамической оперативной памяти Rowhammer для изменения значений переменных в стеке, применяемых в программе в качестве флагов для принятия решения об успешности аутентификации и прохождения проверок безопасности. Практические примеры применения атаки продемонстрированы для обхода аутентификации в SUDO, OpenSSH и MySQL, а также для изменения результата проверок, связанных с безопасностью, в библиотеке OpenSSL...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60334
Когда я наконец увижу "Исследователи из Московского Государственного Университета представили..."? Когда?
Зачем тебе это? Величия не хватает? Так ты два телевизора одновременно смотри.
Там не пользуются Судо.
> Когда я наконец увижу "Исследователи из Московского Государственного
> Университета представили..."? Когда?"На сколько лет отстала....". Думаете, вам в РФ хоть кто-то расскажет как работают СОВРЕМЕННЫЕ компьютерные системы? Угу, щас. Ну и исследования - такие же. Да и вообще - за такую публикацию, имхо, сейчас и "госизмену" ученому схлопотать можно. Это ж вы негодяи, критичную инфраструктуру, значит, подставлять удумали?! Воооооот вам - исследования!
>>выполнение непрерывного чтения одной и той же области памяти приводит к флуктуации напряжения и аномалиям, вызывающим небольшую потерю заряда соседних ячеекДоигрались со своими уменьшениями наномеров. Теперь приходится использовать костыль, из-за которого начение, которое по идее должно было занимать один бит, теперь занимает аж четыре байта.
> Доигрались со своими уменьшениями наномеров. Теперь приходится использовать костыль,
> из-за которого начение, которое по идее должно было занимать один бит,
> теперь занимает аж четыре байта.Вообще-то rowhammer - очень фундаментальная атака, которая долбит "DRAM вообще" и совсем не факт что старый лучше нового, на DDR2/3 с довольно дубовыми нормами - работало. Без регенерации старый DRAM терял данные не хуже нового.
В DDR4 попытались костыльнуть, но вышло именно как объявление в аэропорту "пытался совершить посадку самолет номер 13". Т.е. - пытались, да. Исследователи вскоре заметили что получилось это "не очень".
> которое по идее должно было занимать один бит, теперь занимает аж четыре байта.Минимальный размер в ЦПУ = размер регистра, который в современных процессорах значительно больше чем даже 4 байта ;) И чтобы не ронять скорость, лучше оперировать размерами регистра вместо тогo чтобы потом еще AND-ить выделяя нужные биты
Именно! Например, в архитектуре x86_64 процессору удобнее работать с значениями в 64-битных целочисленных регистрах общего назначения. Но и 32-битные регистры всё ещё работают достаточно быстро.А что памяти больше занимается, так посмотрите на 64-битные указатели…
У меня вот есть смартфон, у которого 64 битный процессор, но официальная прошивка 32 битная. И порт 64 битной версии с похожего устройства работает заметно быстрее, хоть и оставляет меньше свободной озу
> А что памяти больше занимается, так посмотрите на 64-битные указатели…Ты так говоришь как будто программы только и делают что указатели перегружают. С нормальной системой команд там вообще можно адресоваться смещениями от базы, а то и прям от текущего места выполнения (при этом код position independent без жутких костылей характерных для x86-32).
А зачем вам AND'ить, если у CPU есть команды проверки-установки-сброса-инверсии бита?
> А зачем вам AND'ить, если у CPU есть команды проверки-установки-сброса-инверсии бита?Разговор не о выделении битов, а как вообще это избежать зная как устроенна хардварь... и да, AND - это классика, которую поймет любой если хоть чуть-чуть в теме и без заморочек с BMI only CPU
Ну кстати вот набивка битов тоже позволила бы этой проблемы частично избежать.
Хотя, повторюсь, проблема выеденного яйца не стоит - меньше китайского хлама, больше ECC.
Весь софт в любом случае не переписать.
> меньше китайского хламаАльтернатив однако маловато :)
> больше ECC.
https://www.vusec.net/projects/eccploit/
> Весь софт в любом случае не переписать.Ну так в новом по крайней мере меньше возможностей будет, хотя, предложенный метод ИМО хоть и будет работать, но из серии обфускации, - попытка фиксить следствие, а не причину
Ну да, три конкретных доисторических платформы с подогнанными модулями памяти в раболатории - это всё, снова ЙЕС-плоит.Кмк кто-то просто жирно троллит. Кончится тем, что в погоне за всем этим лабораторным бредом наделают реальных дыр.
> Ну да, три конкретных доисторических платформы с подогнанными модулями памяти в раболатории
> - это всё, снова ЙЕС-плоит.
> Кмк кто-то просто жирно троллит. Кончится тем, что в погоне за всем
> этим лабораторным бредом наделают реальных дыр.Современное железо это уже одна большая реальная дыра. В погоне за скоростью и снижением цены это превратилось в мусорное УГ. DRAM это апофеоз экономии: весь пойнт DRAM - "1 транзистор на ячейку" и "мизерная площадь ячейки". Но, вот, эта экономия придает специфичные свойства. Как то нужду в регенерации. Которая клищится с доступом к данным.
Странно в этом всем только то что факап заметили только сейчас. Технология древняя и даже удивительно что палочккой раньше никто не потыкал.
Если память искажается "чтением памяти", то такая память летит в топку.. И ни какие "патчи" смысла не имеют.
> Если память искажается "чтением памяти", то такая память летит в топку.. И
> ни какие "патчи" смысла не имеют.Ну, тогда мы выкинем добрую произведенной DRAM на планете, ибо DRAM без регенерации искажается by design - а вон то генерит хитрые паттерны доступа, нагибающие регенарацию памяти.
Это как хакер и солонка - разработчики DRAM не хакеры, они не подумали о том что кто-то захочет прострелить себе пятку. При том это - древний факап. Ему потенциально подвержена чуть ли не вся DRAM. На ECC вы таки заметите проблемы.
Хотя на вот конкретно моих экземплярах - ну вот не срабатывает что-то. И с ECC и без. Толи структуру контроллера не угадало, толи повезло и память даже при worst case все ж удерживает.
> Ну, тогда мы выкинем добрую произведенной DRAM на планете, ибо DRAM без регенерации искажается by design - а вон то генерит хитрые паттерны доступа, нагибающие регенарацию памяти.Да, и начнем повсеместно использовать память с ECC. Давно пора.
>> Ну, тогда мы выкинем добрую произведенной DRAM на планете, ибо DRAM без
>> регенерации искажается by design - а вон то генерит хитрые паттерны доступа,
>> нагибающие регенарацию памяти.
> Да, и начнем повсеместно использовать память с ECC. Давно пора.Если память реально уязвимая, ECC в конце концов будет пробит - ЭТО может вызывать многобитовые сбои. Которые ECC имеет право даже и не заметить вообще. А если вы как умная клава включите chip-kill, тогда вот вам ремотная DoS атака "атакующий может оставить систему вообще без оперативки".
Дело не в том, что ECC не может быть пробит. Дело в стоимости этой затеи, а также её заметности для пользователя. Если какой-то процесс начнет активно бомбить память, и с помощью ECC это заметит CPU, то об этом узнает ядро и скажет пользователю, а то и сразу прибьет процесс, пока он не натворил дел.
> Дело не в том, что ECC не может быть пробит. Дело в стоимости этой затеи,Да какая, нахрен, стоимость? Купить пятибаксовую вдску рядом? А то и вообще JS запустить почти нахаляву? Это кошмар, конечно.
> а также её заметности для пользователя.
...если он читает логи, что как показала практика, 50/50.
> Если какой-то процесс начнет активно бомбить память, и с помощью ECC это заметит
> CPU, то об этом узнает ядро и скажет пользователю, а то
> и сразу прибьет процесс, пока он не натворил дел.Красивая теория. А откуда юзер узнает какой это процесс? Более того - на хостинге с виртуалками там процессов - и вообще виртуалок - хоть джеппой жуй. А вот апгрейднуть вдску до дедика, и потом и спустившись покрыть все стадо - желающие наверное найдутся.
> Если память реально уязвимая, ECC в конце концов будет пробит - ЭТО может вызывать многобитовые сбоиПри обнаруженном многобитовом сбое ECC система останавливается.
Поэтому не заметить не удастся.
>> Если память реально уязвимая, ECC в конце концов будет пробит - ЭТО может
>> вызывать многобитовые сбои
> При обнаруженном многобитовом сбое ECC система останавливается.Вообще-то это обычно настраивается. Как и chip-kill. Ну и так то ремотная DoS атака - тоже в общем то неплохо. К тому же оно там перезагрузится и можно будет еще попробовать. Боты что, торопятся куда-то?
> Поэтому не заметить не удастся.
Ну вон там на соседнем форуме додик с цисками примерно такой, софт у него на цисках падает, видите ли, довольно часто. ИМХО - его эксплойтами гасят. Но вот что он сделает? Выключит свое счастье совем? Self destruct конечно лишает атакующих морального удовлетворения но в остальном - результат не такой уж и плохой :)
Останов при многобитном ECC обычно _не_ настраивается. Поэтому что это фатальное состояние, продолжение работы после которого невозможно.> ремотная DoS атака
Какая ремотная атака, вы о чём вообще? Для работы rowhammer - надо исполняться на той же системе.
> Ну вон там на соседнем форуме додик с цисками примерно такой, софт у него на цисках падает, видите ли, довольно часто. ИМХО - его эксплойтами гасят
Имхо, там пора таки слезть с дохлой лошади (7600), и выкинуть этот хлам в утиль, конденсаторы умерли.
// при многобитном пробитии ECC пямяти, которая умеет детект в 2 бита и коррекцию в 1.
Бывает кстати куда более хитрая память с многобитным ECC в контроллере - эту вы вообще ровхаммеро не пробьёте никак.
DDR5 вообще в принципе более хитрая.
> // при многобитном пробитии ECC пямяти, которая умеет детект в 2 бита
> и коррекцию в 1.
> Бывает кстати куда более хитрая память с многобитным ECC в контроллере -
> эту вы вообще ровхаммеро не пробьёте никак.
> DDR5 вообще в принципе более хитрая.Чувак, один тип с iXBT разок пробил все кодирование CD-ROM. Интерлив ридсоломона и что там еще. Он мувик записывал. После всех преобразований где-то в середине мувика возникала последовательность косплеящая синхрометку сектора. Большинство приводов охотно видело сектор - там где его нет - и конечно не могло это прочитать. Получился мувик который нельзя записать на CD.
...на этом фоне сказ о том что там не пробьют в DRAM или OoO хлипкоте может выдать либо оптимист, либо дилетант. Современные технологии сложные и хлипкие, а разработчики не хакеры чтобы все странные действия предусматривать. А вот исследователи - палочкой потыкают. И скорее всего найдут в оверинженернутом добре то что ищут. Оверинженерия имеет свою цену.
После слова "iXBT" мне уже страшно, это место, которое лично я в здравом уме не посещаю.То, что там синхрометка возникала - это банальный ляп в кодировании, таких ляпов в тех же флопиках был вагон и маленькая тележка без всяких ECC. Более того, эти ляпы использовались для создания защит от копирования задолго до. Такие дела.
К описываемым же дырам это вообще никакого отношения не имеет.
> Да, и начнем повсеместно использовать память с ECC. Давно пора.Ну да. У меня даже на десктопе уже лет 10 стоит память с ECC.
И даже ровхуммер тут не при чём, просто вон тот самый битврот, которым стращают адепты зфс - у него наибольший шанс произойти именно в унылой современной DRAM высокой плотности, и никакие зфс не спасут.
> Хотя на вот конкретно моих экземплярах - ну вот не срабатывает что-то.непонятно как это должно работать если auth в регистре
int auth = 0;
... // код проверки, меняющий значение auth в случае успешной аутентификации
if(auth != 0)
> то такая память летит в топку..Праздники еще не начались, а народ смотрю уже разогрелся :)
Перед тем как в топку, сперва замену неплохо бы, не?
>> то такая память летит в топку..
> Праздники еще не начались, а народ смотрю уже разогрелся :)
> Перед тем как в топку, сперва замену неплохо бы, не?Ща, он вытащит планки памяти - и поудивляется что без них почему-то не работает :)
>замену неплохо быСтатической памяти лет больше, чем динамической. Но плотность и цена...
>>замену неплохо бы
> Статической памяти лет больше, чем динамической. Но плотность и цена...Ага, а ферритовые кольца еще старее, но размер...
КольцА? Да вы задрали...
Зато их можно использовать вместо шашек!
И они классно катаются по столу))
> Зато их можно использовать вместо шашек!Да что шашки?! Ожерелья целые можно было делать!
>> Зато их можно использовать вместо шашек!
> Да что шашки?! Ожерелья целые можно было делать!Ибо сказано - девице бусы :)
Не, на опеннете так не принято. Принято взвизгнуть и ничего не делать. Вон сверху не осилившие поступить в МГУ задаются вопросом, где мгушные исследователи.))
> Не, на опеннете так не принято.К сожалению...
В МГИМО пускай идут.
Мгимо финишт обычно другой сектор обслуживают и недавно у них проблемы с трудоустройством были - работодатель поменялся.
Вот согласен.> необходимо точно исказить существенное число битов
Тут хакеру даже долго думать не надо, просто надо искажать любые биты и получится аналог ддоса. :)
После того, как суду в сотый раз не сработает, пользователь плюнет на все эти софтверные ухищрения и пойдёт искать нормальную память.
Что-то аппаратную it индустрию нагнули жестко за последние годы. Интересно, а архитектура Эльбрусов с такими же дырами?
> Что-то аппаратную it индустрию нагнули жестко за последние годы. Интересно, а архитектура
> Эльбрусов с такими же дырами?Врядли эльбрусы используют особую, уличную магию^W DRAM - где они ее возьмут?! Как максимум она с ECC окажется в лучшем случае. Но даже ECC при должном желании можно пробить, просто ор в логи будет ДО этого, из-за сбоев ECC.
> Врядли эльбрусы используют особуюВообще-то используют. Там есть отдельный стек, для адресов возврата.
Поэтому найти переменную, которую нужно "долбить" будет сложнее,
так как она лежит в стеке для переменных.
>> Врядли эльбрусы используют особую
> Вообще-то используют. Там есть отдельный стек, для адресов возврата.КМК это не помогает от искажений значений переменных в DRAM. Такая ерунда. Вон там - адреса возврата никто и не менял.
> Поэтому найти переменную, которую нужно "долбить" будет сложнее,
> так как она лежит в стеке для переменных.Учитывая что rowhammer-а даже из JS пытаются практиковать - сильно уповать на то что атакующие чего-то там не смогут найти я бы не стал.
>Что-то аппаратную it индустрию нагнули жесткоабстрагируйтесь :) они к этому шли, а вы завтра новую "память" купите, она же нынче копейки стоит.
Давно уже.У меня ноутбук (!) требует 240 ватт мощности, на официальном заряднике. И при малейшем сбое напруги (например, при саспенде), троттлит половину чипов.
При этом ему ещё 240 ватт мало, он в моменты пиковой нагрузки подтягивает мощу с батареи, то есть, без "новой" батареи и "нового" БП он вообще на проектную мощность не выходит.
Приучили всех к "экспоненциальному росту", и все всё ещё ждут его, как будто так и надо.
А он всё.
Такого понятия как "архитектура эльбрусов" не существует. Чтобы её привести в божеский вид -- её надо ещё пилить и пилить, слишком уж она сырая.
Так нехер пихать в ноутбучный корпус десктоп
При чём тут ноутбуки с десктопами?
Это малореально понять при покупке.Что значит "нехер"? Купить же можно? Можно.
Причём я купил Б/У, который за 3 года не сгорел. А что там у ноутов 2023 года выпуска, мне трудно представить.
Рахитектура ель-брусов.
такими хакерами должна заниматься полиция, а не бизнес.
если им платить за каждую чепуху - чепуха будет размножаться бесконечно.
если их вешать на сетевых кабелях - чепуха закончится вместа с хакерами.
> если их вешать на сетевых кабелях - чепуха закончится вместа с хакерами.Наврядли вы найдете столько много кабелей
А колья или бамбук? )
> А колья или бамбук? )Ну, если так будет и дальше продолжаться по всему миру, то скорее всего 4 мировая будет именно на кольях и бамбуках, но хакеры, они все равно - были, есть и будут бессмертны, как вирусы :)
бабмук подорожал
> такими хакерами должна заниматься полиция, а не бизнес.
> если им платить за каждую чепуху - чепуха будет размножаться бесконечно.
> если их вешать на сетевых кабелях - чепуха закончится вместа с хакерами.Это так не работает. В результате - вооооон там на форуме какой-то чудак плачется что цыски падают. Теперь попробуй найти того кто это ему организовал.
Блекхеты как бы в курсе что за активный дестрой и грабеж полагается - поэтому их очень сложно найти. И единственное изменение с вон того - значит white и gray hats переквалифицируются в black и будут как следует шифроваться. Тягу к знаниям это не остановит.
>Блекхеты как бы в курсе что за активный дестрой и грабеж полагается - поэтому их очень сложно найтиНайти-то легко ... для крыши. Инфраструктура есть, целая страна рабов, с пиететом выполняющая повеления Хозяина тоже есть. После чего они работают на свою крышу, и достать их могут разве что беспилотниками, и то только в случаях крайне испорченных дипотношений.
>> Блекхеты как бы в курсе что за активный дестрой и грабеж полагается - поэтому
>> их очень сложно найти
> Найти-то легко ... для крыши. Инфраструктура есть, целая страна рабов, с пиететом
> выполняющая повеления Хозяина тоже есть.Всякие мутные типы навроде кардеров, ддосеров, спамеров, "неофициальных" воротил и проч - шифруются годами, если не десятилетиями. При том в случае поимки - а ловят довольно крупные господа типа АНБ, ФБР, ЦРУ и проч, у коих ресурсы есть - в сша суд линча уже не в моде. Просто выпишут "пожизненное и 200 лет сверху". По сумме деяний.
Как это примерно выглядит если удалось отловить - загуглите скажем "ulbricht complaint". Это пример участи того кто попытался, но был туповат, нагл, и потому зафейлил маневр. Но он наверняка не единственный такой, судя по всему есть и куда более успешные.
> После чего они работают на свою крышу, и достать их могут разве что беспилотниками,
> и то только в случаях крайне испорченных дипотношений.Не понимаю откуда берется эта вера в всемогущество крыш. Как я понимаю в этом мире есть и свои фантомасы, которые могут любую крышу за нос водить. А вон тем способом можно, имхо, здорово прибавить их количество.
ИМХО это будет как-то так: исследования будут вбиты в подполье, а вулны будут продаваться на черном рынке. Сначала тому кто больше заплатит. Потом всем кто платит. Денег же много не бывает.
Что будет потом? Вот тут на форуме есть тип который удивляется что его циски - ребутаются. С какой-то ошибкой. Софта. Вот таких удивлений - заметно прибавится. И совсем не факт что "крыши" будут выкатывать самые выгодные предложения - поэтому у них будет щанс ощутить на себе атаку сперва в виде таргета, а потом может и докупить/реверснуть технологию узнав что так можно было. Но к тому моменту их инфраструктуру возможно уже разнесли - и это малость поздняк.
Поэтому крыши посообразительнее - имхо заинтересованы в легальности вон того. С одной стороны как минимум часть господ - на виду, и если прилетела совсем уж специфичная атака, по крайней мере понятно откуда начинать копать. С другой - они сразу в курсе что так можно было - ДО того как им вынесут инфраструктуру. Ну а в целом как-то так и выглядят нормальные процессы информационной безопасности, имхо.
Скажите это в лицо полиции, заодно прихватите с собой кабель, а мы поржём
We called it "Project Mayhem".
The first rule of sudo is: you do not use sudo.
The second rule of sudo is: you DO NOT USE sudo.
Ок, а что использовать?
if (auth == "прошёл проверку, а вы дальше пердольте чипы памяти") { ...И тут набигают сишники с криками о многословности.
>> if (auth == "прошёл проверку, а вы дальше пердольте чипы памяти") { ...Сишники набигут, потому что ты сравнил не содержимое строки, а всего лишь адрес указателя...
А если бы сравнивали с true, то шансы на удачное изменение стали бы существенно меньше
С чего бы? Стандарт Си (С++) говорит, что 0 - это false, а всё остальное - true. В тексте новости как раз про это сказано.
Просто не надо вредоносное ПО, написанное на JavaScript, на своей машине запускать.
Осталось ответить на простой вопрос - а как так получилось, что JS-у разрешили чистить кэши (без чего атака на память не пройдёт), и как он обходит ASLR и т.п. чтобы найти адреса целевого процесса.
Да кто ж вас спрашивает? ;)
> Для защиты от атаки Mayhem рекомендуется использовать в сравнениях
> не оценку отличий от нуля или совпадения с единицей, а проверку ...Чо париться, переходим на float?!!
Так 0 через float в памяти тоже будет представлен как 00 00 00 00.
3.14159265, где тут ноль?
> 3.14159265, где тут ноль?тут: 265
Mayhem - это блек металл!
> Для защиты от атаки Mayhem рекомендуется использовать...... флаг -O2 при компиляции.
или хотя бы msdos 2.0
Мне больше интересно, когда через пять лет будут рефакторить sudo, не найдётся ли кто-то, видящий константы:
#define AUTH_SUCCESS 0x52a2925 /* 0101001010100010100100100101 */
#define AUTH_FAILURE 0xad5d6da /* 1010110101011101011011011010 */
#define AUTH_INTR 0x69d61fc8 /* 1101001110101100001111111001000 */
#define AUTH_ERROR 0x1629e037 /* 0010110001010011110000000110111 */
#define AUTH_NONINTERACTIVE 0x1fc8d3ac /* 11111110010001101001110101100 */кто подумает "что за альтернативно одарённый это писал" и вернёт всё как было?
Буквально строчкой выше в коде написан комментарий зачем это.
И зачем же это? Соизвольте скопипастить текст этого комментария.
/* Auth function return values (rowhammer resistent). */
> кто подумает "что за альтернативно одарённый это писал" и вернёт всё как было?и совершенно правильно сделает.
Очередная псевдоатака требующая msdos 1.0 и то в лаборатории. А то можно нечаяно попасть в соседний битик и все тyпо навернется.
За дефайны вообще вон из профессии.
> За дефайны вообще вон из профессии.А что тогда вместо них использовать?
Для числовых значений сойдёт const
В C - это не тот const, который вы ищете.
> Для числовых значений сойдёт constдада, счас адепты constexpr набигут ещё. #define в умелых руках творят добрые чудеса. :D
Ну, стандарты вроде той же MISRA, наверное, станут требовать constexpr в C, когда он перестанет быть слишком новым. Для C++ там есть аналогичный пунктик (16-2-2) не использовать #define для констант.Хотя только #define и enum выражают красивую идею "подставить литерал, никогда не создавая в памяти переменную, не давая возможности сослаться на неё".
> А что тогда вместо них использовать?Надо использовать дефайны, но не забывать их ругать, чтобы не выделяться. Дело не в проблемах дефайнов, а в том, что препроцессор принято ругать. То есть на словах ругаем, на деле даже в тексте MISRA C повсюду пишем дефайны.
Предложение использовать просто const работать не будет (ключевые слова: error, multiple definitions, external linkage, const), у static const всё равно останутся неприятные ограничения, constexpr - это C23.
Надо в принципе выработать в себе презрение к макросам - например, они с трудом читаются после разворачивания (gcc -E). Поэтому в C++ надо использовать только шаблоны - там такой возможности вообще нет (презрение к когнитивному диссонансу тоже надо выработать).
А лучше выработать презрение ко всем возможностям, касающимся compile-time. У комитета оно есть, судя по срокам вокруг __VA_OPT__, consteval, (вы находитесь здесь), std::embed (#embed), рефлексии.
> А лучше выработать презрение ко всем возможностям, касающимся compile-time.И все бы это ничего - но навернувшаяся в run time с run time ошибкой управляющая фирмварь может доставить вам намного больше... седых волос... на всех частях тела... стоящих дыбом :)
...а препроцессором, внезапно, до кучи можно сделать нехилую валидацию коректности довольно много чего. И то что я сдуру 35-й бит 32-битного регистра гораздо лучше узнать при сборке проекта (да, у меня есть макро ловящее такое), чем сделать в рантайме что-то левое, или упасть с ассертом каким. Просто представь себе assertion failed в фирмвари твоего ECU на скорости 120. Как, прикольно? :)
В общем нефиг лезть с универсальными советами, случаи разные бывают. Макро юзают имея на то причины. В том числе и в мисре. А плюсота - сама по себе сложная, жирная и непредсказуемая в плане рантайм поведения.
То был сарказм на тему ограниченности compile-time возможностей и возведения препроцессора в абсолютное зло. Compile-time конкатенация строк на чистом C++ в сотню SLOC и всё такое.> А плюсота - сама по себе сложная, жирная и непредсказуемая в плане рантайм поведения.
До раста в ядре линукса это звучало даже почти убедительно. Никто не запрещает обходиться только zero cost abstraction'ами.
> То был сарказм на тему ограниченности compile-time возможностей и возведения препроцессора
> в абсолютное зло. Compile-time конкатенация строк на чистом C++ в сотню
> SLOC и всё такое.Да вооон там заполнение массива generated (предвычесленным) контентом - на гольном си. А чо, так можно было. Препроцессор даже рекурсию умеет и "почти тюринг полный" как таковой.
Просто у него свои грабли есть - на side effects и порядке/эффекте вычислений можно и налететь. Особенно если не обкладывать козла матом^W^W макросы скобками. Впрочем делать хитрож@пые вычисления прямо в вызове функций всяко не стоит, но в макросах залететь можно сильнее.
>> А плюсота - сама по себе сложная, жирная и непредсказуемая в плане рантайм поведения.
> До раста в ядре линукса это звучало даже почти убедительно.При чем тут вообще хруст? Это такой аргумент из разряда "в линукскернеле хрустиков линчуют"? Оно вообще только начинает пытаться уметь что-то такое, и имеет нехило грабель так то...
> Никто не запрещает обходиться только zero cost abstraction'ами.
Тем не менее плюсы успешно унаследовали от сей ряд бестолковостей, включая и UB и абсолютно дурацкие типы данных навроде "int", определенных ретардами из комитета, абы как. Это стоило и стоит нам всем дохреналион багов на ровном месте. Когда оказывается что int оказывается и 16 битов - валидно. А теперь попробуйте это реально можно. Вон в атмегах можно на свое горе заказать. И все по стандарту как бы. А сколько кода при этом сдуреет?! Чуть менее чем весь?
Будешь ядро сам допиливать?
Ну так се защыта
gcc -DRND1=0x$(openssl rand -hex 4) \
-DRND2=0x$(openssl rand -hex 4) \
-DRND3=0x$(openssl rand -hex 4) \
-DRND4=0x$(openssl rand -hex 4) \
-DRND5=0x$(openssl rand -hex 4) ........
#define AUTH_SUCCESS RND1 /* х.з. */
#define AUTH_FAILURE RND2 /* х.з. */
#define AUTH_INTR RND3 /* х.з. */
#define AUTH_ERROR RND4 /* х.з. */
#define AUTH_NONINTERACTIVE RND5 /* х.з. */
...
$ ./a.out
AUTH_SUCCESS = 0xb8c1fcfd
AUTH_FAILURE = 0xff828bd8
AUTH_INTR = 0xf03b903c
AUTH_ERROR = 0x4cb20a23
AUTH_NONINTERACTIVE = 0x476b545a
Тоже полумеры. Можно еще закодить random при загрузке программы.Но вся фигня в том, что всякие либы, glibc, ядро, syscall, в основном возвращают 0, 1, NULL, в лучшем случае один из errno;
ZF проца тоже 1 иль 0 )
Лучше бы ещё эти константы динамически рандомно генерировать в процессе сборки, а то могут умудриться сгенерировать нужный паттерн через уязвимость DRAM.
Кто-нибудь знает:
- как определить поддерживает ли DIMM TRR (Target Row Refresh),
- поддерживает ли этот режим контроллер памяти процессора, и
- как эту поддержку в контроллере включить если она не включена?
SME + ECC - вот что вам надо, а не костыли.
> Кто-нибудь знает:
> - как определить поддерживает ли DIMM TRR (Target Row Refresh),
> - поддерживает ли этот режим контроллер памяти процессора, и
> - как эту поддержку в контроллере включить если она не включена?Я знаю что надежнее всего - запустить rowhammer у себя на системе и посмотреть что будет :). Если упало/взвыл ECC - упс, у вас точно проблемы.
Погонял несколько вариантов rowhammer у себя на десктопе тестовых системах.
Несколько часов гонял. ECC не взвыла ни разу.
Короче, не ставьте китайский хлам в системы, и будет вам счастье.
> Кто-нибудь знает:
> - как определить поддерживает ли DIMM TRR (Target Row Refresh),# dmidecode
Если у вас есть выхлоп dmidecode в котором показано, что trr поддерживается - скиньте плз сюда.
Не, до 9 января комп с DDR4 не доступен ))
> - поддерживает ли этот режим контроллер памяти процессора, и
> - как эту поддержку в контроллере включить если она не включена?Ковыряй JESD209-4 DDR4 Spec.
DDR регистр: MR24, 7-ой операнд, если 0 - TTR выключен (по дефолту), 1 - включен.
В юзер/kernel-моде точно не включишь/выключишь,
из кода загрузчика можно попробовать. От писателей BIOS зависит.
пришли мне полную копию своего винта, я посмотрю есть ли у тебя поддержка
ЕСС и шифрование памяти на лету самим контроллером на корню решают данную проблему, что и сделал амд.Возня с правкой кода под такое - трата времени, это проблема не уровня приложения.
> ЕСС и шифрование памяти на лету самим контроллером на корню решают данную
> проблему, что и сделал амд.А точно - на корню? Скажем две одинаковые записи в 1 адрес - кодируются одинаково? Тогда можно будет немного побрутфорсить - и подогнать исходные биты так, чтобы целевые биты стали нужными. И гасить потом нужными битами от души. Записывать в память при этом придется конечно левоватые константы, чтобы оно шифровалось в нужные значения. Но подогнать 32-bit число занимает 2^32 операций максимум - и это вполне подъемная величина. Тем более что машины никуда не торопятся.
Это конечно сделает атаку немного сложнее и дольше, но вот решает ли это на корню - большой вопрос. Шифрование зачастую можно "отменить" даже не зная алгоритм и ключ, специфичный диалект chosen plaintext attack получится.
> Возня с правкой кода под такое - трата времени, это проблема не
> уровня приложения.Вообще-то приложения могут сделать это очень неудобным. Скажем - проинвертировать условие: выставить в 0 если юзеру можно зайти, а если не 0 - пшелнафиг. Т.е. if (goaway) {byebye, loser!}.
А вот пытаться rowhammer'ом спустить все биты u32 в ноль уже будет значительно менее прикольно. То что он хоть когда-то сработает именно вот так - это еще вопрос.
>> ЕСС и шифрование памяти на лету самим контроллером на корню решают данную
>> проблему, что и сделал амд.
> А точно - на корню? Скажем две одинаковые записи в 1 адрес
> - кодируются одинаково? Тогда можно будет немного побрутфорсить - и подогнать
> исходные биты так, чтобы целевые биты стали нужными.Окончил онлайн курсы пентератора? :D
Прям так взял и с разбега залез в чужое адресное пространство )))
>> - кодируются одинаково? Тогда можно будет немного побрутфорсить - и подогнать
>> исходные биты так, чтобы целевые биты стали нужными.
> Окончил онлайн курсы пентератора? :DВ каком-то роде...
> Прям так взял и с разбега залез в чужое адресное пространство )))
А зачем - в чужое? Цель - регенерацию нагнуть. Для этого надо определенные паттерны доступа. И единственное что надо - понять как в новом наборе неидеальностей спровоцировать то же самое по смыслу.
И если кто думает что такие трансформации принципиально невозможны - окей, а откуда это следует? Вон то добро и так довольно много пермутаций и что там еще DRAM контроллеров аннулирует, ну или пытается для вон того. Плюс-минус пара quirk что-то радикально меняет в правилах игры?
Меняет, потому что вам надо не случайный бит перевернуть, а вполне конкретный.
Что удаётся только в лаборатории с двумя живыми процессами - атакующим и атакуемым.
одним - второй в это время засаспенжен. Иначе ничего не получится, слишком много времени надо добить кувалдой куда попало прежде чем свершится чудо.
> Меняет, потому что вам надо не случайный бит перевернуть, а вполне конкретный.
> Что удаётся только в лаборатории с двумя живыми процессами - атакующим и атакуемым.Да вот блин, я тут пару концептуальных статей с опеннета у себя воспроизвел, так что сказать что исследователи совсем лохи... не, таки, порой дело говорят. Креативные умы свое всегда возьмут.
И да, интрудеры обычно в этом плане сильно выше среднего. Если это не совсем уж боты конечно.
Из того, что реально в живых условиях будет работать (и проверено) - это meltdown на соответствующих процах.
Там просто зияющая дыра, которая позволяет не напрягаться годами на определение одного бита.
Ещё L1TF работает, опять же, на соответствующих процах. Но там надо специфичные входные условия.
Всё остальное - это просто базз на удачной волне пока что.
SME у AMD использует AES, и наверное рандомный ключ/IV.
Потому про одинаково - сомнительно.Использование AES означает что оно работает блоками, те ты типа флипнул 1 бит в байте а поменялись все 128 бит (16 байт).
Использование SME решает проблему потому что результат становится не предсказуемым.
> SME у AMD использует AES, и наверное рандомный ключ/IV.
> Потому про одинаково - сомнительно.Тут вот какое дело... если ключ/IV рандомные - ИХ НАДО ГДЕ-ТО ХРАНИТЬ. Это лишнее место - где? Иначе как IO с этим регионом делать? И это нельзя часто менять - а как потом расшифровывать? Да еще перфоманс жмет - частая перешифровка скажем по всей площади - не вариант.
А если оно не совсем рандомное и по крайней мере постоянное при серии операций в одно и то же назначение - окей, а что помешает просто посмотреть какие значения вызовут
> Использование AES означает что оно работает блоками, те ты типа флипнул 1
> бит в байте а поменялись все 128 бит (16 байт).Да и хрен с ними, главное найти подходящий для проведения атаки паттерн на выходе. В этом смысле "подброс кубиков рандомом" может быть и не такой уж плохой вариант как кажется.
> Использование SME решает проблему потому что результат становится не предсказуемым.
С его предсказуемостью все было довольно плохо и до этого. Ну и как минимум - оно грохнется. А с вон теми проверками - а там точное значение и не надо, надо чтобы не ноль образовался. И основная проблема - в том что это довольно слабое требвоание, любой сбой ведет к "auth success", что как бы - не очень умно :D
> А точно - на корню? Скажем две одинаковые записи в 1 адрес - кодируются одинаково?Перевернёшь всю линейку кеша, она же блок шифра. Результат будет немножко "на лице".
> Перевернёшь всю линейку кеша, она же блок шифра. Результат будет немножко "на
> лице".Или не на лице. Вот как повезет. А воооон то - хотело "не ноль". Ты явно никогда не интересовался всякими извратами, типа как вооон у тех - суперкод, выполняется на нескольких разных процах сразу. Фокус в том что начальный сегмент кода должен быть "не вредным" для чужого проца. Ну и тут - кто гарантируеи что эта линейка кеша вредная или безвредная в таком аспекте? А, никто? Значит можно посмотреть не сработает ли рулетка в пользу атакующего. Он же не лично будет кубики руками подбрасывать, право?
ECC лишь усложняет атаку, но не исключает https://opennet.ru/49652-rowhammer
rowhammer скоро 10 лет исполнится, его перетpaхали все кто мог.
если у тебя Ryzen то включаешь в UEFI опцию tSME и забываешь о rowhammer навсегда
если у тебя Incel ...ну, ссзб
Мне вот только непонятно, как ПДП с этим совместим. Получается, что другой ведущий шины тоже должен шифровать/расшифровывать? А как обмен ключами с переферийными устройствами?
Этим контроллер памяти занимается, как я понял ему только ключи дают.
Другого ведущего шины уже давно нет.
Не, PCIe в теории может работать в p2p, но это редкий и почти не поддерживаемый режим.
В основном все транзакции между устройствами традиционно идут через root complex, он же CPU.
К памяти - всегда через root complex, по понятным причинам, контроллер то в CPU.
А тот уже может творить всё, что захочет.
О чень интересно почему эта проблема всплыла только сейчас. Лет 15 назад когда игрался с прогами типа Artmoney это было очевидно и работало на ура. Конечно локaлизация нужных переменных в памяти тот еще квест но решаемый.
Оно просто читало/писало память процесса, в этом ничего сложного нет.
> if(auth != 0)
> return AUTH_SUCCESS;Не понимаю — что это. Кто и каким образом определил алгоритм, при котором одно значение некорректное, а мириады других проходят проверку.
Честно - вся эта проблема выеденного яйца не стоит, и в реальных системах постороннего шума столько, что просто не сработает. Или поставит систему колом из-за многобитовой ошибки ECC, там чтобы один-то бит свернуть надо хорошо поизголяться, а чтобы более двух, да ещё и попасть в необнаружимое...
Плюс когда модулей множество - надо ещё интерлив угадывать, и там ещё несколько контроллеров может быть как у EPYC'ов, короче удачи.
Понятно, что на тестах вот только с sudo и атакующим процессором, на одном-единственном модуле памяти с нужным числом рангов и чипов, чтобы интерлив сильно не мешал, на конкретном проце и плате, имеющих конкретные характеристики, чтобы оно флипнуло - оно слегка работает. Но за этими пределами - извините.
// атакующим процессом
А учитывая, что DDR5 - уже не бесконтроллерная, и имеет встроенную не заметную для системы ECC просто из-за хреновых параметров модулей, там контроллер просто этот ровхуммер размешает с вот этим самым, и ничего не получится в принципе.
О, эксперт по технологиям памяти! Почему не существует адаптеров DDR5 -> DDR2?
> Честно - вся эта проблема выеденного яйца не стоит, и в реальных
> системах постороннего шума столько, что просто не сработает.Новость читал?
> Прототип кода для совершения атаки планируют опубликовать после
> внесения исправлений в основные уязвимые проекты."
> .... в SUDO, OpenSSH и MySQL, а также для изменения результата проверок,
> связанных с безопасностью, в библиотеке OpenSSL.
Просто посмотри исходную статью.
Там модули памяти реально приходится подбирать.
Ну и ставить поштучно.
На реальных системах всё это будет работать раз в несколько тысячелетий.
тебе хватит и одного раза в несколько тысячелетий
Я так-то ошибки ECC мониторю. Особенно со времён, когда делл впих**рил в серверы г**ноhynix, который их давал просто по факту существования, пока в фирмвари тайминги не подкрутили вниз от "штатных".
На данный момент их нет.
> Там модули памяти реально приходится подбирать.Жертвы для атак так же выбирают: есть зацепка - ломаем, нет - следующий.
> Ну и ставить поштучно.
kmalloc_node(const), cpu_affinity( const ) ... и ещё куча фишек не фрагментироваться в памяти.
C огромной вероятностью виртуальная память линейно отобразиться на физическую.
Скажите главное - раст уязвим?
да вроде нет - сколько битов в CoC.md не переворачиваю - ничего не случается.
ты там аккуратнее - можно нечайно black на white заменить и сильно заоффендить жителей другого континента.
Не пользуйтесь if'ами, только jump на результат умножения.
jmp $ - лучший вариант
Ну против Mayhem только Burzum поможет
Может ещё через ArtMoney взломаем sudo? Почему вообще у вредоносного процесса есть доступ к области памяти sudo?
Ну ладно, может нет. Он скорее всего смотрит маппинги виртуальной памяти sudo на физическую и долбит её через Rowhammer.
> Он скорее всего смотрит маппинги виртуальной памяти sudoчего в нормально спроектированной системе тоже быть в принципе не должно - но это ж линукс, не удивлюсь если с его /proc даже suid процессы не защищены
Еще один тип уязвимостей, от которых не спасают безопастные языки? Ок.