Weitere CPU-Lücken ret2spec und SpectreRSB entdeckt

Nach Bekannt­wer­den der Sicher­heits­lü­cken in moder­nen Pro­zes­sor-Designs – Mel­tdown und Spec­t­re – Anfang des Jah­res, sowie der bis­her nicht voll­stän­dig ver­öf­fent­lich­ten, von der Pres­se Spec­t­re-NG genann­ten Schwach­stel­len, sind nun wei­te­re Lücken öffent­lich gewor­den, die Ähn­lich­kei­ten zu den bis­he­ri­gen Schwach­stel­len auf­wei­sen, im Detail aber den­noch ande­res sind: ret2spec oder auch Spec­t­re v5 genannt, sowie Spec­treRSB. Ent­deckt wur­den sie von Gior­gi Mai­surad­ze und Chris­ti­an Ros­sow vom Cen­ter for IT-Secu­ri­ty, Pri­va­cy and Accoun­ta­bi­li­ty (CISPA) der Uni Saar­land, sowie einem For­scher­team der Uni­ver­si­ty of Cali­for­nia, River­si­de (UCR).

Die kom­plet­te Fami­lie der seit Janu­ar ans Licht gekom­me­nen Lücken nutzt das Ver­hal­ten moder­ner Out-of-Order-Pro­zes­so­ren, Befeh­le nicht wie bei frü­he­ren In-Order-Designs strikt in der Rei­hen­fol­ge aus­füh­ren, wie sie im Code ste­hen. Statt­des­sen kön­nen OoO-Pro­zes­so­ren Befeh­le vor­zie­hen, wäh­rend sie auf das Ergeb­nis einer ande­ren Berech­nung war­ten oder sogar mit des­sen Ergeb­nis spe­ku­lie­ren (Spe­cu­la­ti­ve Exe­cu­ti­on) und der­weil mal mit dem Ergeb­nis wei­ter­rech­nen, von dem sie “mei­nen”, dass es am wahr­schein­lichs­ten ist. War die Spe­ku­la­ti­on kor­rekt, hat der Pro­zes­sor jede Men­ge Zeit gespart, weil die Berech­nung bereits erle­digt wur­de, wohin­ge­gen ein In-Order-Design hät­te war­ten müs­sen und erst dann hät­te wei­ter­rech­nen kön­nen. Aller­dings sind Out-of-Order-Designs wesent­lich kom­ple­xer, denn die Pro­zes­so­ren müs­sen sich mer­ken, ab wel­cher Code­po­si­ti­on spe­ku­liert wur­de und in wel­cher Rei­hen­fol­ge der Code ursprüng­lich war, um das Puz­zle aus geän­der­ter Rei­hen­fol­ge und spe­ku­lier­ten Ergeb­nis­sen am Ende wie­der so zusam­men­zu­set­zen, dass das Ergeb­nis stimmt.

Dafür wer­den ver­schie­de­ne Puf­fer ver­wen­det. Nor­ma­ler­wei­se sind die­se Daten von außen nicht abgreif­bar. Mit den Spec­t­re-Lücken hin­ge­gen kann durch trick­rei­che Pro­gram­mie­rung, soge­nann­te Sei­ten­ka­nal­at­ta­cken, ein Weg gefun­den wer­den, trotz­dem an die­se Daten her­an­zu­kom­men. Damit wäre es z.B. mög­lich, per Java­script via Brow­ser ein­ge­schleus­ten Code dafür zu ver­wen­den, aus eigent­lich nicht zugäng­li­chen Spei­cher­be­rei­chen z.B. Pass­wör­ter oder Schlüs­sel abzu­grei­fen. Dafür exis­tie­ren auch Bei­spiel­codes, wie wir in den letz­ten Mona­ten bereits berich­tet und ver­linkt hat­ten. Ein ech­ter Angriff, also eine Aus­nut­zung der Spec­t­re-Lücken in frei­er Wild­bahn, ist bis­her jedoch nicht bekannt gewor­den.

