Comments 31
Сложно назвать это уязвимостью.
Предсказать адреса доступные из user-mode которые мапятся физически рядом с целевым адресом практически невозможно.
Предсказать адреса доступные из user-mode которые мапятся физически рядом с целевым адресом практически невозможно.
Это вполне такая реализуемыая DoS-атака. Представьте себе: облачный сервис, кто-то особо вредный арендовал машину и херачит вот такую штуку, а у других клиентов то софт падает, то данные портятся ни с того, ни с сего.
Линейки не слишком болшие, к примеру для 8Gb-плашки это 12бит на адрес колонки, то есть 512байт в строке.
Уязвимы лишь соседние строки. При этом память адресуется по-странично, причём страница как минимум в несколько раз больше строки.
То есть всё же вероятность того что 2 соседних строки принадлежат разным приложениям/виртуальным машинам очень и очень мала.
Уязвимы лишь соседние строки. При этом память адресуется по-странично, причём страница как минимум в несколько раз больше строки.
То есть всё же вероятность того что 2 соседних строки принадлежат разным приложениям/виртуальным машинам очень и очень мала.
Достаточно поменять адрес доступный из user-mode для чтения. Например libc.so которая замаплена в множество рутовых процессов.
А что это меняает?
То есть менять саму libc не получится, так как как минимум copy-on-write.
Поэтому нужно найти адрес который будет лежать прямо перед либо после libc.
С учётом того что я думаю что libc мапится в начале загрузки системы, то физически она расположена достаточно рано, и вероятность того что доступная нашему процессу память будет рядом с ним — ничтожна.
То есть менять саму libc не получится, так как как минимум copy-on-write.
Поэтому нужно найти адрес который будет лежать прямо перед либо после libc.
С учётом того что я думаю что libc мапится в начале загрузки системы, то физически она расположена достаточно рано, и вероятность того что доступная нашему процессу память будет рядом с ним — ничтожна.
Код на запись обычно не доступен совсем. Даже если бы в libc можно было писать и она была copy-on-write, это бы не помогло. Процессор ничего про copy-on-write не знает. Копирование выполняет операционная система, которая перехватывает исключение возникающее при попытке записи в память доступную только для чтения. Если же память изменяется при чтении, то никакого исключения и как следствие копирования не будет.
Собственно я об этом и написал, возможно не так четко. но «менять саму libc не получится».
В физической памяти находится только одна копия libc, libc изменяется, никаких копирований не происходит -> «значит менять саму libc не получится». Странная у вас логика.
Довольно простая.
«так как как минимум copy-on-write» => наименее строгое правило работы с памятью библиотек — это copy-on-write, остальные принципы еще более строги, поэтому смотрим на наиболее благоприятный для эксплуатации copy-on-write => модифицировать оригинальный libc, доступный остальным рутовым процессам не получится, так как страница памяти будет скопирована в АП процесса, который выполняет данную модификацию, и не затронет общие страницы libc.
В каком месте я утверждаю что есть несколько libc?
«так как как минимум copy-on-write» => наименее строгое правило работы с памятью библиотек — это copy-on-write, остальные принципы еще более строги, поэтому смотрим на наиболее благоприятный для эксплуатации copy-on-write => модифицировать оригинальный libc, доступный остальным рутовым процессам не получится, так как страница памяти будет скопирована в АП процесса, который выполняет данную модификацию, и не затронет общие страницы libc.
В каком месте я утверждаю что есть несколько libc?
Еще раз.
1. Есть только одна копия libc.
2. Процесс увидит как libc изменяется.
3. Никакого копирования не будет ни для read-only, ни для copy-on-write памяти:
1. Есть только одна копия libc.
2. Процесс увидит как libc изменяется.
3. Никакого копирования не будет ни для read-only, ни для copy-on-write памяти:
Код на запись обычно не доступен совсем. Даже если бы в libc можно было писать и она была copy-on-write, это бы не помогло. Процессор ничего про copy-on-write не знает. Копирование выполняет операционная система, которая перехватывает исключение возникающее при попытке записи в память доступную только для чтения. Если же память изменяется при чтении, то никакого исключения и как следствие копирования не будет.
В компьютере еще полно таких наводок. Поэтому и введены контрольные суммы… Не думаю, что производителям интересно их исправлять — они гонят версии и набивают карманы, а не улучшают железо…
Теоретически возможно, но есть вещи которые они просто утаили и эти моменты делают атаку не возможной на реальной системе:
1 Для тестов они использовали FPGA контроллер Xilinx, а не релаьный контроллер используемый в ПК.
2 Не учитывают что не одни они используют оперативную память. Т.е. даже если у вас однопроцессорная система, в ней должны быть отключены DMA и все другие потребители способны самостоятельно обращаться к памяти.
3 Забыли про механизм регенерации. Если self-refresh включен, то можно про атаку так же смело забыть.
1 Для тестов они использовали FPGA контроллер Xilinx, а не релаьный контроллер используемый в ПК.
2 Не учитывают что не одни они используют оперативную память. Т.е. даже если у вас однопроцессорная система, в ней должны быть отключены DMA и все другие потребители способны самостоятельно обращаться к памяти.
3 Забыли про механизм регенерации. Если self-refresh включен, то можно про атаку так же смело забыть.
Если честно, то бред. Редкостный бред.
Т.е. эти граждане утверждают, что из памяти при простом непрерывном чтении периодически читаются невалидные данные? При этом тестами это не обнаруживается?
Собственно, каждый сам подумать, на сколько он в это верит.
И ещё одинм факт — нормальные тесты полностью отключают кэширование при тесте. Даже не нужно кэш каждый раз сбрасывать! Странно, что они об этом не знают. А чтобы исполняемый код на память не влиял, код и стек «защёлкиваются» в кэше процессора.
И естественно, что тесты гоняют паттерны, которые подобные проблемы выявляют.
И очевидно, что тесты ничего подобного на нормальной памяти не выявляют.
Т.к. тайминги устанавливаются с учётом подобный эффектов и цикл регенерации, очевидно выбирается из предположения, что вообще непрерывно идут обращения.
А описываемый эффект достижим, но только нужно тайминги неправильные выставить, что в реальности может быть лишь в случае бракованной памяти или ошибки в BIOS. Не зря они это на FPGA гоняют.
И, кстати, в случае наличия присутствия эффекта легко лечится уменьшением периода регенерации.
А с неправильными таймингами и не такие чудеса возможны.
Т.е. эти граждане утверждают, что из памяти при простом непрерывном чтении периодически читаются невалидные данные? При этом тестами это не обнаруживается?
Собственно, каждый сам подумать, на сколько он в это верит.
И ещё одинм факт — нормальные тесты полностью отключают кэширование при тесте. Даже не нужно кэш каждый раз сбрасывать! Странно, что они об этом не знают. А чтобы исполняемый код на память не влиял, код и стек «защёлкиваются» в кэше процессора.
И естественно, что тесты гоняют паттерны, которые подобные проблемы выявляют.
И очевидно, что тесты ничего подобного на нормальной памяти не выявляют.
Т.к. тайминги устанавливаются с учётом подобный эффектов и цикл регенерации, очевидно выбирается из предположения, что вообще непрерывно идут обращения.
А описываемый эффект достижим, но только нужно тайминги неправильные выставить, что в реальности может быть лишь в случае бракованной памяти или ошибки в BIOS. Не зря они это на FPGA гоняют.
И, кстати, в случае наличия присутствия эффекта легко лечится уменьшением периода регенерации.
А с неправильными таймингами и не такие чудеса возможны.
Очень сильно напоминает атаки по ошибкам вычислений (Fault attacks, краткое описание в pdf), просто в данном случае ошибка вводится в память. С помощью ошибок можно изменить данные регистров, пропустить функции, да и вообще натворить множество интересных вещей. Мне нравится эта работа лишь тем, что для ввода ошибок они не используют дополнительного оборудования.
Может это и не уязвимость — но что это полный пэ, так это точно. Не должна прикладная программа иметь доступ к таким вещам, как организация памяти. Я даже не понимаю: а как-то скорректировать это, не переходя на статическую память, возможно?
Да, проблема реальная и очень нехорошая — из-за того, что фикс в старых системах, может быть только за счет очень сильной потери по производительности.
Фикс на стороне контроллера уже придуман и запатентован, так что в новых системах на основе процессоров Интел — все по идее должно быть хорошо.
www.google.com/patents/US20140006704
www.google.com/patents/US20140095780
www.google.com/patents/WO2014004748A1
Фикс на стороне контроллера уже придуман и запатентован, так что в новых системах на основе процессоров Интел — все по идее должно быть хорошо.
www.google.com/patents/US20140006704
www.google.com/patents/US20140095780
www.google.com/patents/WO2014004748A1
Вот и вся разгадка теории о влиянии космических лучей на оборудование…
Что то не фига не получается на КР565РУ5Г повторить.
Написал userspace тестер, Кушает память — так надо.
На моем домашнем серваке i3+DDR3 4 гига одной планкой. Память гарантированно портится до 12-13 итерации.
На моем домашнем серваке i3+DDR3 4 гига одной планкой. Память гарантированно портится до 12-13 итерации.
Собирал с дефолтовыми ключами.
По идее чтобы из юзерспейса замаллочить непрерывный кусок памяти в пределах одной микросхемы нужно чтобы луна была в 3ей четверти, марс в скорпионе и память не слишком фрагметированна. Я вообще удивлен что у меня срабатывает иногда.
У меня это выглядит обычно так… Хотя 1 раз было что все 32 пасса прошли без ошибок. Тут нужна определенная долявезения невезения.
root@slon-P5Q:~/WORK/tandemx# ./a.out
#0… OK
#1… OK
#2… OK
#3… OK
#4… OK
#5… DRAM CRC FAIL! ;-)
root@slon-P5Q:~/WORK/tandemx#./a.out
#0… OK
#1… DRAM CRC FAIL! ;-)
root@slon-P5Q:~/WORK/tandemx#./a.out
#0… DRAM CRC FAIL! ;-)
По идее чтобы из юзерспейса замаллочить непрерывный кусок памяти в пределах одной микросхемы нужно чтобы луна была в 3ей четверти, марс в скорпионе и память не слишком фрагметированна. Я вообще удивлен что у меня срабатывает иногда.
У меня это выглядит обычно так… Хотя 1 раз было что все 32 пасса прошли без ошибок. Тут нужна определенная доля
root@slon-P5Q:~/WORK/tandemx# ./a.out
#0… OK
#1… OK
#2… OK
#3… OK
#4… OK
#5… DRAM CRC FAIL! ;-)
root@slon-P5Q:~/WORK/tandemx#./a.out
#0… OK
#1… DRAM CRC FAIL! ;-)
root@slon-P5Q:~/WORK/tandemx#./a.out
#0… DRAM CRC FAIL! ;-)
Sign up to leave a comment.
«Железная» уязвимость в DRAM позволяет изменить содержимое чужой памяти