LINUX.ORG.RU

IBM представила браузерный упрощенный вариант атаки Spectre v1

 , ,


4

2

Исследователи из Северо-Восточного университета Бостона и команды IBM Research обнаружили новый вариант уязвимости Spectre, которую можно эксплуатировать через браузер. Как и в предыдущих случаях, новая проблема, получившая название SplitSpectre, представляет собой уязвимость в механизме спекулятивного выполнения, реализованном в современных процессорах.

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

Как пояснили исследователи, данная атака технически увеличивает длину окна спекулятивного выполнения. Новый метод был успешно протестирован на процессорах Intel Haswell, Skylake и AMD Ryzen с использованием JavaScript-движка SpiderMonkey 52.7.4.

Статья в формате PDF с подробным описанием атаки

>>> Подробности

☆☆

Проверено: Shaman007 ()
Ответ на: комментарий от anonymous

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

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

uin ★★ ()
Ответ на: комментарий от anonymous

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

uin ★★ ()

Кто-то затирал про x86-одноплатники, ммм. Такую патологическую безграмотность калёным железом выжигать надо. x86 must die!

anonymous ()
Ответ на: комментарий от anonymous

Ну этот не будет а вот этот вот будет:

char a1[10]="0123456789";
char secret[10]="secret";
char* a2;

char func(int offset)
{
   if (offset<10)
      a2[a1[offset]*64];
}
Т.е. При вызове функции с передачей ей аргумента в виде числа он спекулятивно загрузит a2[a1[offset]*64]; еще до того как проверит условие (ну хорошо, в интеле загрузит, а в эльбрусе компилятор просто поставит ее самой первой). Но в защищенном режиме это ничего не даст потому что строго контролируются границы чего откуда можно загружать. В данном примере оно так и так куда то перелазит за диапазон и программа либо грохнется (если условие удовлетворено) либо не грохаясь проскочит но в любом случае (в защищенном режиме) данных в кэше не окажется.

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

Удивляет только почему раньше на это внимание не обратили.

uin ★★ ()
Последнее исправление: uin (всего исправлений: 2)
Ответ на: комментарий от anonymous

Так и представляю, как какеры всего мира денно и нощно стараются найти уязвимости в поделке, которой выпущено наверное меньше (нескольких) тыщ штук.

Зато под линукс эльбрус нет вирусов.

upcFrost ★★★★★ ()
Ответ на: комментарий от Thero

но вообще мы тут конечно за всякие OpenPOWER c OpenRISC должны быть..

А вместо этого за огороженную проприетарную медленную и дорогую поделку, воплощённую в железе хорошо если 10 тысяч раз топите. Зачем? Загадка.

robus ★★★ ()
Ответ на: комментарий от VinnyPuh

Что за ОС пошли такие, что не изолируют hardware от прикладного кода?

Целиком? Да все, прикинь. Почитай, например, про Rowhammer и расскажи, как спастись «изоляцией», в чем она будет заключаться и чего будет стоить.

t184256 ★★★★★ ()

Нифига не понял. Вроде смысл спектра в том, что натренировав предиктор на ветку в которой индекс не выходит за границы, хакер добивается спекулятивного чтения в регистр (в который компилятор поместит переменную j) значения за пределами массива array1, и спекулятивного чтения из какой-то общей памяти. Далее, замеряя время обращения к памяти, хакер может узнать, какая строка попала в кэш и, следовательно, какое значение было бы прочитано в j. В данном случае обращение к j идёт в другом месте, т.е. j должна быть локальной переменной, чтоб попасть в регистр, но при этом доступной и из вызывающего кода и из вызываемого. Какой вообще смысл в атакере и жертве? Раз они разделяют локальные переменные, атакующий может вызывать весь код внутри себя, например выходя за пределы памяти js vm.

khrundel ()

Возникает резонный вопрос, уж не имеет ли ИБМ отношение ко всму этому? Уж очень своеобразно распространяются «круги по воде».

rht ★★★★★ ()
Ответ на: комментарий от Thero

но в эльбрусе это будет софтовая бага..

довольно забавный смысл этой фразы, учитывая что Софтовая Часть Эльбруса — находится внутри проприетарного безальтернативного компилятора.

то есть — как увидить исходный код этого «софта»? а потом исправить, например. какой смысл этой Софтовости, если она не является «мягкой» :-)

и при этом мы знаем что Процессоры Интел тоже работают через использование софтовой прошивки..

и в случае Интел ровно точно также как и в случае Эльбруса — софт является безальтернативным и проприетарным

user_id_68054 ★★★★★ ()
Ответ на: комментарий от StReLoK

Перформанс будет совсем дно. Как-то попробовал порботать на ноуте с атомом и охренел просто от тормозов, субьективно у меня пень три быстрее ворочался.

anonymous ()
Ответ на: комментарий от uin

