Пора менять компьюторы

[Palmaris777]

Вчера все новостные агенстава отметились новой проблемой которая потенциально очень опастна.
Давайте ка и мы обсудим что к чему
https://www.marketwatch.com/story/what- ... 2018-01-04

[Самал Ришон]

пожалуйста не надо! мне этого на работе хватает... у нас у всех уже жопы горят...

[Palmaris777]

А у меня как раз появилась возможность требовать новый комп. Сегодня закину маляву на сходку-или новый компунтер или я не гарантирую!

[Самал Ришон]

Изначально написано Palmaris777:
А у меня как раз появилась возможность требовать новый комп. Сегодня закину маляву на сходку-или новый компунтер или я не гарантирую!

не дадут - все существующие модели процессоров всех производителей и все операционные системы с 2002 года попадают под этот баг

[Foxbat]

Cash is still king.

[Самал Ришон]

Изначально написано Foxbat:
Cash is still king.

и глиняные горшки вместо туалетов тоже... троглодит!

[iHARDee]

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

[Самал Ришон]

Изначально написано iHARDee:
кому-то хочется срубить деньжат нехилых. потом окажется, что проблема яйца выйденного не стоила. впрочем, я и сейчас особой проблемы не вижу. во всяком случае в личном пользовании

проблема как раз глобальная и очень серьезная. и в личном пользовании как раз очень значимая. во первых - все попытки операционных систем починить ее на существуюших платформах процессоров, замедляют их на 5%-30%..
это не баг в коде написанном индусским програмистом а скрытая слабость в фундаментальном алгоритме считки памяти и кэширования, используемом в микрокоде каждого процессора с 2002-го года
во вторых все ваши пароли, все сертификаты защищаюшие ваши ресурсы как раз крутятся в "защишенной памяти" которую сейчас эти баги и позволяют читать тем процессам которые ее не должны читать.
но конечно в корпоративном ИТ будет еще хуже

[john]

во первых - все попытки операционных систем починить ее на существуюших платформах процессоров, замедляют их на 5%-30%..

я подозреваю, что для домашнего контупера на своременных компонентах этот 30% performance hit будет незаметен. Другое дело, где контупреная нагрузка сильная.

[Foxbat]

проблема как раз глобальная и очень серьезная.

Я отлично помню, как ваще кричали "Небо падает!!!" накануне Y2K.
Миллиарды были потрачены на борьбу с воображаемой "проблемой"... а Новый Год пришел и прошел, и ничего не произошло.

[Самал Ришон]

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

[Самал Ришон]

Изначально написано Foxbat:

Я отлично помню, как ваще кричали "Небо падает!!!" накануне Y2K.
Миллиарды были потрачены на борьбу с воображаемой "проблемой"... а Новый Год пришел и прошел, и ничего не произошло.

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

[Palmaris777]

Изначально написано Самал Ришон:

не дадут - все существующие модели процессоров всех производителей и все операционные системы с 2002 года попадают под этот баг

Ха, я это знаю, но надо что бы ответственное лицо тоже знало. Я предьявлю, а там посмотрим. Мой на работе уже совсем старенький, 2 года, а нужен молодой и резвый.

[Foxbat]

Изначально написано Самал Ришон:

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

Не надо рассказывать сказки, вот, лучше почитай:
Opposing view
The contrary view asserts that there were no, or very few, critical problems to begin with. This view also asserts that there would have been only a few minor mistakes and that a "fix on failure" approach would have been the most efficient and cost-effective way to solve these problems as they occurred.
Countries such as South Korea and Italy invested little to nothing in Y2K remediation,[65] yet had the same negligible Y2K problems as countries that spent enormous sums of money.[66]
The lack of Y2K-related problems in schools, many of which undertook little or no remediation effort. By 1 September 1999, only 28% of US schools had achieved compliance for mission critical systems, and a government report predicted that "Y2K failures could very well plague the computers used by schools to manage payrolls, student records, online curricula, and building safety systems".[67]
The lack of Y2K-related problems in an estimated 1.5 million small businesses that undertook no remediation effort. On 3 January 2000 (the first weekday of the year), the Small Business Administration received an estimated 40 calls from businesses with computer problems, similar to the average. None of the problems were critical.[68]
The absence of Y2K-related problems occurring before 1 January 2000, even though the 2000 financial year commenced in 1999 in many jurisdictions, and a wide range of forward-looking calculations involved dates in 2000 and later years. Estimates undertaken in the leadup to 2000 suggested that around 25% of all problems should have occurred before 2000.[69] Critics of large-scale remediation argued during 1999 that the absence of significant reported problems in non-compliant small firms was evidence that there had been, and would be, no serious problems needing to be fixed in any firm, and that the scale of the problem had therefore been severely overestimated.[70]

