The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Атака по определению состояния памяти процессов при помощи страничного кэша

09.01.2019 19:09

Группа исследователей безопасности, из которых несколько участвовали в выявлении первых уязвимостей Meltdown и Spectre, разработали новый вид атаки по сторонним каналам, проводимой на основе анализа содержимого страничного кэша (page cache), в котором содержится информация, полученная в результате обращения операционной системы к дискам, SSD-накопителям и другим блочным устройствам. В отличие от атак Spectre, новая уязвимость не вызвана аппаратными проблемами, а касается только программных реализаций страничного кэша и проявляется в Linux (CVE-2019-5489), Windows и, вероятно, во многих других операционных системах. Для ядра Linux исправление уже доступно в виде патча. В Windows 10 проблема устранена в тестовой сборке (Insider Preview Build) 18305.

Через манипуляции с системными вызовами mincore (Linux) и QueryWorkingSetEx (Windows), позволяющими определить наличие страницы памяти в системном страничном кэше, локальный непривилегированный атакующий может отслеживать некоторые обращения других процессов к памяти. Атака позволяет отслеживать доступ на уровне 4 килобайтовых блоков с временным разрешением в 2 микросекунды в Linux (6.7 измерений в секунду) и 446 наносекунд в Windows (223 измерений в секунду).

В страничном кэше оседают достаточно разнообразные данные, в том числе отрывки исполняемых файлов, разделяемые библиотеки, загружаемые с диска данные, отражённые в память файлы и другая информация, которая обычно хранится на диске и используется операционной системой и приложениями. Атака основана на том, что все процессы используют общий системный страничный кэш и наличие или отсутствие информации в этом кэше можно определить через изменение задержки при чтении данных с накопителя или через обращение к вышеупомянутым системным вызовам.

Страницы в кэше могут быть отражены в области виртуальной памяти, одновременно используемые несколькими процессами (например, в физической памяти может присутствовать только одна копия разделяемой библиотеки, которая отражена в виртуальную память разных приложений). В процессе вытеснения информации из страничного кэша и заполнении его при загрузке типовых данных с диска, можно анализировать состояние аналогичных страниц в виртуальной памяти других приложений. Системные вызовы mincore и QueryWorkingSetEx существенно упрощают проведение атаки, так как сразу позволяют определить какие страницы памяти из заданного диапазона адресов присутствуют в страничном кэше.

Так как размер отслеживаемого блока (4 Кб) слишком велик для определения содержимого путём перебора, атака может применяться лишь для скрытой передачи данных, снижения стойкости криптографических операций через отслеживание поведения алгоритма, оценки типовых шаблонов обращений известных процессов к памяти или наблюдения за ходом выполнения другого процесса, раскладка данных в памяти для которого известна атакующему (например, если изначально известно базовое содержимое буфера во время вывода диалога аутентификации, можно определить пароль на основе посимвольного подбора во время его ввода пользователем).

