CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?

    Что случилось?


    Исследователи Google опубликовали исследование «Reading privileged memory with a side-channel», в котором они описывают найденную ими аппаратную уязвимость, которая затрагивает практически все современные и устаревшие процессоры вне зависимости от операционной системы. Строго говоря, уязвимостей целых две. Одной подвержены многие процессоры Intel (на них проводилось исследование). AMD с ARM также уязвимы, но атаку реализовать сложнее.

    Атака позволяет получить доступ к защищенной памяти из кода, который не обладает соответствующими правами.

    Пожалуй, самое вероятное и неприятное применение на данный момент — получение дампа системной памяти во время выполнения JavaScript.

    Другой интересный вариант — эскалация прав чтения памяти из виртуальной машины. Как вам VPS, который ворует данные из других машин хостера?

    Эксплуатация уязвимости не оставляет следов.

    Насколько это серьезно?


    Это очень серьезно. Мир разделится на «до» и «после». Даже если у вас вообще нет компьютера, отдельные последствия косвенно могут догнать вас в офлайне.

    Как защититься?


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

    Прекрасные новости, это всё?


    Не все. Судя по тестам, патчи сильно повлияют на производительность существующих систем. Тесты показывают падение на 10-30% в некоторых задачах. Да-да, вы все правильно поняли, ваш мак может навсегда стать медленнее, а AWS заметно дороже.

    Дополнительные данные



    Будьте здоровы!
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 524
    • 0
      Тесты показывают падение на 10-30%.
      А, к примеру, эти тесты куда более оптимистичны.
      • +1
        Данные разнятся от задачи к задаче.
        • +5
          syscall'ы выполняются примерно в полтора-два раза медленнее. Если считаешь математику — без изменений, если постоянно делаешь IO — полуторакратная деградация.
          • 0
            А есть результаты тестов?
            Ну или какой-то тест для linux. Я бы сейчас у себя проверил.
            • 0
              Ну вот Phoronix померял. Думаю, завтра уже будет полдесятка таких тестов.
              • 0
                А у вас уже фикс приехал? Я вот в убунте/дебиане пока не вижу. А тест — просто любое интенсивное IO. Например, fio'шный бенчмарк быстрого диска (nvme/ssd), или приложение, шлющее много мелких сетевых пакетов.
                  • 0
                    Да, на федоре ночью зарелизили.
                    sysbench провисает в одном тесте на 30%. Визуально, пока все по старому, больше на io-задачах зависаю, типа клонирования образа.
                    • 0
                      Бедные файловые сервера…
                      • 0
                        Эм… я вообще-то про свой личный ноут писал, если что. И он у меня и до патча подвисал на тяжелых io-задачах.
                        Рабочие сервера обновлять буду не я. Я только проверил, чтобы все работало после апдейта.
                        • 0
                          файлсерверам (если это выделенный сервер, без стороннего кода и виртуализации) пофиг. на них просто не ставится патч.
                          • +1
                            Учитывая тенденцию отказа от выделенных серверов и повального ухода в облака и повсеместной виртуализации, таки не всегда пофик.
                            • –1
                              облачному файлохранилищу (если оно, опять-таки, на выделенном сервере) тоже пофиг.

                              а делать файлохранилище в виртуалке — печаль по просадкам i/o. никто вменяемый таким не занимается.
                              • +2
                                а делать файлохранилище в виртуалке — печаль по просадкам i/o. никто вменяемый таким не занимается.

                                Справедливо только для KVM (за вычетом AHV), так как с VMware или Hyper-V просадка на уровне погрешности.
                                • 0
                                  Справедливо только для KVM

                                  И какой уровень деградации под этим понимается в абсолютной и относительной велечине? +19 us на io, например, это много? А какой уровень тогда у VMware или Hyper-V?
                                  • 0
                                    Циферки потерялись, но разница по иопсам была в районе 20% при одинаковой latency.
                                    Это поправимо, но неизвестно когда что-то подобное включат в обычном KVM.
                  • 0
                    Вот бы было круто, если бы оставили возможность включать/выключать этот фикс когда хочешь — чтобы можно было отключиться от сети и быстренько прогнать IO-intense опеации (например переписать терабайтик данных с одного харда на другой, прогнать вычисления с мемоизацией на диск через shelve или обработать большую HDF5-таблицу через pytables), потом включить обратно и жить спокойно…
              • +4
                geektimes.ru/post/297003

                Разве это не та же новость?
                • +17
                  Та же. Был напуган / редко хожу на гиктаймс.
                  • +6
                    Да у вас, вроде как, новая информация.
                • 0
                  Как-то вообще не объясняется серьёзность проблемы. Сдампить чужую память — это одно, а вот найти в ней что-то полезное — совсем другое.
                  Интересно, можно ли на Windows отказаться от изменений, вызывающих замедление работы. На Linux, вроде бы, можно будет.
                  • +1
                    Насколько я понимаю, можно будет выключить через реестр.
                    • 0
                      Пароли и ключи шифрования в памяти найти относительно просто.
                      Пароль можно просто подбирать из найденного в памяти. У ключей энтропия выше чем у остальных данных обычно, если при этом мониторить трафик, то можно проверять гипотетические ключи.
                      С таким объяснением достаточно серьёзно проблема выглядит?
                      • 0
                        И это всё сможет делать javascript в браузере? Да, я понимаю, что если скомпрометировать популярный сайт, на который зайдёт 100 миллионов пользователей, то у кого-то что-то удастся найти, но в целом — нет, выглядит не очень серьёзно.
                        • +8
                          Из статьи про SPECTRE:
                          Attacks using JavaScript. In addition to violating process isolation oundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by ounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it.


                          В части номер 4.3 есть больше объяснений.

                          Не нужно компрометировать популярный сайт, я прямо сейчас на своём сайте пишу яваскрипт (и даю на него ссылку) который из брауера будет таскать всё что может. У вас несколько вкладок открыто? Даже может быть несколько програм (одна из них — менеджер паролей?), так?
                          А на ссылку, которую я дал, вы нажали? :-)
                          • –5

                            Вообще в том же хроме JS вкладки крутится в её собственном процессе. Отдельном.

                            • +4
                              Дело в том, что уже не в процессах дело. Атака Meltdown позволяет добыть данные из ядра и из других процессов (с некоторыми мелкими оговорками). Без разницы где конкретно данные лежат, в отдельном процессе или в том же самом.
                              • +3
                                Meltdown и Spectre — разные уязвимости. Возможность что-то сделать из JS заявлена только для Spectre (и то, судя по всему, целенаправленно получить какие-то полезные данные именно с использованием JS там практически нереально). Для Meltdown такого не заявлено.
                                • +11

                                  Она позволяет добыть данные из ядра при условии возможности дёргать нужные сисколы и выполнять нужные инструкции CPU в контролируемых условиях. Из JS этого сделать нельзя, но можно сформировать код, который будет через другую уязвимость из перечисленных читать память своего процесса. Разберитесь в механизме работы, а потом делайте заявления.

                                  • –4

                                    Может надо просто написать на js новый Фреймворк и тогда будет можно?

                                    • –4
                                      зачем минусуете? в любой непонятной ситуации надо писать новый js-фреймворк
                              • 0
                                Нужно компрометировать популярный сайт, потому что у вашего сайта посещаемость будет несколько ниже. Это понятно, что можно читать память любого процесса в ОС.
                                • +3
                                  При чем тут посещаемость?
                                  Атака может быть на конкретную группу лиц с использование сайта с нулевой посещаемостью (созданного как раз только для этой атаки).
                          • –1
                            TypeError
                          • +12
                            Старик Столман был всё же прав.
                            • 0
                              Напомните, в чем именно.
                              • +9
                                В том, что опенсорс безопасен. Не может в опенсорсе годами жить незакрытая критическая уязвимость.

                                Был прав.

                                Был.

                                Года так до 2014-го.
                                • +8
                                  Во-первых, Столман говорил о том, что проприетарщина небезопасна. Это не то же самое, что говорить, что опенсурс безопасен. А во-вторых, есть несколько примеров многолетних уязвимостей в опенсурсе
                                  • +1
                                    Вы о HeartBleed?
                                    • +4
                                      Да, как наиболее ярком примере.

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

                                      Применительно к процессорам же опенсорс — это и вовсе смешно, будет примерно как опенсорсные ноутбуки: очень дорого, очень громоздко и по производительности способно на равных конкурировать со средним вайфай-роутером.
                                      • 0
                                        Вы говорите о малосерийном производстве, когда цена еденицы продукции высока, причём тут опенсорс.
                                    • 0
                                      А как же bug 12309?
                                      • 0
                                        12309 все-таки не является багом, связанным с безопасностью (если не рассматривать совпадение обстоятельств приводящее к DoS), да и проявляется в основном на десктопах.
                                        • 0
                                          Про него хоть публично знали.
                                    • +7
                                      Да, Столман-гений (я абсолютно серьёзно). А процессоростроители заигрались с бекдорами и неустойчивыми архитектурами. Я надеялся, что хотя бы на APM/AMD сбежать получится, но некуда бежать, Карл! Получается, даже Байкал дырявый, остался только Эльбрус? На Байкал у моей фирмы денег ещё хватит, а на Эльбрус — не наскребу :(
                                      • +1

                                        А Байкал почему дырявый?

                                        • 0
                                          Он на лицензированном ARM-е сделан. Кстати, к вопросу «зачем изобретать велосипед своей архитектуры?»
                                          • +4
                                            Вообще-то на MIPS P5600.
                                            • +1
                                              Посмотрел — действительно, рано я запаниковал, Байкалу Т1 пока можно доверять. Тяжело это, когда в ИТ не работа, а ходьба по трясине, нервы ни к чёрту становятся. Спасибо, что поправили меня.
                                              • +1
                                                На Байкале-Т1 все эти баги не работают с гарантией если первые 128МБ памяти (там только 128МБ из первых 512МБ распределены под память) НЕ используются для user приложений. А к user страницам доступ либо через EVA, либо через HIGHMEM. В текущем ядре используется HIGHMEM, осталось только запретить рапсределять первые 128МБ под страницы user.

                                                Такой запрет, кстати, ускорит работу с DMA, так как не нужен будет второй cache flush.
                                              • +3
                                                Разобрался.
                                                Есть Байкал-Т1 MIPS P5600 www.baikalelectronics.ru/products/T1
                                                а есть Байкал-М, он на ARMv8-A www.baikalelectronics.ru/products/M
                                                Второй для меня, естественно, теперь умер.
                                              • 0
                                                в тырнете есть кучи проектов процов, например, на основе ПЛИС, только кто для них будет оськи адаптировать… есть сайты, где ссылки на такие проекты собраны десятками, если не сотнями, у каждого проца своя разрядность, программная модель, аппаратная архитектура и система команд.
                                                • +2

                                                  opencores.org и там не все так плохо. Многие ядра пытаются поддерживать wishbone и быть хоть с чем—то совместимым. Вон, OpenRISC даже в космосе побывал и для него есть полноценный тулчеин, даже сборка линукса, а он вроде как даже не самый продвинутый среди открытых архитектур. Проблема в другом — если говорить про асик— нет гарантий, что на заводе ничего в него не дошьют, да и это очень дорого. Если говорить про плис — либо чертовски медленно, либо чертовски дорого (как правило, и то, и другое, если говорить про построение архитектуры общего назначения на плис), да ещё и не на каждую плисину влезет полноценная soc. Но я давно мечтаю собрать на основе маленькой платы с плис типа такой какой-нибудь openphone с чертежами для 3D принтера

                                                  • +1
                                                    А потом Вы будете подозревать компилятор/синтезатор и т.п.
                                                    А так есть же LEON…
                                            • +2
                                              SPARC наше всё :)
                                              • +1
                                                А разве SPARC не всё?
                                                • +2

                                                  RISC наше всё :)

                                                  • +2
                                                    ARM тоже уязвимы окзались
                                                    • 0
                                                      вроде бы не все. только относительно свежие.
                                                      сильно древние неуязвимы
                                                      • 0
                                                        Cortex-A55 свежее некуда. Проблем нет. В то время как древний Cortex-A8 уязвим.
                                                        • 0

                                                          как Неуловимый Джо :)

                                                          • +1
                                                            Нет, тут другая история. ARM только недавно занялся спекулятивным исполнением, которое на x86 появилось в Pentium Pro в 20 лет назад.
                                                    • 0
                                                      как говорил Егор Гайдар: «Отнюдь»… нынешний М8 только вышел и ещё лет 3-5 будет в теме, а там и ещё что нибудь появится, плюс Фуджи свой 12-й выкатили тоже недавно, так что мои заказчики вполне себе интересуются возможностями SPARC/Solaris, поддержка официально до 2030+
                                                      • 0
                                                        Ещё МЦСТ грозится в обозримом будущем родить R2000 и иже с ним.
                                                  • 0
                                                    Что насчёт IBM Power?
                                                    • +6
                                                      Additional exploits for other architectures are also known to exist. These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian).

                                                      access.redhat.com/security/vulnerabilities/speculativeexecution
                                                      • +8
                                                        Есть такой анекдот про поручика Ржевского и оральный секс.

                                                        В общем, если у процессора кэш и предсказание ветвлений есть, то Spectre ваш.
                                                        • +5
                                                          В общем, если у процессора кэш и предсказание ветвлений есть, то Spectre ваш.
                                                          Спекулятивное исполнение и точный таймер нужны…
                                                          • 0
                                                            А какой таймер используется? мультимедийный? а если его отключить, вон в Win XP SP2 на него драйвера вообще нет, в SP3 драйвер есть, но он не используется.
                                                            • –1
                                                              Обычно пользуется RDTSC. Но при наличии нескольких ядер можно и просто счётчиком обойтись…
                                                          • 0
                                                            Напомните, плз)
                                                            • +21
                                                              — Господин поручик — вы, говорят, большой специалист в этих делах. Скажите, вон та дама в рот берет?
                                                              — Которая? — переспрашивает Ржевский.
                                                              — Вон та, в желтом платье.
                                                              — Ну, я со спины сказать не могу, — пожимает плечами поручик. В этот момент дама поворачивается, поручик Ржевский пристально смотрит ей в лицо и говорит:
                                                              — Эта — берет.
                                                              Корнет подходит к даме, они о чем-то беседуют и удаляются. Через некоторое время корнет возвращается, довольный:
                                                              — Действительно, берет! Но как вы определили, поручик?!
                                                              — Послушайте, корнет, — веско произносит поручик Ржевский, — Рот есть — значит берёт!

                                                              Примерно та же история с процессорами и Spectre.
                                                              • 0
                                                                > Примерно та же история с процессорами и Spectre.

                                                                Если права доступа к страницам ядра проверяются ДО запуска подгрузки в кэш, то остается только eBPF, который сам по себе бяка (JIT в ядре!). К тому же он кажется требует привелегий. Гуглы вроде не нашли в текущем коде ядра Linux подходящих последовательностей помимо возможности сформировать их через eBPF.
                                                                • 0
                                                                  Тут два момента.

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

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

                                                                  Так что eBPF просто радикально облегчает задачу, но не более того.
                                                                  • 0
                                                                    DLL? С учетом того, что их пишет кто попало… там и просто так можно такой код зафигачить, что никакого meltdown/spectre наверно и не надо.
                                                                    • 0

                                                                      Имеется ввиду, что системные и широкораспространённые DLL уже содержат нужные последовательности инструкций. Злоумышленнику даже не нужно свой код на вашу машину тащить, всё нужное там уже есть.

                                                      • +1
                                                        и вдруг в этот момент шутки про Эльбрус уже не так смешны. И получается что оборонка в РФ, где используется Эльбрус работает, а остальной мир — нет (конечно я про фантастический рассказ).
                                                        • +1
                                                          о том какие косяки есть в оборонке и Эльбрусе просто меньше народу знает также как и меньше народу вообще их там ищет. Так что шутки актуальны
                                                          • 0
                                                            Правильно сделали что ушли на свой Эльбрус.
                                                        • +4
                                                          Конечно прав.
                                                          Но недостаточно быть правым, надо и альтернативу предлагать, причем не абы какую, а экономически жизнеспособную.

                                                          Более того, Столлман сам использует закрытое железо: Thinkpad T400s.
                                                          И процессор у него Core 2 Duo SP9400, который тоже может быть подвержен этой уязвимости.
                                                          • 0
                                                            Верно, Столлман критиковал Intel за ME, которого в его процессоре нет. Об этой уязвимости он не говорил, но и его процессор попал под раздачу.
                                                            • +1
                                                              Столлман не пользуется JS.
                                                              • +1
                                                                Да он и браузером толком не пользуется. У него вообще там какой-то странный выход в Интернет.
                                                            • 0
                                                              Помню он заявлял, что использует китайский ноутбук на MIPS с открытым BIOS.
                                                              • +1
                                                                Проапгрейдился. По ссылке же написано:
                                                                Before that, I used the Lemote Yeeloong for several years.
                                                          • 0

                                                            А где-то есть список подверженных этому CPU?

                                                            • +9

                                                              Все интел, выпущенные за последние 10 лет :)

                                                              • +1
                                                                Кроме Атомов до 2013 и Итаниумов
                                                                • 0
                                                                  Т.е. если машина старше 10 лет, то 100% проблемы нет? И если АМD до 13-го года?
                                                                  • +1
                                                                    На АМД нет Мелтдауна, только Спектра
                                                                    • 0
                                                                      Вам теперь тоже придётся реализовать защиту?
                                                                      • +1
                                                                        Пока в этом нет особой необходимости.
                                                                        Спектра исправляется\локализуется на стороне каждой прикладной программы в отдельности. А Мелтдаун опасен в основном для многопользовательских систем с множественным доступом различных субьектов, между которыми нет доверия. У РеактОСа же в самой ближайшей перспективе наиболее реалистичные сценарии использования предполагают однопользовательский доступ в изолированных сегментах инфраструктуры.

                                                                        Еще важно отметить, что в РеактОС существующие средства доставки и инжекции вредоносного ПО на данный момент не способны выполнить свою функцию.

                                                                        Безусловно, в дальнейшем определенные механизмы безопасности будут внедрены, а пока мы посмотрим, как с этим справятся остальные вендоры и воспользуемся их опытом.
                                                                        • 0
                                                                          Спектра исправляется\локализуется на стороне каждой прикладной программы в отдельности.

                                                                          Ну если быть честным, то спектру нельзя исправить чисто программно, можно только минимизировать возможность атаки (ну или снизить вероятность что-ли)…
                                                                          Или вы действительно считаете, что уменьшением точности таймера (как превентивно сделали например в некоторых браузерах) или перекомпиляцией софта (дабы заменить уязвимые последовательности) вы исключите фактор атаки? Ну-ну...


                                                                          Еще раз, — спектру практически невозможно полностью закрыть программно, от слова совсем, пока во всяком случае. Еще менее реально закрыться от возможных будущих подобных "уязвимостей". Только если есть возможность как-то отключить branch prediction (например для потока "исполняющего" javascript и/или потенциальный "чужой" код). Или выключить кэши процессора, ну или написать что-то типа "антивирус для процессора" (это сарказм если что).


                                                                          Кроме того уже сейчас нужно различать те-же CVE-2017-5715 и CVE-2017-5753 (например для 5715 нужен еще и микрокод-update, т.е. чисто программно у вас шансов "защититься" просто нет).
                                                                          А ящик пандоры только-только открылся — я к тому что завтрашний зоопарк возможных CVE-дериватов, эксплуатирующих такие и подобные им дыры (т.е. speculative execution и иже с ними), пока сложно себе представить.
                                                                          Но то что он будет, это однозначно.

                                                                          • 0
                                                                            Спектр:

                                                                            Интел предлагает вставлять LFENCE после условного перехода для фикса Варианта-1, и использовать команды PUSH + RET вместо перехода по регистру. Вроде LLVM/gcc уже даже патч есть.
                                                                            • 0
                                                                              Что это значит? Изменение (хорошее замедление) всех jit-компиляторов, чтобы они случайно не сгенерили опасный код из пользовательского js. Очень интересно, как это понравится разработчикам браузеров, которые очень упорно соревнуются друг с другом за каждый процент скорости js. «Наш движок, конечно, медленный, зато он защищён от Spectre»?

                                                                              Но если у атакующего — возможность выполнять свой код с минимальными привилегиями, то зачем ему в свой код вставлять LFENCE?
                                                                              • 0

                                                                                А теперь берем и внимательно читаем "правильную литературу" про спектру, например здесь особливо пункты 7-й и 8-й.


                                                                                Если коротко, про то чего вам тут Intel предлагает: а) этим всё не исправить и история далеко не окончена, и б) хочется спросить — они это вообще серьезно?! Если это правда предложение инженеров Интел (а не отмазка какого-то "продажника")… тогда все еще хуже.

                                                                      • +1

                                                                        Там пишут, что предположительно вообще все когда либо выпущенные 86 процессоры Интел с спекулятивным исполнением. А это с 95 года. Просто в стоей работе авторы продемонстрировали уязвимость на сравнительно новых процессорах.

                                                                    • +1

                                                                      Еще бы помнить когда он выпущен.

                                                                      • +1
                                                                        ark.intel.com поможет.

                                                                        Но, на самом деле, сложно выяснить есть ли в том или ином процессоре этот баг т.к. потроха процессора закрыты и как он обрабатывает инструкции — покрыто мраком.

                                                                        Единственный выход, который мне видится — запускать PoC эксплоит (найти бы его еще) на каждом из них и смотреть результат.
                                                                      • 0
                                                                        Все интел 1995 года (кроме атомов до 2013 и итаниумов). meltdownattack.com
                                                                      • +81
                                                                        Вот например на П4 дыру вообще видно невооруженным взглядом:
                                                                        image
                                                                        • +9
                                                                          Так вот почему Интел процессоры пытался в картриджи прятать…

                                                                          image
                                                                          • 0
                                                                            Это у вас бракованный, сдайте по месту покупки.
                                                                          • 0
                                                                            Это старая, для неё давно уже патч есть.
                                                                            • +3
                                                                              Для того, чтобы произвести запись в write-protected защищенную область, отверстие надо заклеить изолентой?
                                                                            • +2
                                                                              Red Hat пишет о существующих эксплойтах для IBM System Z, POWER8 и POWER9.
                                                                              • +3
                                                                                Вот единственная конкретика, которую удалось найти на сайте intel.
                                                                                Which Intel-based platforms are affected by or vulnerable to the issue?
                                                                                The following Intel-based platforms are impacted by this issue. Intel may modify this list at a later time.

                                                                                Please check with your system vendor or equipment manufacturer for more information regarding your system.

                                                                                Intel® Core™ i3 processor (45nm and 32nm)
                                                                                Intel® Core™ i5 processor (45nm and 32nm)
                                                                                Intel® Core™ i7 processor (45nm and 32nm)
                                                                                Intel® Core™ M processor family (45nm and 32nm)
                                                                                2nd generation Intel® Core™ processors
                                                                                3rd generation Intel® Core™ processors
                                                                                4th generation Intel® Core™ processors
                                                                                5th generation Intel® Core™ processors
                                                                                6th generation Intel® Core™ processors
                                                                                7th generation Intel® Core™ processors
                                                                                8th generation Intel® Core™ processors
                                                                                Intel® Core™ X-series Processor Family for Intel® X99 platforms
                                                                                Intel® Core™ X-series Processor Family for Intel® X299 platforms
                                                                                Intel® Xeon® processor 3400 series
                                                                                Intel® Xeon® processor 3600 series
                                                                                Intel® Xeon® processor 5500 series
                                                                                Intel® Xeon® processor 5600 series
                                                                                Intel® Xeon® processor 6500 series
                                                                                Intel® Xeon® processor 7500 series
                                                                                Intel® Xeon® Processor E3 Family
                                                                                Intel® Xeon® Processor E3 v2 Family
                                                                                Intel® Xeon® Processor E3 v3 Family
                                                                                Intel® Xeon® Processor E3 v4 Family
                                                                                Intel® Xeon® Processor E3 v5 Family
                                                                                Intel® Xeon® Processor E3 v6 Family
                                                                                Intel® Xeon® Processor E5 Family
                                                                                Intel® Xeon® Processor E5 v2 Family
                                                                                Intel® Xeon® Processor E5 v3 Family
                                                                                Intel® Xeon® Processor E5 v4 Family
                                                                                Intel® Xeon® Processor E7 Family
                                                                                Intel® Xeon® Processor E7 v2 Family
                                                                                Intel® Xeon® Processor E7 v3 Family
                                                                                Intel® Xeon® Processor E7 v4 Family
                                                                                Intel® Xeon® Processor Scalable Family
                                                                                Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series
                                                                                Intel Atom® Processor C Series
                                                                                Intel Atom® Processor E Series
                                                                                Intel Atom® Processor A Series
                                                                                Intel Atom® Processor x3 Series
                                                                                Intel Atom® Processor Z Series
                                                                                Intel® Celeron® Processor J Series
                                                                                Intel® Celeron® Processor N Series
                                                                                Intel® Pentium® Processor J Series
                                                                                Intel® Pentium® Processor N Series
                                                                            • +8
                                                                              лучше отключите JavaScript даже при посещении безопасных сайтов

                                                                              Нормально пользоваться Хаброй с отключённым JS — возможно?
                                                                              (не говоря уже об обычных сайтах сплошь увешанных js)

                                                                              • –18
                                                                                Тут уже вы сами решайте что вам надо — рюшечки на сайтах или безопасность
                                                                                • +29

                                                                                  Проблема в том, что js — уже давно далеко не «рюшечки на сайтах», а основной функциональный элемент, отключение которого смерти подобно (этого самого сайта).

                                                                                  • –17
                                                                                    Опять же — сами решайте что вам важнее
                                                                                    • +21
                                                                                      В нашем мире можно удалить браузер, а не выключать JS. Эффект будет примерно одинаковым. Вы даже комментарии здесь писать не сможете без JS
                                                                                      • 0
                                                                                        А чего все докопались до JS? Его то как раз таки можно быстренько изпоганитьправить :-)
                                                                                        Что видимо и произойдёт в ближайшие дни.
                                                                                        • –5
                                                                                          Ох, я очень надеюсь что эта ситуация выдаст пинка проблеме с JS и его наконец выпилят и заменят на что-то современное, ах мечты-мечты…
                                                                                          • +4
                                                                                            Проблема же не в JS.
                                                                                            • –2
                                                                                              Это в данной ситуации проблема не с JS, а я говорю о JS в целом…
                                                                                              • +2
                                                                                                Так-то да, проблема в принципе в коде, который может исполняться просто от открытия веб-страницы, но JS — самое распространённое зло здесь (менее распространённые — Flash, Java, к примеру).

                                                                                                А без JS хабр вполне возможен, если напишут отдельную версию — сделать простую форму для написания статьи/комментариев.
                                                                                  • 0
                                                                                    Вроде, работает.
                                                                                    • +2

                                                                                      Для хрома Google вроде как рекомендует включить chrome://flags/#enable-site-per-process если у вас версия ниже 64

                                                                                      • 0

                                                                                        И как это спасет?
                                                                                        Это как для защиты от ядерной бомбы используйте бронежилет.

                                                                                        • +4
                                                                                          Спасёт от теоретической возможности утечки данных чужих сайтов с использованием атаки Spectre из JS на каком-нить сайте. Разве что сам у себя сайт сможет что-то подглядеть случайно :)
                                                                                        • +8
                                                                                          Chrome втихаря ставит свой software reporter tool, который начинает шариться по всем дискам без всяких уязвимостей.
                                                                                          • +3
                                                                                            Гугл не был бы Гуглом, если бы не индексировал всё, до чего может дотянуться.
                                                                                            • 0
                                                                                              Ещё и скачивает втихаря, если не заблокирована запись в профиль\SwReporter средствами системы.
                                                                                              • +1

                                                                                                А что с клонами Хрома? Вивальди и Новой Оперой?

                                                                                                • 0
                                                                                                  SwReporter — фишка конкретно гуглохрома. Но другие вендоры вполне могут вставить свои бэкдоры…
                                                                                            • 0

                                                                                              Интересно, что будет если отключить WebWorker-ы?

                                                                                            • +1

                                                                                              Интрига дня/недели: подвержены ли процессоры Apple?

                                                                                              • +7
                                                                                                Разве Apple вернулась на Motorolla в своих дескотпах/ноутбуках?
                                                                                                • +5

                                                                                                  Речь про iPhone/iPad — Apple для них пилит свои ARMv8 -совместимые процессоры. У оригинальных ARM Cortex-Axx самой опасной уязвимости (чтение памяти ядра/других процесов) подвержены только Cortex-A75.


                                                                                                  Информации об наличии/отсутствии проблем в процессорах Apple-A пока нет. Ждем!

                                                                                                • +1
                                                                                                  У Apple те же самые интеловские процессоры — поэтому да, конечно.
                                                                                                  • +5
                                                                                                    • 0
                                                                                                      Одна из атак (Spectre) работает на ARMах тоже, но я не знаю про те конкретные которые iPhone/iPad.
                                                                                                      • 0

                                                                                                        Spectre с большой вероятностью работает на всех ipad/iphone. Практически все современные ARM ядра ей подвержены.
                                                                                                        Meltdown подвержены только ядра ARM Cortex-A75 (на них еще нет выпущенных процессоров)
                                                                                                        Однако, Apple не использует готовые ядра Cortex, а разрабатывает ядра сама. На текущий момент нет информации об атаке Meltdown на ARM ядра Apple. Вот ждемс информацию.

                                                                                                  • 0
                                                                                                    думается Pentium MMX и прочие древности наверное не подвержены, но что нам с того?
                                                                                                    • +1
                                                                                                      Apple уже выпустила заявление, отвечающее «да».
                                                                                                      • 0
                                                                                                        И оценка снижения производительности от использования заплаток очень приятна. Практически в пределах погрешности.
                                                                                                    • +4
                                                                                                      Пожалуй, самое вероятное и неприятное применение на данный момент — получение дампа системной памяти во время выполнения JavaScript.
                                                                                                      Больше похоже на заявление от представителей жёлтой прессы. Низкоуровневые операции (типа получения данных по произвольному указателю), которые скорее всего будут нужны для эксплуатации уязвимости, из JS недоступны. В общем, или покажите рабочий пруф, или не распространяйте сомнительную информацию и не нагнетайте бесполезную панику.
                                                                                                      • +2

                                                                                                        В первоисточнике есть JS сниппет, который читает память процесса браузера https://spectreattack.com/spectre.pdf, эта ссылка есть в статье...

                                                                                                        • +3
                                                                                                          Во-первых, рабочего кода там нет. Там есть только вот эти 5 строк, которые лишь маленький кусочек необходимого кода (содержимое остального кода там описано словами и очень примерно):
                                                                                                          if (index < simpleByteArray.length) {
                                                                                                              index = simpleByteArray[index | 0];
                                                                                                              index = (((index * TABLE1_STRIDE)|0) & (TABLE1_BYTES-1))|0;
                                                                                                              localJunk ^= probeTable[index|0]|0;
                                                                                                          }
                                                                                                          Во-вторых, чтение памяти своего процесса (где живёт вкладка) и получение дампа всей системной памяти — разные вещи. В-третьих, не заявлено, что можно целенаправленно прочитать всю память своего процесса из JS. Как я вижу, с использованием этой методики максимум могут быть сделаны выводы о содержимом каких-то случайных блоков памяти своего процесса, в зависимости от того куда при выполнении JS была физически помещена переменная массива.