[iHARDee]

Изначально написано Самал Ришон:

проблема как раз глобальная и очень серьезная. и в личном пользовании как раз очень значимая. во первых - все попытки операционных систем починить ее на существуюших платформах процессоров, замедляют их на 5%-30%..
это не баг в коде написанном индусским програмистом а скрытая слабость в фундаментальном алгоритме считки памяти, используемом в микрокоде каждого процессора с 2002-го года
во вторых все ваши пароли, все сертификаты защищаюшие ваши ресурсы как раз крутятся в "защишенной памяти" которую сейчас эти баги и позволяют читать тем процессам которые ее не должны читать.
но конечно в корпоративном ИТ будет еще хуже

ну, для начала, проблема связана только с теми паролями и сертификатами, которые хранятся именно в незашифрованном виде, чего на пользовательских компьютерах как-раз и не много. это раз. два - проблема с регистрами памяти ЦПУ, к которым нужно еще получить доступ, что веееесьма непросто. особенно из пользовательской области ОЗУ. мало того, что доступ затруднен, нужно еще получить доступ как раз к тем регистрам кэша, где они храняться, если они вообще там храняться в данный момент времени. короче, на форуме долго это все объяснять. но я особо страшной проблемы пока не вижу. это как с проблемаой миллениума все носились, ога

[Самал Ришон]

два - проблема с регистрами памяти ЦПУ, к которым нужно еще получить доступ, что веееесьма непросто.

было непросто до сегодняшнего дня. именно это и позволяет делать Meltdown

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

если процесс не будет словлен вовремя и будет сидеть и читать спекулятивный кэш, особенно на комьпютерах где процессы часто переключают ЦПУ с ядра на пользовательскую область, чисто по статистике, наловится много интересного

паролями и сертификатами, которые хранятся именно в незашифрованном виде,

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

[ГрозаБ]

А на что менять? Другиx процессоров пока вроде нет - под раздачу и Intel, и AMD и АРМ попали...

[Самал Ришон]

Изначально написано ГрозаБ:
А на что менять? Другиx процессоров пока вроде нет - под раздачу и Intel, и AMD и АРМ попали...

Intel Haswell и новее не теряют скорость при новом микрокоде... уже что-то

[iHARDee]

Изначально написано Самал Ришон:

если процесс не будет словлен вовремя и будет сидеть и читать спекулятивный кэш, особенно на комьпютерах где процессы часто переключают ЦПУ с ядра на пользовательскую область, чисто по статистике, наловится много интересного

эмммм... что значит "переключают"? проблема в том, что в кэше ЦПУ данные хранятся в незашифрованном виде. храняться те, что чаще всего используются. это и пароли и прочие данные или команды. и эти данные относятся к процессам и из области ядра ОС и из пользовательской области ОЗУ без всяких "переключений". в кэше иерархия строится по другому принципу. и теоретически эти данные можно считать из кэша. но... во-первых достаточно запретить хранить пароли и сертификаты в кэше. для пользователя замедление вообще будет не заметно. а вот, к примеру, для web-сервера, который обрабатывает тысячи паролей, это будет заметное замедление. с другой стороны, тот же web-сервер храниту в памяти уже зашифрованные пароли. они к нему приходят в таком виде. они в таком виде и храняться в БД. простейшая функция php шифрования md5 позволяет шифровать только в одну сторону. во-вторых, конечно можно получить доступ к стороннему процессу через данные из кэша. но он на статичный. он постоянно меняется. потому spectre и называют сложным типом атаки, что процессы - это не статическое состояние иформации, как файл. их потоки постоянно обрабатываются (если не находятся в фоне). закройте программу и... аля-улю, данные из кэша удалятся.
все что написано об этих 2х типах атак - пока копирование информации из одного источника в другой. даже на профресурсах. так что все это оч напоминает попытку подсобрать бабла с пользователей.

[ИТАР]

Intel Haswell и новее не теряют скорость при новом микрокоде... уже что-то