Среди продемонстрированных исследователями практических применений атаки на локальную систему упоминается создание канала передачи данных из изолированных sandbox-окружений, воссоздание выводимых на экран элементов интерфейса (например, диалогов аутентификации), определение задержек при нажатии клавиш и восстановление автоматически генерируемых временных паролей (продемонстрировано на примере приложения phpMyFAQ). Более того, предложен сценарий гипотетической удалённой атаки, позволяющей локально запущенному вредоносному процессу скрыто передать данные вовне через канал связи, организованный при помощи манипуляцией со страничным кэшем (принимающая сторона определяет данные через измерение задержек при отдаче http-сервером Apache частей публично доступных файлов).

  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Эксплуатация уязвимости в DRAM-памяти через локальную сеть
  3. OpenNews: Атака через JavaScript по определению содержимого L3-кэша CPU
  4. OpenNews: Представлена техника атаки для определения ключей ECDSA и DSA
  5. OpenNews: Атака NetSpectre, приводящая к утечке содержимого памяти по сети
  6. OpenNews: Представлена атака на браузеры, позволяющая определить сайт в другой вкладке
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/49927-page
Ключевые слова: page, cache, attack, linux, memory
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (55) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Иван Семеныч (?), 19:14, 09/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Столмен был прав . . .
     
  • 1.3, Oleh (ok), 19:21, 09/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    В чем суть уязвимости?

    Что дает знание есть страница в кеше или нет?
    С тем самым подходом можно:
    - определять запущенна программа или нет;
    - по времени рендеринга страницы opennet.net можно понять была ли она в кеше или нет.
    ...

     
     
  • 2.5, Cradle (?), 19:49, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    использовать как триггер для запуска аттаки другого типа, чтобы не светиться раньше времени
     
  • 2.7, Аноним (7), 19:50, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если после вытеснения из кэша страница остаётся в физической памяти, значит данные в этой странице находились не только в кэше, но и виртуальной памяти какого-то процесса.
     
     
  • 3.8, Аноним (8), 20:08, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > после вытеснения из кэша страница остаётся в физической памяти

    Если под кешем вы имеете ввиду страничный кеш, то как это?

     
     
  • 4.10, Аноним (7), 20:11, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Флудят дисковой активностью или всплески потребления памяти, близкие к OOM, создают.
     
     
  • 5.54, newbie (??), 13:04, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Есть такая игра в steam, brainout называется, вот у меня такое впечатление, что ... большой текст свёрнут, показать
     
  • 4.11, Аноним (7), 20:16, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В памяти остаётся так как дублирующиеся страницы дедуплицируются и хранится одна копия повторяющейся страницы из страничного кэша и памяти приложения.
     
  • 3.14, letsmac (ok), 20:52, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Перевел так:

    Если страница недавно была в кэше - значит данные в физической памяти еще некоторое время назад были валидными и использовались рабочим процессом.  

     
  • 2.47, КО (?), 10:17, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Что дает знание есть страница в кеше или нет?

    Если страница в памяти, значит ее можно утащить через всякие спектры с мельдонием.

     
  • 2.52, Аноним (52), 11:46, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не понятно? Вот в этом и суть: надо просто бояться =)
     

  • 1.4, Anon_Erohin (?), 19:48, 09/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –36 +/
    По-моему давно пора выкидывать на свалку истории C, время пришло за молодым и современным решением - Rust. Как по мне сейчас в него надо вкладывать финансирование для полировки и стабилизации чем раздавать(отмывать и пилить) бюджеты опен сорс организаций на какие-то там кде или другие putty, нотепады...
    Иначе будет поздно, даже совсем скоро. Я давно об этом пишу, но похожу мало кто это понимает.
     
     
  • 2.6, Cradle (?), 19:49, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    а что, раст кэшем не пользуется?
     
     
  • 3.15, letsmac (ok), 20:54, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там вроде как используется очистка памяти при освобождении. С/С++ то-же так умеет.
     
     
  • 4.16, Anon_Erohin (?), 21:03, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • –10 +/
    Именно, только в С/C++ это нужно делать вручную, я думаю мало кто забивает нулями после память после ее освобождения. Неразобравшись сразу заминусовали, ох уж эти диванные программисты.
     
     
  • 5.18, Аноним84701 (ok), 21:13, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Именно, только в С/C++ это нужно делать вручную, я думаю мало кто
    > забивает нулями после память после ее освобождения. Неразобравшись сразу заминусовали, ох уж эти диванные программисты.

    Религиозные убеждения не позволяют использовать модифицированную версию аллокатора, делающую это при вызове free/delete/whatever?
    Кстати, удачи таким макаром из программы вычистить системный страничный кэш …

    В общем, первый вброс был совсем не плох, на нем бы кое-кому и остановиться …


     
     
  • 6.19, letsmac (ok), 21:35, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>Кстати, удачи таким макаром из программы вычистить системный страничный кэш …

    Что такое системный страничный кэш? TLB ?

    >> делающую это при вызове free/delete/whatever?

    Про это уже много страдательных статей. Главная причина - оно же тормозное довольно таки.

     
     
  • 7.24, Аноним84701 (ok), 21:58, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>>Кстати, удачи таким макаром из программы вычистить системный страничный кэш …
    > Что такое системный страничный кэш? TLB ?

    Из новости:
    >> проводимой на основе анализа содержимого  страничного кэша (page cache), в котором содержится информация, полученная в результате обращения операционной системы к диску,

    .
    > Про это уже много страдательных статей. Главная причина - оно же тормозное довольно таки.

    Ну дык -- не я предлагаю очищать память после освобождения (хотя автоматически, хоть ручками).

     
     
  • 8.25, letsmac (ok), 22:11, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Возможно переводчик не так выразился mincore - determine whether pages are r... текст свёрнут, показать
     
  • 5.35, Michael Shigorin (ok), 23:45, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Именно, только в С/C++ это нужно делать вручную, я думаю мало кто
    > забивает нулями после память после ее освобождения. Неразобравшись

    ...вот и надо не "думать", а разбираться, прежде чем стремительно чушь нести.

    Ключевые слова -- memory sanitization.  РД никто Вам (как и мне) не даст, видимо, но хватит и без них.

     
  • 5.55, КО (?), 10:42, 11/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Именно, только в С/C++ это нужно делать вручную, я думаю мало кто забивает нулями после память после ее освобождения

    Забивать память 0 _после_ освобождения это покруче разименования 0 указателя. :)

     
  • 2.9, Аноним (9), 20:11, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а чего сразу не js ?
     
     
  • 3.17, Петровичус (?), 21:12, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    JS для прикладухи, САПР, итд.
     
     
  • 4.26, letsmac (ok), 22:12, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В САПРе лисп и тикль по большей части.  
     
     
  • 5.32, Иван Семеныч (?), 22:24, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    JS -- тот же лисп, вид сбоку.
     
     
  • 6.37, Аноним (37), 00:08, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > JS -- тот же лисп, вид сбоку.

    Это НЕДОДЕЛАННЫЙ лисп сбоку. Никаких рестартов, никаких макросов. Неуниверсальный синтаксис, из-за чего возникает необходимость костылей типа промисов.

    Хотя кому я это пишу...

     
  • 2.12, Аноним (12), 20:49, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Бред
     
  • 2.13, Аноним (13), 20:51, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Я давно об этом пишу, но похожу мало кто это понимает.

    А может быть, про перспективы Rust почти все давно всё поняли, а до сих пор чего-то не понимаете как раз Вы?

     
     
  • 3.30, proninyaroslav (ok), 22:21, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В системной программировании (вместо С) или замена C++ (как язык общего назначения, в том числе бэкенд)? В целом он претендует на оба направления, но только время покажет какую нишу он займёт.
     
     
  • 4.33, Аноним (33), 23:08, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Время покажет, что никакую.
     
  • 4.40, Аноним (37), 00:17, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > В системной программировании (вместо С)

    Метит, но не выстрелит. Как язык C намного проще, и не только в плане синтаксиса. Некоторые считают, что это важно. Меньше абстракций - ближе к железу - производительнее/предсказуемее/надёжнее.

     
  • 2.34, Michael Shigorin (ok), 23:43, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Я давно об этом пишу, но похожу мало кто это понимает.

    Всё потому, что Вы пишете "об этом", а не это.

    Идите и пишите своё ядро.  Заодно, глядишь, поймёте, в чём вообще дело было -- лет так через пять -- и почему с любым rust, .net, java или ещё чем такие проблемы _в лучшем случае_ останутся на месте (пока будете бороться с худшим случаем, если доберётесь).

     
     
  • 3.38, Аноним (37), 00:10, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Идите и пишите своё ядро

    Не прокатит. Пока он "пишет своё ядро" на расте, раст выйдет из моды, и он будет писать о расте то же самое, что сейчас пишет о c/c++. Он это понимает, поэтому и смысла не видит вкладывать свои ресурсы во что-то кроме комментов на опеннете.

     
  • 2.44, КО (?), 10:07, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >По-моему давно пора выкидывать на свалку истории C

    Всецело поддерживаю, полагаться на то, что компютер сам что-то доделает за тебя - путь к потенциальным проблемам. Писать надо сразу в машинных кодах! :)

     
  • 2.49, Аноним (49), 10:59, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >По-моему давно пора выкидывать на свалку истории C, время пришло за молодым и современным решением - Rust.

    Господа хрустисты, ваш Хруст в решении этой конкретной проблемы не поможет совершенно, с точность до вообще. И Оберон с Брейнфаком тоже не помогут.

     

  • 1.20, Аноним (20), 21:41, 09/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >Для ядра Linux исправление уже доступно в виде патча.

    Ещё -50% производительности?

     
     
  • 2.39, Аноним (37), 00:14, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ещё -50% производительности?

    И небось опять не в виде ifdef-ов, а с runtime-проверкой, на которую приходится половина этого снижения производительности.

     
  • 2.48, Аноним (48), 10:52, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    -50000%
     
  • 2.50, Аноним (49), 11:25, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >В отличие от атак Spectre, новая уязвимость не вызвана аппаратными проблемами, а касается только программных реализаций страничного кэша

    Так что, с чего бы это? Это не аппаратную уязвимость вокруг обходить. Что-то раньше при латании чисто софтовых уязвимостей никто не ныл про снижение производительности.

     

  • 1.21, Аноним (21), 21:47, 09/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    И как всю эту радость теперь отключать?
     
     
  • 2.27, letsmac (ok), 22:13, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Отключив подкачку.
     

  • 1.22, Аноним (22), 21:47, 09/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ждём отдельный проц для ядра и привилегированных процессов, и отдельный для юзерленда.
     
     
  • 2.45, КО (?), 10:10, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Каждой задаче по своему компьютеру, а буфер обмена через облако :)
     
  • 2.46, Andrey Mitrofanov (?), 10:12, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ждём отдельный проц для ядра и привилегированных процессов, и отдельный для юзерленда.

    Не жди!  Интель с Таненбаумом -- уже.

     
     
  • 3.51, Аноним (49), 11:26, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сделали уязвимый Intel ME?
     

  • 1.23, Аноним (23), 21:56, 09/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А есть процессоры без кеша?
     
     
  • 2.28, Аноним (28), 22:15, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Они неэффективны.
     
  • 2.29, letsmac (ok), 22:20, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    ARM cortex-m, AVR, i8051 и прочие.  
     
  • 2.36, Michael Shigorin (ok), 23:47, 09/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> page cache
    > А есть процессоры без кеша?

    Это не про тот кэш.

     
  • 2.42, Эш Уильямс (?), 01:41, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это софтварный кеш ОС для увеличение отзывчивости при увеличении нагрузки.
     

  • 1.43, Какаянахренразница (ok), 05:21, 10/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Шо, опять???
     
     
  • 2.53, Аноним (52), 11:51, 10/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пузырь надувают, пока он не лопнет.
     

  • 1.56, Аноним (56), 13:59, 11/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Давайте затормозим кэш что никто не смог воспользоваться этой "уязвимостью".
    Или лучше вообще отключим
     
     
  • 2.57, Andrey Mitrofanov (?), 14:02, 11/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Давайте затормозим кэш что никто не смог
    > Или лучше вообще отключим

    Пральна, ящитаю!  Прекратить читать с "диску, SSD-накопителю и другим блочным устройствам" в память  --  от этого одни уязвимости. >7<

     

  • 1.58, Эш Уильямс (?), 19:25, 11/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А как же уязвимость RowHammer в DDR и SSD?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру