1. Куча / Говнокод #23642

    0

    1. 1
    Давайте обсудим meltdown и spectre.

    Объясните мне кто-нибудь, в чем принципиальное отличие spectre от meltdown? И как оно позволяет читать память других процессов? Все что я пока понял - это чтение памяти ядра, которое уже все прикрыли, и проблемы с жс в браузере.

    Запостил: FrauSchweinhund, 06 Января 2018

    Комментарии (101) RSS

    • #melt #даун #спектрум
      Ответить
    • ну прочитай статью на gpz, сложно что ли https://googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html

      > И как оно позволяет читать память других процессов?

      При speculative execution процессор имеет право положить хуй на if и начать выполнять любую его ветвь до того, как он проверит, что реально попало в if - если считает это нужным. Все, что грузится в этой ветви, проходит через кэш процессора, что позволяет как минимум косвенным образом выяснить, что там внутри валялось.
      Ответить
    • Нормальная статья про meltdown https://sohabr.net/gt/post/297029/

      Краткий пересказ:

      - Есть спекулятивное исполнение, которое выполняет ветку условного перехода, которая по мнению процессора должна выполниться (предсказание переходов) до того, как выполнится собственно само сравнение. При этом на уязвимых процах не задействуется MMU, который должен давать по рукам за попытку обращения к чужой памяти (та самая ошибка "программа обратилась"), по крайней мере сразу. Т.е. сначала выполняется операция и потом только MMU начинает гавкать.
      АМД неуязвимы потому что у них MMU проверяет права доступа сразу при исполнении, по заявлению их работника.
      Результаты хранятся скрыто, к ним нельзя обратиться через проц.

      - На всех процах есть косвенная адресация (прочти мне ячейку памяти по адресу, лежащему в регистре). Еще там есть кэш, разница по скорости обращения к памяти и кэшу огромная - к памяти сотню циклов (хз сколько на самом деле), к кэшу первого уровня - 1 цикл проца.

      - Результаты спекулятивного исполнения влияют на кэш.

      Сценарий атаки такой:

      Создаются условия для того, чтобы проц посчитал условный переход выполняющимся.
      Процессор в спекулятивном режиме читает значение по адресу 15000. Пусть там будет лежать, например, 98.
      Процессор читает значение, лежащее по адресу 98.
      От MMU приходит ответ о невалидности адреса 15000.
      Процессор сбрасывает конвейер и вместо значения, лежащего по адресу 98, выдаёт нам ошибку.
      Наше приложение начинает читать адреса от 0 и выше в собственном адресном пространстве (имеет полное право), замеряя время, требующееся на чтение каждого адреса, и читая их не по порядку, чтобы не натренировать тот же спекулятивный доступ
      На адресе 98 время доступа вдруг оказывается в несколько раз ниже, чем на других адресах
      Ответить
      • > Таким образом мы можем прочитать всю память ядра системы, на которую, в свою очередь, в современных ОС отображается вообще вся физическая память компьютера.
        > вся физическая память компьютера

        Видимо вот так читать память других процессов.
        Ответить
        • Нужно всю ценную информацию в свопе держать, тогда её не прочесть будет.
          Ответить
        • А вот ты про что. А зачем ее туда отображать? Наверно,чтобы легче испортить было?
          Ответить
          • Ну, кто-то должен же подгружать странички из свопа в физическую память и наоборот. Логично, что этим занимается ядро системы.
            Ответить
            • Я оч хреново помню асм защищенного режима, но как тогда на 4 гб адресного пространства отобразить 4 гб реальной оперативы + адресное пространство проги?
              Ответить
              • Так ведь все 4 гигабайта адресного пространства процессу не были доступны никогда. Оригинально 2, потом (С Large Address Aware) — 4 минус невыгружаемая память ядра. В итоге ядру получается как раз хватает 4 ГБ пространства чтобы отобразить всю память (так как ядро всегда в реальной памяти)

                Ещё PAE есть, с помощью которого можно хоть черта лысого адресовать, но это экзотика.
                Ответить
                • Емнип, всю физическую память внаглую мапают только 64-битные оси. А 32-битки мапали только самое необходимое - page table, буферы для i/o да свои структуры.

                  Но я могу ошибаться.
                  Ответить
                  • если не ошибаюсь то и под 32 бита все мапили. мапы на 32ита осях меньше места жрут. все запихивается в один мап - и из него потом "выделятеся" память (странички) для всего остального - процессы (VMA), кэш, io. может ошибаюсь, но по крайней мере в линуховом ядре нет никакого другого управления физической памятью.
                    Ответить
      • >Нормальная статья
        > https://sohabr.net/gt/post/297029/

        >>Нормальная
        >>habr

        Тебе самому не стыдно-то?
        По ссылкам не ходил, но сайтец наверняка кацапский, хоть и .net.
        Ответить
    • Пусть Х - объект, к которому нет доступа, а arr - массив специальной хуйни.

      Meltdown:
      Выкидываем arr из кэша нахуй, занимаем процессор обсчётом муторной хуйни, и дальшн пишем arr[x]. Часть процессора, которой нечем занятся, делает out of order execution и загружает этот arr[x] в кэш. Выполнение доходит до строчки arr[x], процессор обнаруживает, что Х недоступна, и кидает исключение. Программа его обрабытывае и начинает тыкать arr, проверяя, какой элемент быстрее загрузится, а значит, лежит в кэше. Если 42 элемент, значит Х == 42.
      Патч: Смывать кэш нахуй каждый раз когда происходит нелегальный доступ.

      Spectre:
      Тренируем очко branch predictor, что какое-то условие всегда истинно. Смываем кэш arr. Затем ВНЕЗАПНО делаем его ложным, и пихаем в тело arr[x]. arr[x] загружается в кэш, выполнение реально доходит до условия, ОЖТЫЖЁБАНЫЙНАХУЙПРЕДИКТОРОШИБСЯ, выполнение идёт дальше. Так как реально попытки доступа к запрещённой памяти не было, исключения нет, и никто не в курсе, что произошло. Дальше находим Х из номера элементы arr находящегося в кэше.

      Как читать память других процессов не ебу ещё, можно почитать здесь: https://spectreattack.com/spectre.pdf
      Ответить
      • > Патч: Смывать кэш нахуй каждый раз когда происходит нелегальный доступ.
        Нет. Патч - не держать память ядра в текущем адресном пространстве.
        Ответить
      • Можно ли защититься от Meltdown программно?

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

        Для всех распространённых ОС уже вышли или готовятся выйти патчи, переносящие область памяти ядра в другую облась, т.е. обеспечивающие защиту не только выставлением привилегий, но и контролем доступа по адресам — второе Meltdown обойти не может.

        Проблема в том, что при такой архитектуре системные вызовы (syscalls) становятся крайне накладными — они замедляются в несколько раз. Соответственно, реальные приложения также теряют в производительности, в зависимости от доли системных вызовов в конкретном приложении падение может составить от 1-2 до нескольких десятков процентов. Например, на PostgreSQL продемонстрировано падение более 20 %, в то время как в игрушках разницы практически нет.
        Ответить
      • Сема выше пишет, что amd проверяют доступность X до загрузки arr[X] в кэш - поэтому уязвимы к meltdown только интелы. Получается, амд должны быть не уязвимы к тому, что ты описал как spectre, но везде пишут, что spectre работает и на амд. Что-то не согласуется.
        Ответить
        • > the attacker chooses a gadget from the address space of the victim and influences the victim to execute the gadget speculatively. Unlike ROP, the attacker does not rely on a vulnerability in the victim code. Instead, the attacker trains the Branch Target Buffer (BTB) to mispredict a branch from an indirect branch instruction to the address of the gadget, resulting in a speculative execution of the gadget. While the speculatively executed instructions are abandoned, their effects on the cache are not reverted. These effects can be used by the gadget to leak sensitive information.

          Судя по всему, доступ к памяти идёт от имени процесса-жертвы. Т.е. вместо arr[x] там jz (адрес подобной конструкции в коде жертвы)
          Ответить
          • Ты сейчас про спектр, он про мелтдаун. https://sohabr.net/gt/post/297031/ тут пишет автор, что спектр работает когда фазы луны совпадают.
            Ответить
          • Прочитал вторую часть Семиной статьи. Короче, спектре, манипулируя с бранчпредиктором, заставляет атакуемый процесс загрузить нужный кусок памяти в кэш. А потом какими-то внешними запросами надо заставить атакуемый процесс прочитать нужную память и померять, какой запрос отработает быстрее. Дичь.
            Ответить
          • > chooses a gadget from the address space of the victim
            ASLR?
            Ответить
            • Возможно бранчпредиктор можно натренировать и не повторяя адреса условных переходов?
              Надо случайно обфусцировать бинарь при загрузке, как это делали всякие защиты от крякеров. Только воспроизводить баги и смотреть корки уже не получится.
              Ответить
        • Или до, или до второй команды. Где-то в коментах видел цитату на английском от амдшника.
          Ответить
        • Variants of this issue are known to affect many modern processors, including certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU models, we have exploits that work against real software. We reported this issue to Intel, AMD and ARM on 2017-06-01

          https://googleprojectzero.blogspot.ru/2018/01/reading-privileged-memory-with-side.html
          Ответить
    • Тут про спектр https://sohabr.net/gt/post/297031/. ЯННП
      ---
      TL:DR

      Глобальная ошибка, присутствующая примерно во всех существующих процессорах. Была бы полной жопой, если бы не высокая сложность практической реализации, из-за которой хакеры на неё забьют.

      AMD, похоже, наполовину безопаснее прочих, хотя и непонятно, почему.

      TL:DR — разница с Meltdown

      Meltdown использует ошибку в процессорах Intel и ARM, из-за которой при спекулятивном выполнении инструкций процессор игнорирует права доступа к памяти.

      Spectre использует особенность работы алгоритмов предсказания ветвлений и переходов в современных процессорах, из-за которой один процесс может влиять на вероятность спекулятивного исполнения инструкций в другом процессе.
      Ответить
      • > AMD, похоже, наполовину безопаснее прочих, хотя и непонятно, почему.

        амд никогда так аггресивно как интел не параллелил исполнение. поэтому они слегка медленее и работают.

        с другой стороны, параллелизация + игнорирование ошибок - я теперь понимаю как интел производительность подымал в последние годы. потому что прирост герцами и оптимизациями было трудно объяснить. а с таким out-of-order которому все до жопы... то тогда да, понятно.
        Ответить
      • >AMD, похоже, наполовину безопаснее прочих, хотя и непонятно, почему.

        Да потому что у них ничтожная доля рынка и этот АМД никому нахер не впёрся!

        На самом деле у зелёных тоже багов полно. Просто после десяти лет выпуска малоконкуретных процессоров трудно вызвать былой интерес.
        Помнится эпичная бага у АМД, с кешем TLB. Просто интел/арм повсеместен, потому исследуют его сильнее.

        Как и те же винды. В мире линукс софта дыр и переполнений не меньше, т.к. всё написано на той же сишке. Но у винды доля десктопного рынка на порядок больше, а квалификация среднего юзера ниже.
        Ответить
        • Интелоблядь порвалась, не дочитав описание уязвимости.
          Ответить
          • https://roem.ru/09-01-2018/266163/ms-amd-no-rocks/


            Microsoft приостановил распространение патча от Meltdown и Spectre — он вешает компьютеры на процессорах AMD

            Компьютерам под Windows с некоторыми процессорами AMD не удаётся загрузиться после установки патча от уязвимости Meltdown/Spectre.

            Представленное компанией Microsoft экстренное накопительное обновление безопасности под Windows для устранения недавно выявленных уязвимостей Meltdown и Spectre приводит к возникновению ряда новых проблем и непредсказуемых последствий.

            Жалобы от пользователей систем на базе процессоров AMD на сбои и возникновение ряда новых проблем начали появляться на форуме пользователей Microsoft сразу же после выпуска нового защитного патча.

            Согласно этим сообщениям, проблемы возникают у владельцев систем на процессорах Athlon, получивших кумулятивное обновление безопасности KB4056892 и инсталлировавших его на системах с установленным обновлением Windows 10 Fall Creators Update.



            Security
            It gets worse: Microsoft’s Spectre-fixer wrecks some AMD PCs
            KB4056892 is not your friend if you run an Athlon

            Users report Athlon-powered machines in perfect working order before the patch just don’t work after it. The patch doesn’t create a recovery point, so rollback is little use and the machines emerge from a patch in a state from which rollback is sometimes not accessible. Some say that even re-installing Windows 10 doesn’t help matters. Others have been able to do so, only to have their machines quickly download and install the problematic patch all over again …


            Охуенно, чо. Чинили одно — сломали другое.
            Ответить
            • > Others have been able to do so, only to have their machines quickly download and install the problematic patch all over again …

              Отключить интернет эти гении не догадались...
              Ответить
              • https://support.microsoft.com/en-us/help/4056892/windows-10-update-kb4056892

                Symptom: Microsoft has reports of some customers with AMD devices getting into an unbootable state after installing this KB. To prevent this issue, Microsoft will temporarily pause Windows OS updates to devices with impacted AMD processors at this time.

                Workaround: Microsoft is working with AMD to resolve this issue and resume Windows OS security updates to the affected AMD devices via Windows Update and WSUS as soon as possible. If you have experienced an unbootable state or for more information see KB4073707. For AMD specific information please contact AMD.


                Эта история становится всё лучше и лучше.
                Нет, ну вот-как-то, а?
                Может они под видом т.н. "патча" еще бекдоров добавили?
                Ответить
                • А зачем им ещё бэкдоры добавлять? У них и так канал поставки бэкдоров обновлений работает на полную, добавить туда что-нибудь не проблема. Кстати, десятка всё ещё шлёт кучу инфы под видом "телеметрии"?
                  Ответить
        • > Просто интел/арм повсеместен, потому исследуют его сильнее.
          Это зелень? Тут баг, общий для нескольких типов процев, но не работающий на AMD.
          Ответить
    • > Давайте обсудим meltdown и spectre.
      А что там обсуждать? Нам всем пиздец.
      Ответить
      • интелу может быть будет слегка пиздец.

        народ на интернете поговаривает о судебном процессе против интела, т.к. они: знали о проблеме уже пол года; до последнего момента отрицали что это баг; тыркали пальцами в конкурентов в то время как сами не останавливались продавать дефективные процы; на текущий момент даже и следов что они что-то фиксят микрокодом пока нету.
        Ответить
        • Какой там пиздец. Все фиксится софтово.
          Ответить
          • фиксится - но с большим уроном для производительности. все бенчмарки переделывать надо.

            с другой стороны, факт что фиксится (и фиксится другими, а не интелом), не оправдывает того что интел на проблему забил и продолжал продажи.
            Ответить
            • Что значит "забил"? Ты думаешь в железе ее пофиксить хуй да нихуя? И ты думаешь из-за такой проблемы ты получишь 100% бесплатную замену?
              Ответить
              • Ну из-за бага который выдавал ошибки в ~10й цифре при делении плавучки меняли же.
                Ответить
              • я не думаю. даже дергатся не собираюсь.

                > Ты думаешь в железе ее пофиксить хуй да нихуя?

                для этого уже 20+ лет (после fdiv бага) существует "microcode" - механизм для фиксов багов проца, которым (интел хвастался) они буквально все могут пофиксить.

                но так как надо сбрасывать кэши, я думаю интел это спихнул на ОСы, потому что это плохо для производительности, и они скорее из-за плохого маркетинга это будут пытаться избегать делать. если процы тормозят из-за интела - то это как бы плохо для интела. если процы тормозят из-за ОСи - то у интела есть отмазка.
                Ответить
                • > если процы тормозят из-за ОСи
                  > у интела есть отмазка
                  Но патчи в осях же только на интелах включены и тормозят...
                  Ответить
                • А вообще, KPTI это же круто... Может быть микроядра популярнее станут, всё-таки одно из основных преимуществ монолитки наполовину закопали.
                  Ответить
                • > которым (интел хвастался) они буквально все могут пофиксить.
                  Давай пруфы

                  > но так как надо сбрасывать кэши
                  Когда?

                  > если процы тормозят из-за ОСи - то у интела есть отмазка.
                  Я думаю они даже с патчами будут ебать amd в хвост и гриву. Время реальной конкурренции ушло.
                  Ответить
                  • > > но так как надо сбрасывать кэши
                    > Когда?

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

                    и это уже фикс ... то ли для первого, то ли второго экплоита.
                    Ответить
                    • Фикс для мелтдауна - вынос адресов ядра из адресного пространства процессов.
                      Ответить
                • > До конца следующей недели Intel также намерен выпустить обновление микрокода для 90% моделей CPU, выпущенных последние 5 лет.
                  Ну ладно, посмотрим. Кстати, а посадить троян/бекдор в микрокод можно?
                  Ответить
                  • > посадить троян/бекдор в микрокод можно
                    Интелу - запросто. Остальным - х.з., всё-таки там цифровая подпись какая-то есть.
                    Ответить
                    • Откуда инфа? Были прецеденты? Даже если есть подпись - можно ли поставить старую версию микрокода с известными уязвимостями?
                      Ответить
                      • > поставить старую версию микрокода
                        У проца флешки нету, микрокод заливается BIOS'ом на каждом старте. Т.е. в теории можно даунгрейднуть/пропатчить прошивку (но прошивки сейчас не особо любят даунгрейдиться).
                        Ответить
                        • То есть патчи микрокода будут патчить биос? А какая защита от даунгрейда биоса?
                          Ответить
                          • > То есть патчи микрокода будут патчить биос
                            Как вариант. Операционки, по идее, тоже могут микрокод лить. Лишь бы версия заливаемого микрокода была больше, чем та которая сейчас в проце.

                            > защита от даунгрейда биоса
                            Тупо отказывается принимать старую прошивку. Программатором пока ещё можно что угодно залить...

                            З.Ы. А вот на некотрых приставках при апдейте "выжигали" фьюзы, чтобы старая прошивка больше никогда не могла запуститься...
                            Ответить
                            • >Операционки, по идее, тоже могут микрокод лить.

                              Даже легче чем кажется. Всякие убунты просто грузят его на старте.

                              $ apt policy intel-microcode

                              Проверять:
                              $ dmesg | grep microcode
                              Ответить
                    • много там не подпишешь.

                      а вектор интересный. микрокоды заливаются раз, и никаких проверок после на них не делается.

                      микрокодом добавляешь баг, а потом в юзверспэйсе его "экплоитишь" что бы делать все что хочешь в любой момент времени - и не оставляя следов.
                      Ответить
                      • > много там не подпишешь
                        Ну вот сейчас исследование читаю - там 2048-битная RSA подпись.
                        Ответить
                        • проверяет сам проц?
                          Ответить
                          • Да. Правда я не понял, нафига публичный ключ в апдейте лежит. Видимо, в проце только под его хэш места хватило...

                            З.Ы. Ну вектор не такой уж интересный - залитый микрокод после резета пропадёт, а патчить BIOS - следы останутся (проще тогда туда код въебать, хоть RSA ломать не придётся).
                            Ответить
                  • > Кстати, а посадить троян/бекдор в микрокод можно?
                    Для AMD K8 таки смогли (там апдейты микрокода были с простой чексуммой и не зашифрованные): https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-koppe.pdf

                    З.Ы. Пиздец у чуваков ресурсы были:
                    In order to remove layers, we used a combined approach of Chemical Mechanical Polishing and plasma etching. During inspection of the seventh layer, we encountered the expected ROM array structure. We acquired images of individual layers using a Scanning Electron Microscope since optical microscopy reaches diffraction limits at this structure size.
                    Ответить
              • >И ты думаешь из-за такой проблемы ты получишь 100% бесплатную замену?

                А разве компы найденные на свалке меняют? Возможно ты не помнишь, т.к. болтался у папки в яйцах, но в 90х меняли пеньки, когда FDIV ёбнул.
                Ответить
        • Почему интелу? Почему не арму?
          Ответить
          • у арм проблема намного меньше, и сами процов они не делают.

            ответственность падает на Samsung/Apple/STM/TI/etc которые арм дезайнами пользуются, но их все равно кастомизируют.

            и в отличии от интела, на армах нет микрокода, которым это можно пофиксить. для арма в любом случае нужен софтварный фикс в ОС.
            Ответить
            • Ок, производителям ARM процев.
              А кто тебе сказал что это можно пофиксить микрокодом?
              Ответить
        • Ответить
        • >на текущий момент даже и следов что они что-то фиксят микрокодом пока нету

          Оооо. Микрокод — это отдельная епархия.
          Непонятно что вообще страшнее: аппаратные баги или намеренные бэкдоры в микрокоде.
          Ответить
          • Кому нужны букдоры? Воровать куки Путена?
            Если правда вскроется, то не отмоешься же.
            Ответить
            • >Если правда вскроется, то не отмоешься же.

              Гойсподи, да у них постоянно такое вскрывается.
              https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00075&languageid=en-fr

              А тот эпик с RDRAND, аппаратным генератором рандома, когда пало подозрение на контроль NSA что писали массовую петицию выкинуть нахуй кернела.

              https://crypto.stackexchange.com/questions/10283/could-rdrand-intel-compromise-entropy
              Ответить
      • [color=yellow]цвет не тот[/color]
        Ответить
    • Налетай!
      git clone https://github.com/IAIK/meltdown
      Ответить
    • Штеуд-chan is being lewded hard. Ещё одну дыру в AMT нашли:
      https://business.f-secure.com/intel-amt-security-issue
      Ответить
    • Давайте я объясню за Meltdown.
      Про спектр пока не читал, было не до того.
      В адресном пространстве процесса есть ядро, но из юзерспейс кода (в сегменте с dpl=3) читать его нельзя:
      получишь fault потому что там у страниц запрещен доступ из userspace.

      У CPU е разные модули (ALU, AGU итд) и всех их надо загрузить: потому проц выполняет микрокоманды спекулятивно:
      if (*foo) {bar=42 + 1}. Пока один вычиляет foo(представим что branch prediction не работает), другой считает 42+1.
      Если *foo==FALSE, то результат откидывается.
      Почитать подробнее можно в мануале про pipelines и в вики про hazards и алгоритм Tomasulo.
      Когда почитаешь и поймешь как reservation stations обменваются по CBS и что такое register rename
      -- возвращайся и читай дальше.

      Код "MOV AL, [KernelSpaceAddr]" вызовет fault, но к этому моменту он уже может быть выполнен, потому
      что проверка выполнялась параллельно с кодом. Физически данные будут во "внутреннем" регистре (см register rename)
      и никогда не станут доступы следующей инструкции потому что всё это проц нахуй выкинет следующим шагом (потому что fault).
      То-есть у нас такой "код в другом мире" считал память, но передать ее дальше не может.
      Есть side channel аттака на кеш Flush+Reload (советую почитать) на основее нее сделано то, что происходит дальше.

      Если флашнуть кеш (cflush) а потом считать данные из памяти то загрузка займет долгое время, а если из прочитать то
      кеш будет заполнен и времени нужно будет меньше.


      ПРОДОЛЖЕНИЕ НИЖЕ
      Ответить
      • НАЧАЛО ВЫШЕ

        Process1: cflushшит доступную ему память и порождает Process2.
        Process2: читает байт из памяти ядра и использует его для индексации в массиве в доступной ему памяти
        foo=*kern_space; bar = *(addr_of_somemem += (4096 * foo)) и тут его настигает fault.
        Process2 может поставить хендлер или сдохнуть или использовать транзационную память, не важно что с ним дальше.

        Важно что если он считал 0 то addr_of_somemem теперь в кеше
        А если 1 то addr_of_somemem + 4К теперь в кеше.

        Теперь Process1 просто читает addr_of_somemem и замеряет время.
        Малое время addr_of_somemem -- считали 0
        большое время -- считали 1.

        Лечится KAISER: убираем из адр. пространства процесса все ядро кроме нужного (обработчики прерыв итд)

        Вот тут все на пальцах: https://meltdownattack.com/meltdown.pdf
        Ответить
        • продаю свои ношеные трусы для любителей пикантненького, 5тр, сам гей, смазлив, ухожен, пиши прямо сейчас [email protected] антон ЖДУ
          Ответить

    Добавить комментарий