Но у них есть возможность просто подождать пока интел с amd придумают решение и сделать аналогичное в софте.

а ещё у них есть возможность не страдать хренью и начать активно сотрудничать с upstream (ядро, gcc, binutils, glibc и так далее)..

возможность есть, однако по какой-то причине они эту возможность не используют..

откуда же тогда взялось мнение будто они будут использовать возможность для устранения спектра? ведь намного проще утверждать «у нас спектра вообще нет, в камне» :-) чем заниматься его устранением :-)

user_id_68054 ★★★★★ ()
Ответ на: комментарий от user_id_68054

не представляю как вы сможете разобраться в вопросе так резво смешивая разные слои абстракции..

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

Thero ★★★★★ ()
Ответ на: комментарий от user_id_68054

ну и что с того что она «явная» — хочешь сказать что говнокомпилятор Эльбруса якобы не навставляет этих спекулятивностей в явном виде? прям в машинных кодах.
«явная» это же НЕ синоним слову «отсутствует». разве не так? :-)
// P.S.: Эльбрусами проблема скорее в том что SpiderMonkey там наверное ещё врядли дорос до JiT :-) — скорее всего именно это его и спасёт в случае с Браузером

https://www.youtube.com/watch?v=vbhA_FEL4kY

https://habr.com/company/jugru/blog/419155/

Xintrea ★★★★★ ()
Ответ на: комментарий от Thero

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

давай с тобой условимся — если мы говорим про Эльбрус, то будем подразумевать что «процессор» это «проприетарный_компилятор + железка».

а если мы говорим про Интел, то процессор это «проприетарная_прошивка + железка».

а теперь вопрос — откуда мне быть уверенным что моя сишная программа будет выполняться именно так как я её написал?

ну не на машинных же кодах пишу :-)

user_id_68054 ★★★★★ ()
Ответ на: комментарий от user_id_68054

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

Thero ★★★★★ ()
Ответ на: комментарий от user_id_68054

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

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

Thero ★★★★★ ()
Ответ на: комментарий от user_id_68054

возможность есть, однако по какой-то причине они эту возможность не используют..

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

Xintrea ★★★★★ ()
Ответ на: комментарий от anonymous

с конспирологией

Why, собственно, not?

Не, я понимаю, что всем тупо покласть с пробором на всё, что напрямую не задевает их задницы. Поэтому я не настаиваю. Так, предположил. Истории известны и не такие финты ушами.

совок головного мозга

Как же , как же =)

rht ★★★★★ ()
Ответ на: комментарий от user_id_68054

не страдать хренью и начать активно сотрудничать с upstream (ядро, gcc, binutils, glibc и так далее)..


Апстрим это не следователь с которым взял и «пошел на сотрудничество», это мастер-репозиторий проекта в который просто так добавиться и свой код комитить нельзя. И код пропатченый для компилирования своим компилятором, а не каноничным, и так чтоб под одну целевую архитектуру - такой код никто не примет.
«Каноничных» компилятора всего два - gcc (в котором кроме столлммана никто не разбирается) и llvm (в котором в теории все должно быть идеально но по факту то же не все просто). И в оба пропихнуть свою архитектуру просто то же быстро не получится, а бесплатно тебе никто поддержку в llvm и gcc не сделает.

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

uin ★★ ()
Последнее исправление: uin (всего исправлений: 1)
Ответ на: комментарий от zgen

где то в таком - https://en.wikipedia.org/wiki/Cyrix#/media/File:KL_IBM_6x86MX.jpg

As part of the manufacturing agreement between the two companies, IBM received the right to build and sell Cyrix-designed CPUs under the IBM name. While some in the industry speculated this would lead to IBM using 6x86 CPUs extensively in its product line and improve Cyrix's reputation, IBM continued to mostly use Intel CPUs, and to a lesser extent, AMD CPUs, in the majority of its products and only used the Cyrix designs in a few budget models, mostly sold outside of the United States. IBM instead sold its 6x86 chips on the open market, competing directly against Cyrix and sometimes undercutting Cyrix's prices.

alwayslate ()
Последнее исправление: alwayslate (всего исправлений: 1)
Ответ на: комментарий от rht

при чём тут Эшелон, интересно? ппц каша в голове

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

anonymous ()
Ответ на: комментарий от anonymous

как раз подумай

Не учи меня жить, лучшн помоги материально =)

Ещё раз: я не настаиваю. Кому куда охота впрячься, на какую иглу подсесть, во что верить - дело сугубо личное.

rht ★★★★★ ()
Ответ на: комментарий от user_id_68054

а ещё у них есть возможность не страдать хренью и начать активно сотрудничать с upstream (ядро, gcc, binutils, glibc и так далее)..
возможность есть, однако по какой-то причине они эту возможность не используют..

Презирают сообщество и ненавидят свободу. Даже в этой теме анонимно пишут — сообщество, якобы, ненужно,

robus ★★★ ()