Мало что понятно (для меня лично)... но всеж любопытно почитать тех ,кто разбирается в вопросе . Послежу за темой ... если возможно Самал Ришон (без эмоций на раздражители) просветите чайника ... в чем проблема ... ну для простых юзеров ПК?

[iHARDee]

Изначально написано Самал Ришон:

Intel Haswell и новее не теряют скорость при новом микрокоде... уже что-то

а что такого в архитектуре Haswell, что не позволит при изменении работы кэша снизить скорость работы?

[Самал Ришон]

Изначально написано iHARDee:

эмммм... что значит "переключают"? проблема в том, что в кэше ЦПУ данные хранятся в незашифрованном виде. храняться те, что чаще всего используются. это и пароли и прочие данные или команды. и эти данные относятся к процессам и из области ядра ОС и из пользовательской области ОЗУ без всяких "переключений". в кэше иерархия строится по другому принципу. и теоретически эти данные можно считать из кэша. но... во-первых достаточно запретить хранить пароли и сертификаты в кэше. для пользователя замедление вообще будет не заметно. а вот, к примеру, для web-сервера, который обрабатывает тысячи паролей, это будет заметное замедление. с другой стороны, тот же web-сервер храниту в памяти уже зашифрованные пароли. они к нему приходят в таком виде. они в таком виде и храняться в БД. простейшая функция php шифрования md5 позволяет шифровать только в одну сторону. во-вторых, конечно можно получить доступ к стороннему процессу через данные из кэша. но он на статичный. он постоянно меняется. потому spectre и называют сложным типом атаки, что процессы - это не статическое состояние иформации, как файл. их потоки постоянно обрабатываются (если не находятся в фоне). закройте программу и... аля-улю, данные из кэша удалятся.
все что написано об этих 2х типах атак - пока копирование информации из одного источника в другой. даже на профресурсах. так что все это оч напоминает попытку подсобрать бабла с пользователей.

не знаю русскоязычную терминологию - перевел "context switch" как "переключение" может и неправильно
содержание спекулятивного кэша контролировать кодом операционной системы или приложения нельзя - это на уровне микрокода процессора - совсем другой зверь чем кэширование в обычном понимании.
каждый раз когда процессор делает Boolean "or" он считает оба варианта инструкций после разветвления и заносит их в спекулятивный кэш - и потом выдает один, а второй сбрасывает при context switching. баг SPECTRE состоит в том что для скорости, при context switching процессор не проверяет, на каком кольце крутится процесс - ring 0 (ядро) или ring 3 (пользовательский процесс) и при запросе в правильный момент до скидывания ненужного результата, выдает содержание.
любая обработка информации - сравнение пароля, или умножение 2х2 всегда будет сопровождаться заполнением спекулятивного кэша. этот баг использует доступность спекулятивного кэша, позволяя специально написанному процессу читать его в реальном времени.
можно запретить доступ пользовательским процессам к спекулятивному кэшу и вот от этого и будет потеря быстродействия и именно это сейчас и делают все чтоб залатать дырку.
процессоры Intel имеют еще одну проблему - Meltdown - при запрещенном произвольном доступе пользовательского процесса к памяти ядра - генерируется ошибка и в спекулятивный кэш сбрасываются адреса памяти ядра.
если достаточно долго это делать и читать спекулятивный кэш, можно со временем узнать все адреса памяти отведенные для процессов ядра и скинуть их на дамп - со всеми паролями, и тд
да, атака не из простых, но как-только код будет написан, все разойдется по даркнету и 15-летние скрипт-киды будут им пользоваться.

[Самал Ришон]

Изначально написано iHARDee:


а что такого в архитектуре Haswell, что не позволит при изменении работы кэша снизить скорость работы?

не знаю - это из заявления Интеля

[iHARDee]

Изначально написано Самал Ришон:

