Найдена новая уязвимость в процессорах

    Инженеры Microsoft и Google совместными усилиями обнаружили новую уязвимость в процессорах Intel, AMD, ARM похожую на Meltdown и Spectre. Угрозу назвали Speculative Store Bypass (v4) (CVE-2018-3639). Аналогично Spectre, эксплойт также использует спекулятивное выполнение команд, которое предоставляют современные CPU.



    Метод атаки напоминает Spectre 1, но базируется на восстановлении осевших в процессорном кэше данных после отбрасывания результата спекулятивного выполнения операций при обработке чередующихся операций записи и чтения с использованием косвенной адресации. Когда операция чтения следует за операцией записи (например, mov [rbx + rcx], 0x0; mov rax, [rdx + rsi]), смещение адреса для чтения уже может быть известно из-за выполнения похожих операций (операции чтения выполняются значительно чаще и чтение может быть выполнено из кэша) и процессор может спекулятивно выполнить чтение раньше записи, не дожидаясь пока будет вычислено смещение косвенной адресации для записи. Если после вычисления смещения выявлено пересечение областей памяти для записи и чтения, процессор просто отбросит уже спекулятивно полученный результат чтения и повторит эту операцию.


    Особенностью Speculative Store Bypass является возможность её использования с помощью скриптов внутри приложений. Другими словами, злоумышленники могут оставить вредоносный JavaScript-код прямо на веб-странице, а пользователь при её посещении тут же окажется в опасности. Хакеры могут получить доступ к данным, хранящимся в памяти браузера. Это может быть история поисковых запросов, адреса, данные банковских карт и прочее.


    Однако, данная уязвимость была найдена в ноябре 2017 года, а Intel уже выкатила бета версии микрокода для OEM производителей чтобы те обновили свои продукты. Как и в случае Spectre и Meltdown приведет к потере производительности на 2 — 8%, по данным теста SYSmark 2014 SE. Апдейты пакетов с ядром собраны для RHEL и Ubuntu, и ожидаются для SUSE и Debian.


    «Мы продолжаем работать с затронутыми производителями процессоров и уже предприняли более глубокие меры защиты для устранения уязвимостей вредоносного исполнения в наших продуктах и ​​сервисах. Нам неизвестен какой-либо экземпляр, использующий этот эксплойт, который бы влиял на Windows или нашу инфраструктуру облачных сервисов. Мы стремимся к дальнейшему смягчению последствий для наших клиентов», — рассказал представитель Microsoft.
    Поделиться публикацией
    Комментарии 51
      +3
      2% там, 3% здесь и вот — «Покупайте наши новые процессоры, они производительнее на 20% по сравнению с предыдущим поколением!».
        0

        Молодцы! Идут по стопам Apple. А что мне делать с моим ноутбуком на 6700k? Процессор без всего остального не поменять, сокет в 8700k другой, а в следующем поколении опять наверное изменят, да даже один только процессор не дешевый.
        А есть где то сравнение скорости версий Windows 10 на одном и том же железе, типа 1803 vs 1703?

        +1
        Говорят, этих уязвимостей не меньше семи — и три из них похлеще январских будуть… ;)
        +3
        Производительность новых процов еле растет, так давайте старые затормозим. Хороший маркетинговый ход, с далека зашли.
          +2
          Попробую намекнуть прямо — эти уязвимости относятся ко всем предыдущим поколениям, примерно за 10 лет…
            +2
            Так вообще замечательно! Даже старенькое железо, исправно крутящее простенькие задачки, менять придется. Это же какие продажи внезапно попрут.
            Но вообще конечно не особо приятные новости для различных сервисов. Цены немного подрастут, а кто-то и вовсе закроется. Остается лишь надеяться, что патчи будут раньше крупных утечек данных.
              +5
              Да не будет ничего. Уязвимость слишком трудно использовать и слишком дорого исправлять.
                +1
                Ой, да какой только фигней люди не страдают совершенно бесплатно. Что уж говорить при наличии финансового интереса. Если информация действительно ценная, принцип «неуловимого Джо» может и не сработать.
            +1
            «Старые и новые» вы хотели сказать. Отличный маркетинг — покупайте наши уязвимые процессоры, других всё равно нет.
              0
              Я же говорю, большой задел на будущее, сейчас будем потихоньку снижать производительность этих, а потом выйдут новые исправленные и их хорошо можно будет продавать.
            +1
            Скоро придётся им половину, если не больше, внутрипроцовых ускорителей исполнения убирать, ибо все они основываются на возможности сделать что-то заранее и имеют побочные эффекты на тайминги (ускорение же). И окажется что честно и без этих дыр можно работать на частоте не больше чем частота выборки из оперативной памяти (а это в лучшем случае сотни МГц). Ну ещё можно дать софту (или ОС) явную адресацию процессорного кеша как ещё одной области физической памяти, чтобы ОС, которая уже знает кого от кого надо защищать, сама клала в кеш нужные страницы по своему алгоритму. Это наверно будет медленнее чем сейчас (хотя в теории там можно сделать и более хороший алгоритм под конкретные нужды), но быстрее чем на частоте памяти.
              –1
              Достаточно сбрасывать спекулятивно загруженную строку кеша.
                +2
                Недостаточно, потому что загруженная строка вытеснит другую строку, и вытесненную нужно будет восстановить. Иначе можно будет определить, какая строка вытеснена.
                  0
                  Всё ещё хуже — неспекулятивный кеш тоже может что-то раскрыть про код, который его подгрузил. Хотя это эксплуатировать ещё сложнее чем то что имеется, но думаю найти подходящую ситуацию возможно. И закрыть это можно либо проверяя весь код на то, какие побочные эффекты на кеш он делает и насколько они вычислимы сторонним наблюдателем, либо переведя кеш на програмное управление.
                    0
                    Я предлагаю в стадию отката команды, когда обнаружена ошибка доступа, откатывать не только значения регистров, как сейчас происходит, но и состояния строк кеша. Для этого нужно завести пару-тройку «теневых» строк, которые будут подгружаться в спекулятивном выполнении, и коммититься в основной кеш, только если команда завершилась успешно.
                0

                Зачем убирать? Достаточно добавить корректные проверки доступа.

                  +1
                  Они есть. Проблема в том, что проверки доступа для ускорения выполняются параллельно с другими операциями. И, когда проверка говорит «нельзя», параллельные операции уже залезли в кеш.
                    0

                    Не могу назвать эти проверки корректными, если инструкции меняют кэш на основе данных, доступ к которым запрещён.

                      0
                      Проверки сами по себе корректные, но выполнять их надо до запуска основной функциональности инструкции, а не параллельно с ней. Можно отменить конвеер и делать всё строго последовательно, а не брать в работу сразу по 10 инструкций и выполнять их как удобнее, т.е. out-of-order.
                +1
                Там 10% потеряли, тут 8%. Это можно так допатчиться что пределом мечтаний станет запустить «сапера» или «косынку» на самом производительном процессоре.
                  0
                  Зато это будет самый неуязвимый Сапер на свете!!!
                    0
                    Вот тут они и выкатят новые исправленные камни.
                    +4

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

                      +3

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

                        –2
                        Так на них левый софт не запускают же, а если кто-то и доберётся то ничего не поможет. Тут главная уязвимость — открыл страницу и яваскрипт тебя хакнул… вот это не приятно. С остальным можно бороться.
                          +2

                          Приложения банков для удалённого доступа к банковским услугам, вообще-то, запускаются на устройствах пользователей. В том числе и через web.
                          Те же самые устройства часто одновременно используются и для других вещей.
                          Думаю, не нужно объяснять, что разделение адресных пространств процессов — отличная штука, и почему без неё будет, мягко говоря, неудобно.

                      0
                      Отключать обновления или покупать новый камень? Через годик выкатят новые уязвимости и закроют их 50% производительностью камня, вот тогда будет весело.
                        +1
                        По-моему вполне логично, что чем сложнее система, тем больше в ней дыр.
                        И это касается и железа, и ОС, и прикладного ПО.

                        — У нас дыра в безопасности!
                        — Ну хоть что-то у нас в безопасности.
                          0
                          Найдена новая уязвимость в процессорах

                          Однако, данная уязвимость была найдена в ноябре 2017 года, а Intel уже выкатила бета версии микрокода для OEM производителей чтобы те обновили свои продукты.


                          Апдейты пакетов с ядром собраны для RHEL и Ubuntu


                          Дело Ализара живет.
                            0
                            Meltdown и Spectre были найдены в середине 2017, а патчи выкатили только в январе 2018, да и известно о них обществу стало примерно тогда же.
                            0
                            Такими темпами похоже что придется перейти на i7 просто потому-что с закрытием уязвимостей мощность серии упадет до уровня i5 (а сам i5 упадет до уровня кофемолки). Или вообще перейти на AMD.
                              0
                              В статье же пишут что AMD подвержены тоже.
                                +1
                                Я не в плане защиты от дыр а в плане соотношения цены к мощности, с поправкой на возможность ее использовать (тут нужно вспомнить прошлые АМДшные Bulldozer).
                                  0
                                  Ну так да, согласен.
                                0
                                Во времена когда трава была зеленее, где-то в 2012 году, удивлялся насколько 3770 быстр. Семерка загружалась за 10 секунд с hdd. Все остальное отрабатывало моментально.
                                И вот наступает 2018. Видео на Утубе переходит в полноэкранный режим за секунду (вместо сотен мс). Ощущение, как вы правильно описали, i5.
                                  +2
                                  Вопросы к браузеру и ютубу, а не процессору. Ютуб тормозит, браузеры жиреют.
                                    0
                                    Да. Еще это будет означать что все остальные программы тоже стали работать медленнее.
                                0
                                А нет слухов, появятся ли вообще процессоры, в которых эти типы уязвимостей будут исправлены в железе?
                                  +1
                                  Объясните кто-нибудь пожалуйста, почему возможность точного тайминга операций важна для непривилегированных процессов?
                                    +1
                                    Инструкция чтения текущего такта давно доступна, и неизвестно, что сломается, если поменять её поведение (хотя, если отключить её только у браузера, наверное не будет проблем).

                                    Но, если точный таймер убрать, время можно набирать или тупо статистикой, или выполняя операции в цикле и используя обычные часы.

                                    Другой вариант — запустить 2 потока, второй поток тупо крутит i++ в цикле и таким образом обеспечивает приличную точность.
                                  0
                                  По-видимому, придется инженерам вводить новую сущность — свойство для нитей, которое отключает всю спекулярку и прочие потенциально опасные «ускорялки». Так сказать SecureThreadFlag. И для потенциально опасных приложений, типа браузера, это свойство устанавливать.
                                    0
                                    Такое уже есть — аппаратные memory barriers. В x86 — это lfence/sfence.
                                      0
                                      Т.е. Chrome, когда JIT-тит js, должен после каждой инструкции добавлять LFENCE? Так он быстро вылетит из списка быстрых браузеров.
                                        0
                                        Думаю, удар по производительности будет почти такой же, как и от отключения спекуляции специальным флагом (предлагалось ведь именно это). Все равно в такой ситуации, коду, генерируемому JIT вряд ли получится заполнить все issue слоты.
                                    0
                                    На мой взгляд, вся истерия со Spectre и Meltdown это перекладывание с больной головы на здоровую:
                                    -процессор меняет очередность выполнения в угоду производительности;
                                    -в процессе выполнения оказывается что что нарушено право доступа к памяти;
                                    -процессор генерирует исключительную ситуацию: «тут процесс не туда полез, посмотри»;
                                    -операционная система приложению: «тут процессор говорит что ты не туда полез, на посмотри где ты лажанул» (а раньше приложения регулярно крашились с ошибкой доступа).
                                    Проблема не в том что процессор проверяет право доступа после операции доступа (да хоть 3-4 инструкции пропустит, за это время зловред практически ничего не успеет сделать с парой байтов секретной информации), проблема в том что операционная система в угоду «стабильности» передает не глядя обработку опасного исключения: «самому приложению».
                                    Это как охранник пустит человека который ломится в закрытую дверь: «подождите я вам сейчас открою, тут закрыто», лишь потому что за 30 лет его к этому приучили люди которые постоянно забывают свои ключи или путают двери.
                                      0
                                      Хорошая защита от Meltdown — просто чистить кеши всех уровней при появлении исключения. Заодно говнокодеры, которые делают логику на exception-ах, задумаются.

                                      Однако, от Spectre это не спасает. Когда процессор понимает, что он зашёл не в ту ветку из-за неверно предсказанного перехода, он откатывает регистры без уведомления ОС.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое