Ryzen 2 Meltdown Spectre

Так что же у вас вместо процессора?

Процессор.

Да щас:

http://phrack.org/issues/67/11.html

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

Не штеуд просто. AMD64. До AMD64 были IA32 AMD. А до них лет 15 назад, да, грешил штеудами.

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

просто они в случае фэйла обламываются в retirement и проблему не видели. честно говоря, непонятно - они же явно обнаруживают ошибку в момент обращения к TLB а оно идет первым. у x86 pipt-кэш, поэтому tlb надо проходить всегда. почему не зарубают чтение на этом этапе - зогадка.

алсо, почему такая проблема у всех - вот где главная загадка.

почему все на эту какашку наступили

Ну тогда у вас тоже есть возможность иметь баг который ещё не нашли.

P.S Не фанат ни красных, ни синих.

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

Допустившие один баг с большей вероятностью допустят и второй.

Сразу предвижу вопрос: почему на амд работает спектр. Работает, но только в пределах одного процесса. Для выхода из сэндбокса и чтения памяти своего процесса годно, между процессами шиш.

И? Таким образом можно кучу корпораций (привет Samsung) закопать. Но ведь мы умные люди и делать это не станем?

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

Возможность иметь баг который ещё не нашли, есть у всех.

Даже у тех, кто вообще процы и софт не использует, а ежедневно картошку копает. Баги и в организмах бывают.

Ну и да, на картошке этих багов регулярно травить приходится.

Как тебе конкретно это угрожает? :)

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

Никак не связано, особенно с учетом текучки кадров :)

Соседние вкладки уже в соседних процессах, не?)

Есть задачи, которые оптимально решить полностью на том, о чём вы говорите, принципиально нельзя. И их много.

Не вижу корреляции между пони и умом.

Увы и ах, но пока ещё «не». С iframe'ми и прочим эмбедом типа флеша тоже не всё гладко.

Кроме того, опять же, XSS сильно упрощается. Чей-нибудь JS например не имеет доступа к кукам фейсбучки пользователя, а они при авторизации через таковую в пределах одной вкладки в память процесса подгрузятся.

То есть тут уже речь не о процессе на вкладку, а о процессе на домен в пределах вкладки. Это сильно хреновый вариант.

Ты про унаследованный код слыхал, который разрабатывался на системах не подключенных ни к какому интернету где пароль больше 6 символов невозможен, — потому что убили бы лопатой за перерасход ресурсов и паранойю (а надо еще и че-то работать на сильно менее 640Кб, которых уж точно хватало всем, дадад, а у потенциальных террористов на то время не было достаточных вычислительных мощностей (и не жидились нанимать проверенных людей в службу внешней безопасности, которая могла нарушителя NDA если чо и физически покарать :))? Авторы давно на пенсии, если живы, а кот — «работает не трогай» :) Или хотя бы про проблему 2000 года, с программами которым не упало пространство чисел дальше конца жызы вселенной, потому что «и так работает, скоро на пенсию, а там молодежь на новых компах с широкими словами перепишет»? И которые разумеется никто не стал переписывать «потому что работает не трогай!» — а потом его заставили работать с системами и на системах где переполнение того буфера в 6 символов — как два пальца об асфальт :)

на х86-64 должно работать потому что в адресах ffff880000000000 - ffffc7ffffffffff прямо размаплена вся память.

Тока эти языки в те времена когда буфера так экономили нельзя было на чем-то слабее мейнфрейма использовать :)

А проверять аргументы ручками - подход, устаревший еще в 60е.

Потому что встроенные проверки — это цена, которую не были готовы заплатить :)

А это, длину буфера проверять не модно? Говорю же - проблема в ДНК.

пишут что работает хотя и херовее. значит читает таки, байт приходит в регистр.

им же полюбасу надо в TLB сходить за физ.адресом. там им должны были показать член, например. это один бит поставить в MMU - CPL==3. инструкция фэйлится, и её результат - FIAL. реально такое ощущение что просто забили.

А это, длину буфера проверять не модно? Говорю же - проблема в ДНК.

А зачем ее было проверять там, где буфер был физически 6 символов? :) Тогда это уже называли «оверхед». Потом софт портировали «просто чтоб работал» другие люди (физический буфер стал «просто массивом»).

Говорю же - проблема в ДНК.

Только не всегда тех, кто автор изначального кода :)

Ты не видел в современном HFT (софт для бирж, основа мировой экономики :)) массовых срезаний углов типа убирания проверок («потому что они тормозят, а мы все равно прожжом в азик и будет чики-пуки») или проверки формата таймстампа сравнением длины, от которых любое изменение конфига конечным потребителем может стать охотой на единорога (т.е. если они «купили подписку» — это конечно вернется бумерангом к разрабам движка)?

Люди идут на это потому что «невидимая рука» показывает им знаками, через манагера и его начальство, что если на графике сравнительных тестов конкурент будет выше, чьи-то поделки перестанут быть нужны уже в краткосрочной перспективе, пока они ковыряются над супероптимизациями, чтобы не оставлять дыр в безопасности, которые оптимизации через месяц выкидывать на помойку — потому что «рынок вон-оно где» и либо делаешь «вчера», а потом это будет не твоей проблемой — либо сразу просматриваешь «вакансии» :)

Понял.

Изоляция соседних вкладок не панацея. Есть ещё iframe, который тебе могут воткнуть на любом промежуточном узле без https, или с ним в случае mitm.
Не знаю как в лисе, в хромом вот что:
Strict site isolation Mac, Windows, Linux, Chrome OS, Android
Highly experimental security mode that ensures each renderer process contains pages from at most one site. In this mode, out-of-process iframes will be used whenever an iframe is cross-site. #enable-site-per-process
По дефолту не включено
Top document isolation Mac, Windows, Linux, Chrome OS, Android
Highly experimental performance mode where cross-site iframes are kept in a separate process from the top document. In this mode, iframes from different third-party sites will be allowed to share a process. #enable-top-document-isolation
Аналогично
Iridium
Версия 2017.11 (Сборка для разработчиков), Fedora Project (64 бит)
Базируется на 62-какой-то сборке хромиума.
В 64-й версии у хромого то же самое — хайли экспериментал и по умолчанию отключено.

И что мне помешает пристегнуть к своему вредоносному JS шапку с GPL? Ну да, я не смогу засудить спецов по безопасности за ковыряние в моём вредоносе, и коллег черношапочников за присваивание моего вредоноса. Вот пичалька-то

Ты должен был наслаждаться свободой, а не сайтами и стабильностью.

Понял.

Я слабо разбираюсь в web'е, так что большое спасибо за объяснение.

в соседних вкладках много интересного. 

Да, об этом я не подумал :(

С другой стороны современные браузеры могут создавать процессы на каждое окно или таб.

Тот код из новости при добавлении описанных там же правок работает на моём FX-8120, мне бояться, или нет?

Meltdown у тебя не работает. Работает Spectre. Чтобы снизить опасность от него, если используешь хромиум, или что-то на нём основанное, зайди в chrome://flags/ и разреши там #enable-site-per-process и #enable-top-document-isolation.

мне бояться, или нет?

Кирпич на голову тоже может упасть в любой момент. Стоит бояться, или нет? Поставь HTTPS Everywhere, следи за сертификатами сайтов — будет меньше вероятности, что тебе подсунут что-то внутрь трафика. Ходи по белому списку — наверняка не напорешься ни на что плохое. Поставь блокировщик скриптов и разрешай их только в минимальном объёме на белом списке сайтов.

Не за что.

современные браузеры могут создавать процессы на каждое окно или таб

Этого может оказаться недостаточно. Уже делают site-per-process.

У меня лиса с HTTPS Everywhere, uBlock и uMatrix. Этого достаточно?

Да хз, достаточно или нет. Зависит от того, где ты ходишь в интернет и какие у тебя настройки этих расширений. Хотя, думаю, что по дефолту выставлено достаточно безопасно.

Буду считать что я спасён, выставлены в параноидальную крайность.

Не бойся будет другая закладка

На ещё http://seclists.org/fulldisclosure/2018/Jan/12

либо делаешь «вчера», а потом это будет не твоей проблемой — либо сразу просматриваешь «вакансии»

Мой вариант второй однозначно. Но про людей с проблемами в ДНК я в курсе. А потом вылезают уязвимости типа того же Meltdown - там тоже видимо «вчера» сделали, пообрубав проверки RPL на спекулятивном чтении.

ME(Intel)/fTPM(AMD) - это вообще энтерпрайзно-корпорастный ад и ужас. К счастью, этот ад и ужас лечится гораздо проще - микрокодом, и от линейного софта затычек не требует.

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

Мы вам эксплойт и на либрежеэс подсунем если надо будет.

В последних процах просадки от патча существенней чем в старых, так новые процы не рекламируют..

Тогда начинайте хоронить амуду
https://twitter.com/internetofshit/status/948684798570188806

Кащинка херни не скажет
https://twitter.com/turbojedi/status/949622813283020800?s=17

А чего её хоронить? Мельтдоний (Meltdown) на AMD не работает, Spectre затыкается микрокодом (пока нет, но ожидается) вместе с небольшими изменениями в софте, которые не сильно скажутся на производительности. В общем, AMD практически сейф в этой истории.

Я бы лучше на этом фоне DRM похоронил - все контентные защитки базировались на «невозможности» прочитать области памяти DRM-драйверков с ключами. Теперь достаточно просто интеля, непатченного ядрышка и Meltdown. То есть интель DRM'щикам удружил всерьёз, просто об этом молчат пока.