не знаю русскоязычную терминологию - перевел "context switch" как "переключение" может и неправильно
содержание спекулятивного кэша контролировать кодом операционной системы или приложения нельзя - это на уровне микрокода процессора - совсем другой зверь чем кэширование в обычном понимании.
каждый раз когда процессор делает Boolean "or" он считает оба варианта инструкций после разветвления и заносит их в спекулятивный кэш - и потом выдает один, а второй сбрасывает при context switching. баг Meltdown состоит в том что для скорости, при context switching процессор Интел не проверяет, на каком кольце крутится процесс - ring 0 (ядро) или ring 3 (пользовательский процесс) и при запросе в правильный момент до скидывания ненужного результата, выдает содержание.
любая обработка информации - сравнение пароля, или умножение 2х2 всегда будет сопровождаться заполнением спекулятивного кэша. если достаточно долго его читать, можно со временем узнать все адреса памяти отведенные для процессов ядра и скинуть их на дамп - со всеми паролями, и тд
можно запретить доступ пользовательским процессам к спекулятивному кэшу и вот от этого и будет потеря быстродействия и именно это сейчас и делают все чтоб залатать дырку.
процессоры АМД не имеют этой проблемы - они делают проверку уровня процесса всегда (поэтому они не такие быстрые как Интел) но на них нашелся другой хрен с винтом - SPECTRE - этот баг работает немного по другому, но использует тоже доступность спекулятивного кэша, позволяя специально написанному процессу читать его в реальном времени.
да, атака не из простых, но как-только код будет написан, все разойдется по даркнету и 15-летние скрипт-киды будут им пользоваться.

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

[Самал Ришон]

вчера была закрытая веб-лекция про это от SANS https://www.sans.org/about/
у меня есть слайды от нее - могу скинуть - дай мыло. мне действительно очень тяжело это на русский переводить
я вот посмотрел сейчас в них опять - я перепутал названия багов немного - все что я написал про разветвление - это про SPECTRE и про все процессоры.
а meltdown использует немного другой метод чтоб считать адреса памяти ядра - генерирует ошибку и считывает адреса памяти из спекулятивного кэша которые туда пишутся во время генерирования этой ошибки, потом делает дамп - и это про Интель - счас поправлю в своем тексте :
_______________
не знаю русскоязычную терминологию - перевел "context switch" как "переключение" может и неправильно
содержание спекулятивного кэша контролировать кодом операционной системы или приложения нельзя - это на уровне микрокода процессора - совсем другой зверь чем кэширование в обычном понимании.
каждый раз когда процессор делает OR или IF он считает оба варианта инструкций после разветвления и заносит их в спекулятивный кэш - и потом выдает один, а второй сбрасывает при context switching. баг SPECTRE состоит в том что для скорости, при context switching процессор не проверяет, на каком кольце крутится процесс - ring 0 (ядро) или ring 3 (пользовательский процесс) и при запросе в правильный момент до скидывания ненужного результата, выдает содержание.
любая обработка информации - сравнение пароля, или умножение 2х2 всегда будет сопровождаться заполнением спекулятивного кэша. этот баг использует доступность спекулятивного кэша, позволяя специально написанному процессу читать его в реальном времени.
процессоры Intel имеют еще одну проблему - Meltdown - при запрещенном произвольном доступе пользовательского процесса к памяти ядра - генерируется ошибка и в спекулятивный кэш сбрасываются адреса памяти ядра.
если достаточно долго это делать и читать спекулятивный кэш, можно со временем узнать все адреса памяти отведенные для процессов ядра и скинуть их на дамп - со всеми паролями, и тд
можно запретить доступ пользовательским процессам к спекулятивному кэшу и вот от этого и будет потеря быстродействия и именно это сейчас и делают все чтоб залатать дырку.
да, атака не из простых, но как-только код будет написан, все разойдется по даркнету и 15-летние скрипт-киды будут им пользоваться.

[mvkozyrev]

Хорошо. Имеем дапм всех процессов ядра. И что дальше? По какому идентификатору можно определить, к чему что относится?

[iHARDee]

Изначально написано mvkozyrev:
Хорошо. Имеем дапм всех процессов ядра. И что дальше? По какому идентификатору можно определить, к чему что относится?

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

[Самал Ришон]

Изначально написано mvkozyrev:
Хорошо. Имеем дапм всех процессов ядра. И что дальше? По какому идентификатору можно определить, к чему что относится?

ну, дампы читать умеют многие. Определенные процессы имеют узнаваемые паттерны. например LSA и SAM на контроллере домена. а что еще нужно? этого мало?

[mvkozyrev]

Изначально написано Самал Ришон:

ну, дампы читать умеют многие. Определенные процессы имеют узнаваемые паттерны. например LSA и SAM на контроллере домена. а что еще нужно? этого мало?

ИМХО, веселье будет не хуже, чем Bit Locker брутфорсить .

[Самал Ришон]

Изначально написано mvkozyrev:

ИМХО, веселье будет не хуже, чем Bit Locker брутфорсить .

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