Группа исследователей безопасности, из которых несколько участвовали в выявлении первых уязвимостей Meltdown и Spectre, разработали (https://arxiv.org/pdf/1901.01161.pdf) новый вид атаки по сторонним каналам, проводимой на основе анализа содержимого
страничного кэша (page cache), в котором содержится информация, полученная в результате обращения операционной системы к диску, SSD-накопителю и другим блочным устройствам. В отличие от атак Spectre, новая уязвимость не вызвана аппаратными проблемами, а касается только программных реализаций страничного кэша и проявляется в Linux (CVE-2019-5489 (https://security-tracker.debian.org/tracker/CVE-2019-5489)), Windows и вероятно во многих других операционных системах. Для ядра Linux исправление уже доступно (https://lkml.org/lkml/2019/1/5/104) в виде патча (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...). В Windows 10 проблема устранена в тестовой сборке (Insider Preview Build) 18305.Через манипуляции с системными вызовами mincore (http://man7.org/linux/man-pages/man2/mincore.2.html) (Linux) и QueryWorkingSetEx (https://docs.microsoft.com/en-us/windows/desktop/api/psapi/n...) (Windows), позволяющими определить наличие страницы памяти в системном страничном кэше, локальный непривилегированный атакующий может отслеживать некоторые обращения других процессов к памяти. Атака позволяет отслеживать доступ на уровне 4 килобайтовых блоков с временным разрешением в 2 микросекунды в Linux (6.7 измерений в секунду) и 446 наносекунд в Windows (223 измерений в секунду).
В страничном кэше оседают достаточно разнообразные данные, в том числе отрывки исполняемых файлов, разделяемые библиотеки, загружаемые с диска данные, отражённые в память файлы и другая информация, которая обычно хранится на диске и используется операционной системой и приложениями. Атака основана на том, что все процессы используют общий системный страничный кэш и наличие или отсутствие информации в этом кэше можно определить через изменение задержки при чтении данных с накопителя или через обращение к вышеупомянутым системным вызовам.Страницы в кэше могут быть отражены в области виртуальной памяти, одновременно используемые несколькими процессами (например, в физической памяти может присутствовать только одна копия разделяемой библиотеки, которая отражена в виртуальную память разных приложений). В процессе вытеснения информации из страничного кэша и заполнении его при загрузке типовых данных с диска, можно анализировать состояние аналогичных страниц в виртуальной памяти других приложений. Системные вызовы mincore и QueryWorkingSetEx существенно упрощают проведение атаки, так как сразу позволяют определить какие страницы памяти из заданного диапазона адресов присутствуют в страничном кэше.
Среди продемонстрированных исследователями практических применений атаки на локальную систему упоминается создание канала передачи данных из полностью изолированных sandbox-окружений, воссоздание выводимых на экран элементов интерфейса (например, диалогов аутентификации), определение задержек при нажатии клавиш и восстановление автоматически генерируемых приложением phpMyFAQ временных паролей. Более того, предложен сценарий гипотетической удалённой атаки, позволяющей локально запущенному вредоносному процессу скрыто передать данные вовне через канал связи, организованный при помощи манипуляцией со страничным кэшем (принимающая сторона определяет данные через измерение задержек при отдаче http-сервером Apache частей публично доступных файлов).
URL: https://www.openwall.com/lists/oss-security/2019/01/07/1
Новость: https://www.opennet.me/opennews/art.shtml?num=49927
Столмен был прав . . .
В чем суть уязвимости?Что дает знание есть страница в кеше или нет?
С тем самым подходом можно:
- определять запущенна программа или нет;
- по времени рендеринга страницы opennet.net можно понять была ли она в кеше или нет.
...
использовать как триггер для запуска аттаки другого типа, чтобы не светиться раньше времени
Если после вытеснения из кэша страница остаётся в физической памяти, значит данные в этой странице находились не только в кэше, но и виртуальной памяти какого-то процесса.
> после вытеснения из кэша страница остаётся в физической памятиЕсли под кешем вы имеете ввиду страничный кеш, то как это?
Флудят дисковой активностью или всплески потребления памяти, близкие к OOM, создают.
Есть такая игра в steam, brainout называется, вот у меня такое впечатление, что она этим и занимается когда я в нее играю ;) через некоторое время рывки всякие и подфриживания, а потом дикий сброс всего из памяти в своп и зависание, правда она на java. Выделение -Xms -Xmn -Xmx не помогают. Что только не делал, думал что проблема в ACPI багах, в общем я сбился с толку пытаясь пофиксить это поведение, по сути просто игра так устроена, что вызывает более быстрые фризы и зависания, а вот в чем суть проблемы под Linux без понятия, вот несколько вещей которые пробовал, но все сводится к одному, в конечном итоге через некоторое время комп виснет намертво, биос шил последний, пробовал DSDT править (исправить исправил с горем пополам, но некоторых методов просто не существует и как их туда дописать я не знаю), в итоге вернулся к обыкновенным настройкам:acpi_osi=Linux acpi=force acpi_enforce_resources=lax radeon.dpm=1 radeon.audio=1 hpet=force clocksource=hpet pci=ioapicreroute,realloc acpi_sleep=old_ordering"
#pcie_aspm=off intel_idle.max_cstate=0 processor.max_cstate=0 intel_pstate=disable acpi_sleep=old_ordering"
#acpi_osi=Linux acpi=force acpi_enforce_resources=lax radeon.dpm=1 radeon.audio=1"
#acpi=off hpet=disable pcie_aspm=off intel_idle.max_cstate=0 processor.max_cstate=0 intel_pstate=disable"
#acpi_osi=Linux acpi=force acpi_enforce_resources=lax radeon.dpm=1 radeon.audio=1 hpet=force clocksource=hpet irqpoll pci=ioapicreroute,assign-busses,nocrs,routeirq,nobfsort,pcie_bus_peer2peer,realloc pcie_aspm=off intel_idle.max_cstate=0 processor.max_cstate=0 intel_pstate=disable acpi_sleep=old_ordering"#CPU issues mitigation produces complete freeze?
#pti=off l1tf=off spectre_v2=off spec_store_bypass_disable=off
#check for possible dependencies between CPU hang
#intel_pstate=disable intel_idle.max_cstate=0 processor.max_cstate=0#cat /sys/devices/system/clocksource/clocksource0/available_clocksource
#tsc hpet acpi_pm
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
#irqpoll
В памяти остаётся так как дублирующиеся страницы дедуплицируются и хранится одна копия повторяющейся страницы из страничного кэша и памяти приложения.
Перевел так:Если страница недавно была в кэше - значит данные в физической памяти еще некоторое время назад были валидными и использовались рабочим процессом.
>Что дает знание есть страница в кеше или нет?Если страница в памяти, значит ее можно утащить через всякие спектры с мельдонием.
Не понятно? Вот в этом и суть: надо просто бояться =)
По-моему давно пора выкидывать на свалку истории C, время пришло за молодым и современным решением - Rust. Как по мне сейчас в него надо вкладывать финансирование для полировки и стабилизации чем раздавать(отмывать и пилить) бюджеты опен сорс организаций на какие-то там кде или другие putty, нотепады...
Иначе будет поздно, даже совсем скоро. Я давно об этом пишу, но похожу мало кто это понимает.
а что, раст кэшем не пользуется?
Там вроде как используется очистка памяти при освобождении. С/С++ то-же так умеет.
Именно, только в С/C++ это нужно делать вручную, я думаю мало кто забивает нулями после память после ее освобождения. Неразобравшись сразу заминусовали, ох уж эти диванные программисты.
> Именно, только в С/C++ это нужно делать вручную, я думаю мало кто
> забивает нулями после память после ее освобождения. Неразобравшись сразу заминусовали, ох уж эти диванные программисты.Религиозные убеждения не позволяют использовать модифицированную версию аллокатора, делающую это при вызове free/delete/whatever?
Кстати, удачи таким макаром из программы вычистить системный страничный кэш …В общем, первый вброс был совсем не плох, на нем бы кое-кому и остановиться …
>>Кстати, удачи таким макаром из программы вычистить системный страничный кэш …Что такое системный страничный кэш? TLB ?
>> делающую это при вызове free/delete/whatever?
Про это уже много страдательных статей. Главная причина - оно же тормозное довольно таки.
>>>Кстати, удачи таким макаром из программы вычистить системный страничный кэш …
> Что такое системный страничный кэш? TLB ?Из новости:
>> проводимой на основе анализа содержимого страничного кэша (page cache), в котором содержится информация, полученная в результате обращения операционной системы к диску,.
> Про это уже много страдательных статей. Главная причина - оно же тормозное довольно таки.Ну дык -- не я предлагаю очищать память после освобождения (хотя автоматически, хоть ручками).
>>>> проводимой на основе анализа содержимого страничного кэша (page cache), в котором содержится информация, полученная в результате обращения операционной системы к диску,Возможно переводчик не так выразился :
mincore - determine whether pages are resident in memory
QueryWorkingSetEx - Retrieves extended information about the pages at specific virtual addresses in the address space of the specified process.
ТЕ просто эти функции смотрят страница в RAM или сброшена на диск (page fault). В подкачке реально можно много чего нарыть, но подкачка в современных системах..... Там надо постараться, чтобы кэш (!) при наличии свободной RAM (!) засвопился. Если только принудительно сбрасывать, так можно да согласен.
Пошел перечитывать Танненбаума, начал забывать базис.
> Именно, только в С/C++ это нужно делать вручную, я думаю мало кто
> забивает нулями после память после ее освобождения. Неразобравшись...вот и надо не "думать", а разбираться, прежде чем стремительно чушь нести.
Ключевые слова -- memory sanitization. РД никто Вам (как и мне) не даст, видимо, но хватит и без них.
>Именно, только в С/C++ это нужно делать вручную, я думаю мало кто забивает нулями после память после ее освобожденияЗабивать память 0 _после_ освобождения это покруче разименования 0 указателя. :)
а чего сразу не js ?
JS для прикладухи, САПР, итд.
В САПРе лисп и тикль по большей части.
JS -- тот же лисп, вид сбоку.
> JS -- тот же лисп, вид сбоку.Это НЕДОДЕЛАННЫЙ лисп сбоку. Никаких рестартов, никаких макросов. Неуниверсальный синтаксис, из-за чего возникает необходимость костылей типа промисов.
Хотя кому я это пишу...
Бред
> Я давно об этом пишу, но похожу мало кто это понимает.А может быть, про перспективы Rust почти все давно всё поняли, а до сих пор чего-то не понимаете как раз Вы?
В системной программировании (вместо С) или замена C++ (как язык общего назначения, в том числе бэкенд)? В целом он претендует на оба направления, но только время покажет какую нишу он займёт.
Время покажет, что никакую.
> В системной программировании (вместо С)Метит, но не выстрелит. Как язык C намного проще, и не только в плане синтаксиса. Некоторые считают, что это важно. Меньше абстракций - ближе к железу - производительнее/предсказуемее/надёжнее.
> Я давно об этом пишу, но похожу мало кто это понимает.Всё потому, что Вы пишете "об этом", а не это.
Идите и пишите своё ядро. Заодно, глядишь, поймёте, в чём вообще дело было -- лет так через пять -- и почему с любым rust, .net, java или ещё чем такие проблемы _в лучшем случае_ останутся на месте (пока будете бороться с худшим случаем, если доберётесь).
> Идите и пишите своё ядроНе прокатит. Пока он "пишет своё ядро" на расте, раст выйдет из моды, и он будет писать о расте то же самое, что сейчас пишет о c/c++. Он это понимает, поэтому и смысла не видит вкладывать свои ресурсы во что-то кроме комментов на опеннете.
>По-моему давно пора выкидывать на свалку истории CВсецело поддерживаю, полагаться на то, что компютер сам что-то доделает за тебя - путь к потенциальным проблемам. Писать надо сразу в машинных кодах! :)
>По-моему давно пора выкидывать на свалку истории C, время пришло за молодым и современным решением - Rust.Господа хрустисты, ваш Хруст в решении этой конкретной проблемы не поможет совершенно, с точность до вообще. И Оберон с Брейнфаком тоже не помогут.
>Для ядра Linux исправление уже доступно в виде патча.Ещё -50% производительности?
> Ещё -50% производительности?И небось опять не в виде ifdef-ов, а с runtime-проверкой, на которую приходится половина этого снижения производительности.
-50000%
>В отличие от атак Spectre, новая уязвимость не вызвана аппаратными проблемами, а касается только программных реализаций страничного кэшаТак что, с чего бы это? Это не аппаратную уязвимость вокруг обходить. Что-то раньше при латании чисто софтовых уязвимостей никто не ныл про снижение производительности.
И как всю эту радость теперь отключать?
Отключив подкачку.
Ждём отдельный проц для ядра и привилегированных процессов, и отдельный для юзерленда.
Каждой задаче по своему компьютеру, а буфер обмена через облако :)
> Ждём отдельный проц для ядра и привилегированных процессов, и отдельный для юзерленда.Не жди! Интель с Таненбаумом -- уже.
Сделали уязвимый Intel ME?
А есть процессоры без кеша?
Они неэффективны.
ARM cortex-m, AVR, i8051 и прочие.
>> page cache
> А есть процессоры без кеша?Это не про тот кэш.
Это софтварный кеш ОС для увеличение отзывчивости при увеличении нагрузки.
Шо, опять???
Пузырь надувают, пока он не лопнет.
Давайте затормозим кэш что никто не смог воспользоваться этой "уязвимостью".
Или лучше вообще отключим
> Давайте затормозим кэш что никто не смог
> Или лучше вообще отключимПральна, ящитаю! Прекратить читать с "диску, SSD-накопителю и другим блочным устройствам" в память -- от этого одни уязвимости. >7<
А как же уязвимость RowHammer в DDR и SSD?