Последнее обновление:
«Уязвимость» процессоров Spectre и JavaScript
Мы уже писали об «уязвимостях» процессоров Intel, якобы выявленных в конце 2017 г. – Meltdown и Spectre. Также писали, что сообщение о них привело лишь, в сухом остатке, к росту стоимости акций фирмы Intel (хотя, по идее-то, должно бы быть наоборот). Однако, там мы ограничивались общим, функционально-логическим подходом. В этой статье попробуем взглянуть на «проблему» чуть глубже.
Оригинал одной из статей на тему Spectre находится здесь. А здесь – о Meltdown.
Общее впечатление о работе
Характерно, что макет (внешне) этой статьи полностью соответствует современному научному формату. Т.е. есть аннотация (Abstract), введение (Introdaction), основная часть, обсуждение. В самом деле:
В конце приводится довольно внушительный список из ссылок, использованных ее авторами. Т.е. внешне – все достаточно серьезно. Ни дать, ни взять – серьезная научная работа. Да и авторы – не кто попало, а сотрудники крупных и широко известных в мире университетов (исключение составляет. разве что, первый автор в списке: он, судя по реквизитам, является независимым - Independent) . Правда, на полях статьи почему-то отсутствуют реквизиты соответствующего научного журнала… Да и сайт, на котором она находится, честно говоря, можно характеризовать одним словом: «простейший»: вот он. Так же выглядит и spectreattack.com.
Такие сайты – страницы делались, наверное, лет 30 назад, на самой-самой заре развития языка html. А ведь XXI-й век на дворе, все-таки. Да и потом – для чего посвящать этим «уязвимостям» отдельные сайты? Неужели, так обстоят дела буквально с каждой уязвимостью (а ведь в той же операционной системе Windows – их сотни, причем некоторые из них, до сих пор, компания Microsoft упорно не желает ликвидировать, несмотря на имеющуюся информацию)? Едва ли. Обычно они просто перечисляются на каком-нибудь тематическим ресурсе (или в печатном издании). Ну, бывает, когда одной уязвимости, да, посвящается одна или несколько вебстраниц. Но, чтобы отдельно САЙТЫ, да еще для каждой уязвимостей по отдельности – вот это уже перебор. Но, памятуем: ничего не делается просто так. Тем более, в современном мире цифровых олигополий - типа Microsoft.
Перейдем к обсуждению статьи
Что же, к делу. Вот скриншоты 6-й и 7-й страниц комментируемой статьи. Мы сделали свой, авторский перевод части статьи, касающейся Javascript. В переводе возможны неточности, но, мы, в некоторых местах, постарались сделать перевод более адаптированным к стилистике русского языка. Хотя, в любом случае, оригиналы страниц - перед Вами. Также их можно скачать с сайта-источника.
В некоторых местах (другим цветом) даны наши комментарии.
Итак, текст перевода
В подтверждение концепции, был записан код JavaScript который, при выполнении в браузере Google Chrome, позволяет JavaScript читать частную (приватную) память из процесса в котором он запущен (cм. Листинг 2). Часть кода JavaScript использовавшаяся для реализации утечки - следующая, где константы TABLE1_STRIDE = 4096 и TABLE1_BYTES = 225:
На прогнозирующих ответвлениях mistraining проходов, установлен индекс (через битовые операции) к значению в пределах диапазона, затем на заключительной итерации индекс установлен к значению, выходящему за пределы адреса в simpleByteArray.
Переменная localJunk используется для того, чтобы гарантировать, что операции не оптимизированы, и “|0” операции действуют как подсказки для целей оптимизации для интерпретатора JavaScript, что значения являются целыми числами.
Как и другие оптимизированные движки JavaScript, V8 выполняет компиляцию точно-во-время для того, чтобы преобразовать JavaScript в машинный язык. Чтобы получить дизассемблирование для x86,
1 if (index < simpleByteArray.length) {
2 index = simpleByteArray[index | 0];
3 index = (((index * TABLE1_STRIDE)|0) & (TABLE1_BYTES-1))|0;
4 localJunk ^= probeTable[index|0]|0;
5 }
Листинг 2: Эксплуатация Спекулятивного Выполнения с помощью JavaScript
| 1 cmpl r15,[rbp-0xe0] | ; Compare index (r15) against simpleByteArray.length |
| 2 jnc 0x24dd099bb870 | ; If index >= length, branch to instruction after movq below |
| 3 REX.W leaq rsi,[r12+rdx*1] | ; Set rsi=r12+rdx=addr of first byte in simpleByteArray |
| 4 movzxbl rsi,[rsi+r15*1] | ; Read byte from address rsi+r15 (= base address+index) |
| 5 shll rsi, 12 | ; Multiply rsi by 4096 by shifting left 12 bits}\%\ |
| 6 andl rsi,0x1ffffff | ; AND reassures JIT that next operation is in-bounds |
| 7 movzxbl rsi,[rsi+r8*1] | ; Read from probeTable |
| 8 xorl rsi,rdi | ; XOR the read result onto localJunk |
| 9 REX.W movq rdi,rsi | ; Copy localJunk into rdi |
Листинг 3: дизассемблирование спекулятивного выполнения в примере JavaScript (Листинг 2)
во время разработки использовался вывод JIT, инструмента командной строки D8. Была сделана ручная тонкая настройка продвижения исходного кода до отрывка, приведенного выше, чтобы получить значение simpleByteArray.length в локальной памяти (вместо кэшируемого в регистре или требующий множественных команд для выборки). См. Листинг 3 для получившегося вывода дизассемблирования от D8 (который использует синтаксис ассемблера AT&T).
Инструкция clflush не доступна из JavaScript, поэтому, сбрасывание кэша выполнялось путем чтения серий адресов в 4096-байтовых интервалах из большого массив. Из-за памяти и конфигурации КЭШа на процессорах Intel, серии ~2000 таких чтений (зависящих от размера кэша процессора), были адекватным очищением данных кэшей процессора для адресов, имеющих то же значение в адресных битах 11-6 [38].
Естественно, эта (а также и иные низкоуровневые инструкции) для JS недоступны, это очевидно. Однако, если эта инструкция НЕДОСТУПНА из Javascript, то о какой такой уязвимости Spectre, которая реализуется при помощи такой инструкции, по отношению к Javascript идет речь? Как же сбросить кэш средствами JS? Не получится. А если не получится – так зачем вообще упоминать в статье о, якобы, уязвимости JS? Ведь для реализации этой уязвимости на практике придется, ни много ни мало, при помощи какой-то другой программы выполнять функцию clflush или сбрасывать кэш как-то иначе.
А это, в свою очередь, означает, как и ожидалось, что сам по себе Javascript неспособен сделать то, о чем идет речь в комментируемой статье. Если же допускать, что параллельно с браузером (в котором, в свою очередь, будет запущен код JS), будет работать еще и другая программа (которая выполнит функцию clflush для сбрасывания кэша), так возникает вопрос: КТО ее запустит? Сам владелец компьютера, чтобы поспособствовать реализации «уязвимости» Spectre? Или – хакер? Если последний, так он должен вначале получить доступ к компьютеру. А если получит – так уж тогда ему гораздо проще использовать очередной троян или что-то в этом роде. Ну, понятно, что и требовалось доказать.
Пропущенные результаты переданы через состояние КЭШа при probeTable[n*4096] для n=0..255, таким образом, каждая попытка начинается с передачи сбрасывания, состоящей из серий операций чтения, сделанных из probeTable[n*4096], используя значения из n>256. У кэша, кажется, есть несколько режимов для того, чтобы решить, который именно адрес следует очистить, поэтому для того, чтобы способствовать режиму LRU (наименее недавно использованный) режим, два индекса использовались, где второй запаздывал первый посредством нескольких операций. Параметр длины (например, [ebp-0xe0] в дизассемблировании) нуждается в очистке также. Хотя, его адрес неизвестен, но есть только 64 возможных 64 байтовых смещений по отношению к 4096-байтовой границе, таким образом, все 64 возможности были попробованы, чтобы найти ту, которая работает.
JavaScript не обеспечивает доступ к rdtscp инструкции, и Chrome намеренно ухудшает точность из его таймера с высоким разрешением, чтобы ликвидировать возможность атак временным анализом с использованием performance.now() [1]. Однако, особенность Web Workers языка HTML5 делает простым создать отдельный поток, который неоднократно постепенно уменьшает значение в расположении разделяемой памяти [18, 32]. Этот подход получает в результате таймер с высоким разрешением, который обеспечил достаточное разрешение.
Что же касается словосочетания «свойство Web Workers языка HTML5» (в подлиннике: Web Workers feature of HTML5) - это вообще какой-то неологизм. Что такое «Web Workers feature»? Видимо, об этом знают только авторы статьи. Хотя, вполне возможно, что эта «feature» попросту выдумана ими – до кучи, как говорится. Или - этим словосочетанием названа какая-нибудь стандартная черта, свойство html5.
Ну, и наконец
Потом, язык HTML5, равно как и html другой версии – это совсем не Javascript. Уж html – это совершенно безобидный язык. Он даже не является языком программирования. Это – всего лишь язык гипертекстовой разметки. И, кажется, авторы обсуждаемой статьи осведомлены об этом. Так тогда – зачем это все? Зачем писать статью об «уязвимости»? Видимо, в самом деле, только для того, чтобы создать шумиху.
Другое дело, если бы авторы продемонстрировали, в самом деле, РЕАЛЬНЫЙ пример кода на Javascript, который, действительно, давал бы возможность нерегламентированного чтения памяти, КЭШа, без помощи других средств. Тут да, спору бы не было. Но, где же они найдут такой пример-то? Поэтому и пришлось им ограничиться тем, что написано в их статье. Общими словами и, как нам видится, попыткой подтасовки результатов. Т.е. что-то там написали, несколько раз упомянули термин «Javascript» и даже некий код привели, который, якобы, является «эксплойтом». М-да. Если бы все так было просто... так уж давно бы кто-то это использовал.
Но, "уязвимость" процессора - это Вам не дипломная работа. Это - вещь серьезная. Мы бы с этим шутить не стали, однозначно. Но, все же вот находятся шутники.
Впрочем, вот что
Впрочем, вполне возможно, что javascript, в самом деле, подвержен (как и ряд команд языка С, к примеру) банальному, давно известному (см. выше) переполнению памяти. Да, возможно. Следовательно, некоторые из команд javascript, содержащих некорректные значения, возможно, способны вести себя неправильно. Однако, во-первых, авторами статьи не приведено НИ ОДНОГО алгоритма, который ЦЕЛИКОМ основывался бы на средствах javascript и который был бы способен получить доступ к приватной памяти процесса, в котором он запущен (таким процессом является браузер, в частности). Приведенный авторами код требует, дополнительно, низкоуровневого вмешательства в работу компьютера. Сам же по себе этот код (если не "помочь" ему при помощи низкоуровневого вмешательства), на наш взгляд, нельзя назвать опасным.
Во-вторых, вот здесь-то как раз и наблюдается очередная странность: авторами приведен, на наш взгляд, безопасный код. А вот как раз конкретных примеров - ГДЕ, в КАКИХ командах javascript, при значениях КАКИХ переменных может наблюдаться переполнение - авторы не привели. Ни одного, т.е. от слова - совсем. Хотя, статья, повторимся, выглядит - с намеком на современный научный формат, да еще и целый сайт создали ИСКЛЮЧИТЕЛЬНО для сообщения об этих "уязвимостях". Чисто для внешнего вида, на наш взгляд. Так что же - очередная "новость" или так называемый "вброс"?
Правда, есть еще в статье, как утверждают ее авторы, пример на языке С, который, якобы, «тоже» «демонстрирует» данную «уязвимость». Однако, честно говоря, после прочитанного о Javascript видится, что и в отношении С будет, наверное, то же самое, что называется «притянутое за уши». Посему – даже и вникать в дальнейшее описание и утруждать себя переводом – уже не хочется.
Ну, а авторы – они, да, могут и дальше писать подобные развлекательно-научно-фантастические статьи. Только и заголовки у таких статей должны бы быть соответствующие. Из серии «Нейзнайка на Луне». Непонятно, правда – зачем.
Впрочем, вполне допускаем, что после научной фантастики (если обществом она не будет воспринята) далее пойдет попросту откровенная пропаганда из серии "эй, срочно обновляйте там свои браузеры, операционные системы, а то уже у миллиардов пользователей компьютеры "взломали". Да-да, обновляйте там, ибо новые браузеры и операционные системы смогут еще больше информации отправлять с Вашего компьютера куда-нибудь в сеть. Поэтому - не тяните там с обновлениями. А новые браузеры, глядишь, потом и платными станут... А старыми браузерами Вы потом воспользоваться не сможете, так как операционные системы тоже обновятся...".