Группа исследователей из Амстердамского свободного университета (https://ru.wikipedia.org/wiki/%D0%90%D0%... разработала новую технику атаки (http://www.cs.vu.nl/~kaveh/pubs/pdf/ffs-usenixsec16.pdf)&nbs... (Flip Feng Shui), позволяющую добиться изменения содержимого памяти чужих виртуальных машин. Продемонстрированы два успешных примера осуществления атак. Первая атака позволяет изменить (https://www.youtube.com/watch?v=TqWmP2owbdo) значение отдельных битов RSA-ключа OpenSSH или GnuPG в чужой виртуальной машине. Вторая атака приводит к изменению (https://www.youtube.com/watch?v=cs7xDkBG7_4) URL пакетов, загружаемых через apt-get и позволяет добиться установки стороннего deb-пакета в Ubuntu и Debian.В основе атаки лежит проявляющаяся в современных чипах памяти DRAM уязвимость RowHammer (https://www.opennet.dev/opennews/art.shtml?num=41340), позволяющая исказить содержимое отдельных битов памяти путём цикличного чтения данных из соседних ячеек памяти. Так как память DRAM представляет собой двухмерный массив ячеек, каждая из которых состоит из конденсатора и транзистора, выполнение непрерывного чтения одной и той же области памяти приводит к флуктуации напряжения и аномалиям, вызывающим небольшую потерю заряда соседних ячеек. Если интенсивность чтения достаточно большая, то ячейка может потерять достаточно большой объём заряда и очередной цикл регенерации не успеет восстановить его первоначальное состояние, что приведёт к изменению значения сохранённых в ячейке данных.
Арендовав виртуальную машину на том же физическом сервере, что и виртуальная машина жертвы, атакующие могут воспользоваться тем, что в процессе дедупликации, идентичные страницы памяти разных виртуальных машин отражаются в одну область физической памяти. Например, при запуске в разных виртуальных машинах идентичных операционных систем, многие доступные на чтение компоненты данных ОС будут размещены в ОЗУ в виде одной физической копии, отзеркаленной в разные виртуальные машины. Применения метода RowHammer для таких дедуплицированных областей позволяет атакующим внести искажения в совместно используемые области памяти.URL: https://thestack.com/cloud/2016/08/12/cloud-hacking-trick-al.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=44968
Прелестно! (ц)
> Прелестно! (ц)Копро экономика в действии. Память стала дешевой, не правда ли?
> Копро экономика в действии. Память стала дешевой, не правда ли?Компьютер в каждом доме! Какой скандал!
Ты дурачек который не осилил новость но сказать что то хочется?Проблема отчасти в том что памяти не хватает и приходится мутить дедуплекацию.
> Прелестно! (ц)Что тебе прелестно?
Ты первый будешь сдавать все местные логи от первого нуля до последнего по первому требованию "партии". Ты ведь именно этим здесь уже сейчас занимаешься.
Можно подумать, у вас не летят сдавать по легкому мановению волосатой руки вашингтонского обкома.
> Ты первый будешь сдавать все местные логи от первого нуля до последнего
> по первому требованию "партии". Ты ведь именно этим здесь уже сейчас
> занимаешься.Посмотрите, люди. Вот так выглядит типовой лжец: пишет, но подтвердить не сможет.
По самой простой причине -- нет у меня "местных логов".Впрочем, чего взять с учащегося у западных истеричек...
> Прелестно! (ц)Миша, уж тебе то пора знать про отличие регистровой памяти и драма,в отличии от твоих местных клоунов.
Ну и таки да - клиенты хезнера и прочих "ит-сарай" все равно интереса не представляют.
>> Прелестно! (ц)
> Миша, уж тебе то пора знать про отличие регистровой памяти и драмаТак всё равно ж прелестно. В комплексе с TTM, WiB и прочими факторами, разумеется...
Как трудно жить. (ц)
Ц (ц)
Ц*Ц=Щ
Отсюда мораль: используйте нестандартные компоненты, чтобы их не дедуплицировали.Пример: если вы раскатаете debian testing с самосборным ядром, дедуплицировано будет заметно меньше чем если вы возьмете стандартный образ ubuntu 16.04 LTS. И атака превратится в конкретный ребус, особенно если попрятать баннеры с версиями и проч.
Одни шпиёны вокруг. Думаете, скроете свою порнуху с понями от Путина? Неее, он всё видит!
Что ещё раз доказывает, что виртуализация и безопасность рядом не лежали. Нужна безопасность => используй разное железо для каждой задачи. ARM микросерверы здесь неплохо смотрятся.
Обход защиты вирутализации - всего лишь пример использования. Уязвимость существует в самом железе, что есть опасным для любой машины.
> Обход защиты вирутализации - всего лишь пример использования. Уязвимость существует в самом
> железе, что есть опасным для любой машины.На собственном микросервере чужой код извне можно совсем не запускать. Вектор проведения атаки отваливается.
А бункер ты уже построил? А посадил там под землёй дерево? А вырастил ли своих подземных детей?
Когда твой сервак поломают и заставят тебя несколько суток разбираться с проблемой, особенно в самый неподходящий момент, тогда и послушаем твои шуточки про подземные деревья и подземных детей
Маладой человек когда 15 лет назад, я сказал заказчику что надо к ДДОС приготовитьсяя услышал "да кому оно нужно", через годик рвали волосы и думали "что же делать????"
ИМХО нет у него ни какого сервака, ни реального, ни виртуального.
действительно, сама по себе виртуализация не обеспечивает безопасности, но для этого есть специальные технологии (sVirt, например). да, отдельная железка безопаснее связки kvm+libvirt+sVirt, но эта связка в свою очередь безопаснее чем запуск всех сервисов в одной системе. а в виду того, что разное железо под разные задачи могут себе позволить только юные теоретики (цена на место в приличном ДЦ имеет определяющее значение), за неимением лучшего, так сказать.
Клован, уязвимость в технологии DRAM, а не архитектуре процессора
> За скорость и уменьшение расхода памяти платишь точностью и безопасностьюТипа Айфон и Китайский Андроид?
>функционалдальше не читал
> клоун: функционал, который известен с самого создания технологии, и который прописан в
> документации к процессору, уязвимостью не является.Уязвимостью оказались аномально высокие токи утечек во многих чипах при специально организованных доступах к памяти. И никто не описывал это в документации. О такой фигне даже сами разработчики чипов не подозревали. Это вообще не на всех чипах DDR3 работает. У части чипов заряд держится достаточно для того чтобы регенерация прошла правильно.
Ну что, даешь отборные, элитные чипы DDR3 для гиков, админов и прочих безопасников? :)
клоун: ты когда в последний раз читал документацию по программированию процессоров и памяти? Там куча оговорок вида "может привести к повреждению" (оборудования, данных, ..). Просто эту научились юзать.
> клоун: ты когда в последний раз читал документацию по программированию процессоров и
> памяти? Там куча оговорок вида "может привести к повреждению" (оборудования, данных,
> ..). Просто эту научились юзать.передай клоуну (только не наври перепечатывая), ЕУЛА от твоего хозяина тоже включает много оговорок (в том же духе), но ты их глюкоподелями пользуешься и уверяешь - они безопасны
и юзать эти глюки умеют со момента начала продаж МСперделок
клоун: все известные ошибки принято документировать, предлагая альтернативные варианты решения на время устранения ошибки. Радует, что даже некоторые отечественные разработчики ПО дошли до этой простой истины:http://downloads.v8.1c.ru/content/Platform/8_2_19_68/ErrPlat...
> клоун: все известные ошибки принято документировать, предлагая альтернативные варианты
> решения на время устранения ошибки. Радует, что даже некоторые отечественные разработчики
> ПО дошли до этой простой истины:
> http://downloads.v8.1c.ru/content/Platform/8_2_19_68/ErrPlat...говорилка, передай своему клоуну - у тебя нет отечества, ты - дитя МС, а нее свои правила...
и за документирование их ошибок, в паблике (по истечении опред. срока и отсутствия реакции) - МС поднимут визг
Я ему тут друха нашёл. Не его уровень, конечно. Но всё равно они похожи =)
http://arhivach.org/thread/93609/
Скажи "нет" дедпуликации памяти!
Сократить период регенерации. Таймингами в BIOS поиграться может? Производительность сервера упадёт, но безопасность важнее.
это спорное решение и не факт что будет нормально работать, определенно вылезет что-нибудь другое.
Можно еще ограничить количество обращений к близлежащим ячейкам памяти за один цикл регенерации.
У VMware ESXi дедупликация страниц памяти, насколько я знаю, начинается при нехватке RAM хоста, что само по себе зашквар^W нештатная ситуация.
У kvm/qemu с этим вроде бы ещё хуже - они этого не умеют (поправьте меня, если я не прав).Да, проблема на уровне физики есть, но разносить все задачи по железякам - не напасёшься юнитов, я уж молчу про деньги.
> У kvm/qemu с этим вроде бы ещё хуже - они этого не умеют (поправьте меня, если я не прав).Умеют, но по умолчанию отключено.
> Умеют, но по умолчанию отключено.По умолчанию сейчас в большинстве дистров ksmd (ядерный тред фонового дедупа) активен, но дедупает только то что явно маркировано через madvise. И вопрос сводится к тому делают ли ваши kvm/qemu madvise() на памяти виртуалки. Свежие версии могут и по умолчантю делать. Или проверяйте или ksmd отключите. Хотя для начала стоило бы проверить что вас rowhammer вообще пробирает. Он срабатывает только на некоторых "неудачных" чипах. А некоторым чипам это пофиг. Ну и у нормальных серверов память с ecc, ошибок бует море.
Ударим дупликацией по дедупликации!
Ситуация имеет место быть при использовании KSM (дедупликация памяти хост-системы). Отключив её можно закрыть эту уязвимость.
>Отключив её можно закрыть эту уязвимость.нет, отключение KSM только блокирует возможный вектор атаки, уязвимость остаётся
Насчет Ubuntu повеселило. Ничего, что apt сверяет контрольную сумму с packages который подписан ключом Ubuntu?
> Насчет Ubuntu повеселило. Ничего, что apt сверяет контрольную сумму с packages который
> подписан ключом Ubuntu?Не поможет от разрушения кода или данных в оперативке. Марш читать основы работы микропроцессорных систем.
> Вторая атака приводит к изменению URL пакетов, загружаемых через apt-get и позволяет добиться установки стороннего deb-пакета в Ubuntu и Debian (например, изменили имя хоста загрузки с ubuntu.com на ubuftu.com, ubunt5.com и т.п.).Даже текст новости не осилил, а все туда же - пальцы веером.
Я так понимаю, что определить, какие именно ячейки надо изменить для получения нужного результата - задача более чем не тривиальная.
*поправляя шапочку из смеси титана, свинца и фольги*
Феноменально! Бэкдор в железе, в контроллере памяти да ещё и на уровне токов. До этого бы вряд-ли кто-то додумался раньше. Напоминает ситуацию бэкдоров в шрифтах в вин 10, но это серьезней и есть на 99,9% электронных девайсов. Что же остается параноику? Паять Радио 86РК? Или уходить на какие-то ЕС ЭВМ или даже старей?
Кстати, говорится, мол виртуальная память ссылается на один и тот же район физической памяти. А кто-то говорил о преимуществах виртуальной памяти. Не удивлюсь, если ещё вернется механизм оверлеев. И это будет прекрасно.
> Что же остается параноику? Паять Радио 86РК?Разрабатывать собственные микрочипы? Правда Вентилям тоже нельзя доверять... Эх, незадача.
Только транзисторы, только хардкор !
Какие ещё "транзисторы"? Только релюшки! А ещё лучше - тётеньки со счётами.
И колбаса "Чайная".
Херня все это. От однобитовых ошибок есть ECC, а ежели кто гоняет виртуалки на железе без ECC, тот сам себе злой буратино.Для нечитателей цитата из публикации (cтр. 12):
"Another option is to rely on memory with errorcorrecting codes (ECC) to protect against single bit flips."
Именно. Зато вой подняли...
Разработка нового DRAM при поддержки АНБ
При поддержке (для поддержки).
Вложенная Виртуализациия и тотальное шифрование, включая память - наше всё.Им для начала нужно будет узнать, что именно и как менять, потом придётся ломать шифры.
> Вложенная Виртуализациия и тотальное шифрование, включая память - наше всё.А что, идея. Только это... софтварное шифрование - тормозит. А аппаратное - так сейчас многин DRAM контроллеры и так scrambling делают, для кондиционирования сигналов, чтобы по шинам не разлетались неудачные наборы битов.
Проблема в том что злоумышленник может в принципе обмануть даже быстрое шифрование. Какая ему разница, перевернутся биты в плейнтексте или шифротексте? А кто сказал что кусочек шифротекста нельзя контролируемо попортить для получения желаемого результата? Станет сложнее атаковать, но полностью поблему не устранит.
> Им для начала нужно будет узнать, что именно и как менять, потом
> придётся ломать шифры.Не обязательно - цель не сломать шифр и даже не узнать данные. Цель их креативно порушить чтобы сломать логику программы недоступной напрямую. Для этого атакующему не обязательно знать как это вообще расшифровать. Можно порушить шифротест, возможно расшифрованный вариант испортится так что это будет чем-то полезно. Например пропатчить КОД, ориентируясь на что-то типа ret2libc. Надо будет угадать чтобы расшифрованный блок содержал несколько "полезных" байтов. А это значительно проще чем угадать 128-битный ключ шифрования.
> через apt-get и позволяет добиться установки стороннего deb-пакета в Ubuntu и Debian (например, изменили имя хоста загрузки с ubuntu.com на ubuftu.com, ubunt5.com и т.п.)Что за плохой пример, apt-get просто откажется устанавливать в таком случае, так как подпись не совпадёт.
А как с подобным справится зеркалирование памяти? (если вообще хоть какая-то разница будет..)
> RowHammerВ DDR4 это исправили, насколько я понимаю. Ну и про ECC правильно пишут выше - с ним даже в DDR3 сложно проэксплуатировать.
> выполнение непрерывного чтения одной и той же области памяти приводит к флуктуации напряжения и аномалиям, вызывающим небольшую потерю заряда соседних ячеек. Если интенсивность чтения достаточно большая, то ячейка может потерять достаточно большой объём заряда и очередной цикл регенерации не успеет восстановить его первоначальное состояние, что приведёт к изменению значения сохранённых в ячейке данных.Инженера 1970-х в шоке.
> Инженера 1970-х в шоке.Возможно вынуждать платить дважды за одну и туже память они тогда ещё не додумались,
тем более что и сама по себе настолько секретная информация о таком backdoor не говоря уже с их же цру института - вряд ли бы вообще вышла в мир, если бы неболо команды...
* не было
ksmd так жрёт процессор, что лучше его выключить, нпдеюсь qemu ещё не научили самостоятельно страницы мержить