В дизайне процессоров Intel выявлена фундаментальная ошибка, которая требует внесения значительных изменений в ядра операционных систем Linux, Windows и macOS для устранения уязвимости на уровне чипа. Обновление микрокода чипа не позволит устранить проблему. Решить её можно только через программное обновление операционных систем или же путём покупки нового процессора, в котором нет ошибки в дизайне.
В дизайне процессоров Intel выявлена фундаментальная ошибка, которая требует внесения значительных изменений в ядра операционных систем Linux, Windows и macOS для устранения уязвимости на уровне чипа. Обновление микрокода чипа не позволит устранить проблему. Решить её можно только через программное обновление операционных систем или же путём покупки нового процессора, в котором нет ошибки в дизайне.
Программисты наспех вносят изменения в систему виртуальной памяти ядра Linux. В Microsoft также уделили особое внимание данной проблеме и распространили соответствующее обновление Windows среди участников программы тестирования Windows Insider в ноябре и декабре. Выход исправления для всех пользовательских систем запланирован на ближайший «Вторник патчей». В результате установки этих обновлений производительность систем с процессорами Intel в ОС Linux и Windows существенно снизится. По предварительным оценкам, в зависимости от типа выполняемых задач и модели процессора, падение производительности составит от 5% до 30%. В более новых версиях чипов содержатся функции, такие как PCID, которые позволят уменьшить негативный эффект снижения производительности.
Пока что подробности об уязвимости в дизайне процессоров Intel не разглашаются. Вероятно, подробные сведения будут опубликованы для общественности после массового выпуска обновлений для операционных систем. На текущий момент о проблеме известно немного. Однако сообщается, что ошибке подвержены современные процессоры, выпущенные на протяжении последнего десятилетия. Из-за ошибки в дизайне ряд пользовательских программ – от приложений для работы с базами данных до JavaScript в браузерах – могут получать доступ к защищённым участкам памяти ядра. Как минимум, вредоносное ПО и хакеры могут воспользоваться этой ошибкой для более простого использования других ошибок безопасности. В худшем случае ошибка может позволить прочитать содержимое памяти ядра, в котором, среди прочего, могут содержаться конфиденциальные сведения о логинах, паролях, секретных ключах и т.д. Программное устранение ошибки заключается в том, что память ядра полностью изолируется от пользовательских процессов, использую KPTI (Kernel Page Table Isolation).
В процессе работы программ для выполнения своих задач (например, для записи данных в файл или открытия сетевого соединения) им всякий раз необходимо передать ядру управление над процессором. Для наиболее быстрого и эффективного перехода от пользовательского режима к режиму ядра и обратно, ядро присутствует во всех адресных пространствах виртуальной памяти всех процессов, хотя для самих программ оно невидимо. Когда ядро необходимо, программа выполняет системный вызов, процессор переключается в режим ядра и получает доступ к нему. Когда необходимая задача выполнена, процессор получает команду переключиться обратно в пользовательский режим и заново войти в процесс. В пользовательском режиме код и данные ядра остаются вне поля зрения, но присутствуют в таблицах страниц процесса.
Новые обновления для операционных систем переводят ядро в полностью изолированное адресное пространство. В результате, оно становится не только невидимым для запущенных процессов, а полностью отсутствующим в доступных для них адресных пространствах. На самом деле такой подход является ненужным, но из-за ошибки в процессорах Intel он становится необходимым для обеспечения безопасности. Недостатком такого разделения является тот факт, что для переключения между отделёнными адресными пространствами теперь потребуется значительно больше времени для каждого системного вызова и каждого аппаратного прерывания. Для каждого такого переключения теперь потребуется, чтобы процессор полностью выгрузил кэшированные данные и загрузил информацию из памяти. Это приводит к увеличению накладных расходов на работу ядра и замедлению компьютера. В результате, системы на базе процессоров Intel будут работать медленнее.
И на что теперь ориентироваться?... На производительность, или безопасность?
Xeon, так понимаю, тоже содержат уязвимость... А наспех накатанные патчи, возможно, приведут к нестабильном поведению некоторых программ и системы в целом...
проблема в другом.
80% или более стоят пиратки)
... и никакие обновления поставлены не будут..
На AMD или Эльбрус ))
Эльбрус или Байкал ???
мутно как то это
ну если мутно, то на зизитру.
ох и строгие дядьки )).
А есть тут кто из математиков? В чем интел просчитался ?
Походу AMD вырвется в топ по всем бэнчмаркам, где куча системных вызовов. А ОС с kqueue (*BSD, macOS) покажут еще больший отрыв на бенчмарках сетевых приложений, т.к. epoll требует больше системных вызовов на каждое соединение.
Но вообще, конечно, это мало на что повлияет на практике.
Так а в каких процессорах ошибка?
Точно не у амд.Кароч, коллизия с параллелизмом ? Так какая математическая башка в интеле сделала ошибку ?
Там же если все ниже и ниже спускаться сплошная математика.
ОФФтоп
Человеческий фактор ?
Обычный баг, да, как и все баги - человеческий фактор. В процессорах часто бывают баги.
Никакая ошибка в схеме процессора в ПРИНЦИПЕ не может сказываться на дырах в программном обеспечении. Это разные и совершенно не связанные явления.
Это за туманными фразами, рассчитанными на неграмотного обывателя скрывается очередной лохотрон - выкачать по новой деньги из всех пользователей INTEL за псевдообновление.
А вообще... INTEL - явно не самая лучшая архитектура. процессора. Это было ясно еще на стадии первых моделей, лет 25-30 назад.
Но реклама - страшной пробивной силы инструмент...А умение делать процессоры и умение их продавать - тоже совершенно разные профессии
Если результат выполнения инструкции не соответствует её описанию в документации - возможны любые последствия и любые же уязвимости в ПО.
Это как, при чем тут дыры в программном обеспечении? Тут как бы вся суть, что архитектура дает всякие обещания, которые иногда не работают, что в худшем случае приводит к уязвимостям. Хорошо, что некоторые хоть можно затыкать программно, но так не всегда бывает. Бывает, что можно только выкинуть, ибо затыкание приведет к потере основной функции.
10-ти летиями не видеть баг ? бред. Просто опыт эпла с занижением производительности старых устройств он заразен.
Толсто намекают, что пора нам покупать новые процы, а то мы зажрались:
чай в пакетиках завариваем один разне хотим ежегодно брать одну и ту фигню в разных обертках, причем обязательно каждый год с новым, е$#ть его в рот, сокетом, старый видите ли за год типа "устаревает" и нужно кровь из носа обязательно брать новый сокет и новую мать под него, чтобы интел еще и на продаже чипсетов руки грел.А может, это всё часть глобальной стратегии АМД по возвращению на широкий рынок. Эдак, знали у них про эту "уязвимость", и чтобы показать как очередное преимущество своих процессоров выкатили сабж в паблик
/параноик_мод
Уже и первые тесты заплаток есть https://3dnews.ru/963636
Похоже для маршрутизаторов и всего активно юзающего ядро/переключение контекста удар будет очень ощутимый, а для userspace приложений - нулевым.
А тем временем, акции амд растут, а интел просели, гыгы
Так вообще-то, или может быть ? От бл@#ь гений всезнающее око. Ты еще скажи что по модели OSI с 1 на 4 можно сразу прыгать. В основе каждого технологического процесса в электронике, а особенно в проектировании CPU лежит фундаментальная наука. По идее какой-то индус где-то в доке просчитался. Наверное !? )))
Можешь и дальше звать меня гением, приятно))
Ну збс. Я тогда еще в садик ходил. Ну ты похвастайся еще чем-то. Напугай страшными словами Это, бывает, надо
.
Процессор, это помимо логической части еще и физика. И ты, как знавець низкоуровневых языков знаешь, что одно от другого неотделимо. Таки вот и интересно, что за ошибка )). Там не с военными заморочками приколы хоть )). Вот у цисок то "жучки" найдены, китайцы ж не просто так от них отказались )).
Intel Responds to Security Research Findings
newsroom.intel.com/...ings/
Официальная инфа по уязвимостям:
googleprojectzero.blogspot.com/....html
Variant 1: bounds check bypass (CVE-2017-5753)
Variant 2: branch target injection (CVE-2017-5715)
Variant 3: rogue data cache load (CVE-2017-5754)
A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.
A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]
A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)
A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.
Spectre (variants 1 and 2): https://spectreattack.com/spectre.pdf
Meltdown (variant 3): https://meltdownattack.com/meltdown.pdf
security.googleblog.com/....html
support.google.com/...22138
Похоже все хуже, чем казалось. Все процессоры интел, амд, арм подвержены уязвимостям, позволяющим читать данные внутри процесса и пофиксить это нельзя. А интелы (все) позволяют еще и изоляцию памяти обойти и читать память ядра, но это хоть можно пофиксить. Правда рисерч продолжается, возможно со временем найдут такое же и для амд и для арм.
Реальный фикс возможен только новыми процессорами, которые еще не разработали
twitter.com/...86752
чувак демонструє на відео баг (убунта)
Пошла моча по трубам...
Ждем эксплоитов для удаленных манипуляций
На вулнерсе пока тишина ?
Вчера народ уже игрался с javascript PoC эксплоитом.
в хроме есть такая вещь как изоляция процессов
спасает?
Ну как спасает, если обновились и в ядре уже есть фикс от варианта 3, то левые сайты смогут только внутри своего процесса читать память, но все равно обходя сэндбокс хрома. А так всегда лучше просто держать javascript отключенным по дефолту и включать только на некоторых сайтах. Локал и многие форумы обычно работают без javascript. Ну и блокировщик рекламы и трекинга, а то даже на тех сайтах, где javascript придется включить всякая гадость может пролезть через это все.
---
Кстати часть процессоров ARM уязвимы еще одному варианту, они назвали его вариант 3а, тоже позволяет читать память ядра, это офицальная инфа уже от самого ARM. И вообще все процессоры с out-of-order уязвимы варианту 1 или 2. Т.к. во времена, когда это все изобрели, о side channel timing атаках никто и не задумывался.
А вот еще патч retpoline для llvm компилятора, защитит от варианта 2 убивая возможность косвенных предсказаний. Добавляет 5%-10% овэрхэд в среднем каждой программе. Правда производительность таки можно вернуть, но только статическими оптимизациями, т.е. превращая эти косвенные предсказания в прямые.
IMHO опасность этих багов сильно преувеличена.
Плакать есть смысл сугубо хостерам - там где на одной машине бегают данные многих пользователей, и утечек данных между ними быть не должно даже теоретически.
Провайдерам эта самая возможность одного процесса прочитать чуть ли не побайтово память чужого процесса не представляет собой какого-либо интереса или опасности.
Не, хостеры обновились и не парятся. Больше всего затрагивает юзеров десктопных/планшетных/телефонных ОС.
а можно ссылку на материал, где говорится про АМД и уязвимость?
Выше постил уже, АМД в Spectre: https://spectreattack.com/spectre.pdf
Hetzner прислал вот такое пока что:
То фигня что акции падают у интела,
через месяц они как сумашедшие попрут вверх, потому что вырастут продажи процессоров.
Просто представьте амазон и то что теперь для обслуживания надо больше мощностей, вы представляете себе, амазон увеличивает свои мощностя на 30 процентов? Там столько камней будет, что цены на процы вырастут по всему миру и будет такая же херня как с видюхами для майнинга.
www.opennet.ru/...shtml
Компанией Google для ядра Linux предложен вариант патчей c реализацией метода "retpoline" для блокирования атаки Spectre. Накладные расходы от данных патчей не превышают 1.5%
[CentOS-announce] CESA-2018:0007 Important CentOS 7 kernel Security Update
CentOS Errata and Security Advisory 2018:0007 Important
Upstream details at : access.redhat.com/...:0007
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
320ab3bd00bd1f051c69f65f2d4cd6ab64585f977d9cd7a52e64e8f8147894fc
kernel-3.10.0-693.11.6.el7.x86_64.rpm
0eefdec5447d3ed2781f30d093e22f4654e8af201e1e8058a57876d1baf2ee64
kernel-abi-whitelists-3.10.0-693.11.6.el7.noarch.rpm
5137d0db8632342edfb355ce5bb0a4b4b80d5ffd4b9950bb8dcfcd78e4b8a9dc
kernel-debug-3.10.0-693.11.6.el7.x86_64.rpm
882a6522bdafaa697173ff7adedd2cd6ceee5c4a6aa0cd1cb4cf042789420c78
kernel-debug-devel-3.10.0-693.11.6.el7.x86_64.rpm
9c0d7753c649d68cd25b212ee573cec37dc2211891444224e502128fcffdf301
kernel-devel-3.10.0-693.11.6.el7.x86_64.rpm
d2005d6a85f2ddd627290dd4cd4d2084215ef45cd8b3f66077b68fe2b0cce61e
kernel-doc-3.10.0-693.11.6.el7.noarch.rpm
34d8682b2df1e47c9675f913fbfb129420cce219beaf7985c607a69ccdb3e064
kernel-headers-3.10.0-693.11.6.el7.x86_64.rpm
fd3eaf598546bcb502e5e7293d0301b48774c9358dd320b7e53bd042dfae7094
kernel-tools-3.10.0-693.11.6.el7.x86_64.rpm
3c53034adc4c942a02f1dd72f0adf688f558867caf086b5b239169262b75f570
kernel-tools-libs-3.10.0-693.11.6.el7.x86_64.rpm
91153ae59d0acf585201b9a5b453ed8e6504651bf114e3c21c725ce42c8675c5
kernel-tools-libs-devel-3.10.0-693.11.6.el7.x86_64.rpm
8ef1d6c1ef77af60bbb680fa58b1d15f7901c21220c7e5db05edbbbb56f7b17c
perf-3.10.0-693.11.6.el7.x86_64.rpm
b1f7bf92063bce0cec6286845686bc6ef96db126bdaa8987703b21a736a1a509
python-perf-3.10.0-693.11.6.el7.x86_64.rpm
Source:
b7756ceda51a35942e03d553f0ec6049ba2520c89e0d66e8e2cdae88f6db0d6a
kernel-3.10.0-693.11.6.el7.src.rpm
Note:
1) This is a widespread issue with potentially huge impact, we
appreciate any help in spreading the word around so maximum number of
users are able to find out, and patch their systems.
2) Upstream is curating information around this issue at
access.redhat.com/...ution
- information on that page would be helpful for most people on CentOS
Linux as well.
3) Please reach out to us at #centos on irc.freenode.net for any
feedback, comments, questions or concerns.
lists.centos.org/....html
Подробнее о том, что с какой уязвимостью делать:
security.googleblog.com/....html
Variant 1: bounds check bypass (CVE-2017-5753): Анализ и перекомпиляция бинарника, чтобы уязвимый код не генерировался.
Variant 2: branch target injection (CVE-2017-5715): Обновление микрокода процессора или софтово, используя патч Retpoline пересобрать ядро и программы по надобности.
Variant 3: rogue data cache load (CVE-2017-5754): Патчить ядро операционной системы патчем Kernel Page Table Isolation.
Ну и замечу, что гугл не обнаружил значительной деградации производительности ни от какого патча.
Еще новое: Никакие Raspberry Pi не уязвимы ни к Meltdown, ни к Spectre, т.к. используют только in-order процессоры. Аналогичные процессоры у интела, которые еще могут быть у кого-то в использовании - это старые атомы, которые до Silvermont были, тоже in-order и тоже не уязвимы.
По варианту 1 уязвимости могут тоже со временем появиться какие-то инструменты, может сразу в компиляторе, как и retpoline для варианта 2. Интел и сам предлагает статический анализ для этого.
Кому интересно, как компиляторы/интерпретаторы собираются защищаться от Spectre 1 и 2, можете почитать как Webkit защищает Javascript: webkit.org/...bkit/
Где собака на физическом уровне порылась ?
Кеш маппипга страниц виртуальной памяти приложения в физическую. В результате выполнения операций "наперед" в кеш попадает адрес одной из страниц, номер которой соответствует запрошенному байту из памяти ядра. При сканировании страниц она прочитается быстрее остальных.
За останніх років 7 проідуктивність проців виросла на якихось 50%, що дуже мало. Памятаю часи, коли за 1-2 роки компютер ставав застарілим. Наразі моєму процу домашньому десь 6 років. Доставив оперативки до 16 гіг. Купив нову відяху і нові ігри на високих тягне тільки так. От навіщо людям купувати нові проци?
Як тільки я почув про цю новину зразу ж сказав знайомим - відключайте оновлення ос. Думаю багато хто в курсі, що провідні виробники смартфонів випускають оновлення на старі моделі і роблять їх навмисне тормозними, щоб люди бігли купувати новенькі нетормозні айфончики. От тут швидше за все та ж сама історія. Продажі різко впали. Треба стимулювати людей купувати нові компи. Думаю там після того оновлення користуватися взагалі стане нормально не можливо ПК.
Це звичайно не факт, але дуже на те схоже.
Все те обновления, которыми ОС могут повлиять на все программы касаются только Meltdown на интелах и они такие, что влияют на производительность только там, где производительность никакой роли не играет. Т.е. эти страшные бенчмарки - это все равно что мерять насколько быстро велосипедист может ехать по автобану. Но автобан же не для велосипедистов.
А вот со Spectre все не так, кроме ядра, сама ОС ничего защитить не может и уязвимы практически все (ну кроме in-order процессоров). От Spectre можно защититься только каждой программе отдельно, даже обновления микрокода нужны чисто, чтобы дать возможность программам использовать определенные функции процессора. И это все как раз влияет на производительность фундаментально, т.к. многие ветвления в программе могут быть сильно замедлены, особенно если фиксить все это автоматически компилятором. Но в то же время вон Javascript в Webkit придумали как пофиксить без замедления, даже на бенчмарках всего 2.5% просадка, что в реальных условиях вообще ничего. Более того, защита от Spectre защищает и от Meltdown.
И нет, это не заговор, новые процессоры без таких уязвимостей могут появиться очень не скоро, минимум года через 2-3 и это будет первый блин комом, потом еще годами будут с производительностью что-то делать.
Таки суетнулись
В чипах AMD обнаружены подобные Spectre и Meltdown уязвимости
Уязвимости позволяют получить доступ к содержимому защищенной части процессора.
В чипах AMD Ryzen и EPYC обнаружены уязвимости, подобные печально известным Spectre и Meltdown в процессорах Intel. Исследователи израильской компании CTS-Labs выявили в процессорах AMD 13 уязвимостей, позволяющих получить доступ к высокочувствительной информации и установить вредоносное ПО.
Процессоры Ryzen используются в ноутбуках и настольных компьютерах, а EPYC – в серверах (чипы используются в дата-центрах по всему миру, в том числе в Microsoft Azure Cloud).
Хуже всего то, что проблемы затрагивают защищенную часть процессора, где, как правило, хранятся пароли и ключи шифрования. Для эксплуатации большинства обнаруженных уязвимостей атакующему потребуются права администратора, то есть, сначала он должен получить доступ к атакуемому компьютеру, заразив его вредоносным ПО. Тем не менее, даже это условие не делает уязвимости менее опасными. Все они позволяют получить доступ к защищенной части процессора и похитить конфиденциальную информацию. Злоумышленник может иметь доступ в течение многих лет, а жертва так и не узнает об этом.
Исследователи разделили обнаруженные уязвимости на четыре категории.
Master Key
При запуске компьютера обычно происходит процесс безопасной загрузки. Процессор удостоверяет компьютер в том, что в данный момент выполняется только аутентичный доверенный код, а не вредоносное ПО. Уязвимость Master Key позволяет обходить проверку при запуске и внедрять вредоносный код в BIOS компьютера.
Fallout
Уязвимость затрагивает процессоры EPYC. С ее помощью злоумышленник может получить доступ к разделу защищенных данных.
Ryzenfall
Схожая с Fallout уязвимость, однако затрагивает чипы Ryzen. Позволяет получить доступ и полный контроль над блоком Secure Processor.
Chimera
Уязвимость позволяет с помощью Wi-Fi, Bluetooth или проходящего через чипсет сетевого трафика скомпрометировать устройство путем выполнения вредоносного кода.
На исправление уязвимостей исследователи дали AMD менее 24 часов. Обычно между уведомлением производителя о проблеме и ее публичным раскрытием проходит 90 дней, которых вполне достаточно для подготовки надежного исправления. Исследователи Google дали Intel целых шесть месяцев на исправление Spectre и Meltdown. Столь скорое раскрытие подробностей об уязвимостях в AMD до выхода соответствующего патча чревато серьезными последствиями.
Источник: securitylab
одмин, чойта тебя на новости потянуло? :-)
а че б и нет? все равно натыкаюсь
да нет, это в принципе не плохо, просто были реееедко, а сейчас за день несколько штук )
ну просто сегодня дольше сидел с планшетом в... местах не столь отдаленных )
поплюй про места, если чот не то съел - то те места по-другому называются )
или серьезно, те места?
ну где, блин, люди обычно с планшетами чи с телефонами сидят читают?
Места заключения так и называются, а вот про другие - оно как-то не принято говорить прямо
Раскрыта информация об обнаружении 8 новых уязвимостей в механизме спекулятивного выполнение инструкций в процессорах Intel. По предварительным данным проблемы также затрагивают некоторые процессоры ARM и возможно процессоры AMD, но исследование в этой области пока не завершено. Уязвимости продолжают развитие идей по восстановлению данных, оставшихся в процессорном кэше в результате активности блока предсказания переходов, ставших известными под именем Spectre и позднее получивших развитие в атаках SpectrePrime, SgxPectre и BranchScope.
Информация о проблемах уже передана компании Intel, которая намерена выпустить два набора исправлений - первый в мае, а второй в августе. Кроме Intel в это же время ожидается публикация исправлений от Microsoft и разработчиков ядра Linux. Исправление усложняет то, что каждая из 8 уязвимостей требует отдельного патча и не закрывается ранее выпущенными исправлениями.
В настоящее время обнародованы лишь общие сведения о проблемах, детали будут опубликованы после истечения эмбарго или публикации исправлений (90-дневный эмбарго на одну из уязвимостей истекает 7 мая). Так как уязвимости выявлены разными командами исследователей, среди которых Google Project Zero, вероятно каждая из проблем будет раскрываться по отдельности и будет снабжена своим именем. До публикации деталей для упрощения идентификации все восемь проблем решено именовать Spectre-NG (Next Generation).
По классификации Intel четырём проблемам присвоен высокий уровень риска, а остальным - средний. Сценарий проведения атак Spectre-NG в общем виде напоминает атаки Spectre. Наиболее опасная проблема позволяет атаковать системы виртуализации, давая возможность из гостевой системы получить доступ к информации в памяти хост-окружения или чужих гостевых систем. Например, таким образом можно перехватить находящиеся в памяти ключи шифрования, пароли и прочие конфиденциальные данные. Утверждается, что при помощи новой уязвимости организовать атаку по перехвату данных в системах виртуализации значительно проще, чем при использовании оригинальных уязвимостей Spectre.
opennet
You should to log in