Das Neue an ret2spec/Spectre v5 und Spec­treRSB ist nun, dass nicht die Sprung­adres­sen für den Angriff genutzt wer­den, son­dern die Rück­sprung­adres­sen, also prak­tisch ein umge­kehr­ter Spec­t­re-Angriff. Um die Aus­nut­zung der Lücke zu erschwer­den, wer­den die sel­ben Maß­nah­men emp­foh­len, die bereits bei Spec­t­re zur Lin­de­rung ange­wandt wur­den: die Zeit­mes­sung der Brow­ser soll unge­nau­er wer­den, denn für einen erfolg­rei­chen Angriff ist das Timing ent­schei­dend. Daher haben die Brow­ser-Her­stel­ler nach Bekannt­wer­den der ers­ten Lücken die­ser Art im Janu­ar die von Skrip­ten im Brow­ser nutz­ba­ren Timer-Genau­ig­keit künst­lich redu­ziert. Als Lin­de­rung gegen Spec­treRSB wird der Linux-Ker­nel-Patch RSB refil­ling vor­ge­schla­gen.

In den PDFs der For­scher wird haupt­säch­lich auf Intel-Pro­zes­so­ren ein­ge­gan­gen. Ob die Atta­cken so auch 1:1 auf ande­re Imple­men­tie­run­gen eines Out-of-Order-Designs – z.B. von AMD oder ARM – anwend­bar sind, geht aus der Ver­öf­fent­li­chung bis­her nicht her­vor. Zumin­dest haben AMD und ARM die Lücken grund­sätz­lich bestä­tigt. Ob sie auch für die eige­nen Pro­zes­so­ren gel­ten, bleibt aber (noch) offen. So war AMD bei­spiels­wei­se von Mel­tdown gar nicht betrof­fen, obwohl auch Mel­tdown das Prin­zip eines OoO-Pro­zes­sors nutzt:

Intel: Intel ack­now­led­ged this “very inte­res­ting” issue of RSB-based spe­cu­la­ti­ve exe­cu­ti­on and will fur­ther review the attack and its impli­ca­ti­ons. Their imme­dia­te advice is to resort to miti­ga­ti­ons simi­lar to Spec­t­re is to defend against our attack (see Sec­tion 6.1); this is, howe­ver, sub­ject to chan­ge as part of their ongo­ing RSB inves­ti­ga­ti­ons that we trig­ge­red.

Mozil­la Foun­da­ti­on: The Mozil­la Foun­da­ti­on like­wi­se ack­now­led­ged the issue. They deci­ded to refrain from using com­pi­ler-assisted defen­ses, as they would see­min­gly requi­re com­plex chan­ges to JIT-com­pi­led and C++ code. Ins­tead, they aim to remo­ve all (fine-gra­nu­lar) timers from Fire­fox to des­troy caching-based feed­back chan­nels. Fur­ther­mo­re, they refer­red to an upco­m­ing Fire­fox release that inclu­des time jit­te­ring fea­tures simi­lar to tho­se descri­bed in Fuz­zy­Fox [23], which fur­ther har­den against accu­ra­te timers.

Goog­le: Goog­le ack­now­led­ged the pro­blem in princip­le also affec­ts Chro­me. Simi­lar to Fire­fox, they do not aim to address the pro­blem with com­pi­ler-assisted solu­ti­ons. Ins­tead, they also refer to inac­cu­ra­te timers, but more import­ant­ly, focus on a stron­ger iso­la­ti­on bet­ween sites of dif­fe­rent origins. Chrome’s so-cal­led Site Iso­la­ti­on pre­vents atta­ckers from rea­ding across origins (e.g., sites of other domains). Howe­ver, as dis­cus­sed in Sec­tion 6.1, this does not miti­ga­te the pro­blem that atta­ckers can break ASLR with our attack tech­ni­que.

AMD / ARM: Alt­hough we have not tested our attacks against ARM and AMD archi­tec­tures, they ack­now­led­ged the gene­ral pro­blem.

Micro­soft: Micro­soft has ack­now­led­ged the pro­blem and is working on fixes, but has not dis­c­lo­sed tech­ni­cal details yet.

Apple: As of 07/23/2018, we have not heard back from Apple yet.

Red­hat: Red­hat was thank­ful for our dis­clo­sure and men­tio­ned that the cur­rent Spec­t­re defen­ses (espe­ci­al­ly flus­hing RSBs)—without con­si­de­ring RSB-based attacks—might other­wi­se have been remo­ved by the ker­nel deve­lo­pers in the near future. In par­ti­cu­lar, Red­hat men­tio­ned that fixing RSB under­flows will not ful­ly sol­ve the pro­blems poin­ted out in our paper.