Home » Posts tagged "javascript"

讀書時間:Spectre 的攻擊方式

上次寫了 Meltdown 攻擊的讀書心得 (參考「讀書時間:Meltdown 的攻擊方式」),結果後來中獎狂流鼻水,加上 Spectre 用的手法就更複雜,慢慢看的情況就拖到最近才看完... 這邊就以讀者看過 Meltdown 那篇心得的前提來描述 Spectre。

Spectre 的精華在於 CPU 支援 branch prediction 與 out-of-order execution,也就是 CPU 遇到 branch 時會學習怎麼跑,這個資訊提供給 out-of-order execution 就可以大幅提昇執行速度。可以參考以前在「CPU Branch Prediction 的成本...」提到的效率問題。

原理的部份可以看這段程式碼:

這類型程式碼常常出現在現代程式的各種安全檢查上:確認 x 沒問題後再實際將資料拉出來處理。而我們可以透過不斷的丟 x 值進去,讓 CPU 學到以為都是 TRUE,而在 CPU 學壞之後,突然丟進超出範圍的 x,產生 branch misprediction,但卻已經因為 out-of-order execution 而讓 CPU 執行過 y = ... 這段指令,進而導致 cache 的內容改變。

然後其中讓人最驚豔的攻擊,就是論文示範了透過瀏覽器的 JavaScript 就能打的讓人不要不要的...

圖片裡,上面這段是 JavaScript 程式碼,下面則是 Chrome V8JIT 後轉成的 assembly (這是 AT&T style):

可以從這段程式碼看到,他想要透過這段 JavaScript 取出本來無法存取到的祕密值 index,然後透過 probeTable 得知 cache 的變化。

在這樣的攻擊下,你就可以取得這個 process 裡可以看到的空間,甚至極端的 case 下有可能是 kernel space (配合 Meltdown 的條件)。

不過如果你不能跑 JavaScript 也沒關係,Spectre 的論文裡也提供各種變形方式提供攻擊。像是這樣的程式碼也可以被拿來攻擊:

if (false but mispredicts as true)
    read array1[R1]
read [R2]

其中 R1 是有帶有祕密值的 register,當 array[R1] 有 cache 時,讀 [R2] 就有機會比較快,而沒有 cache 時就會比較慢 (這是因為 memory bus 被佔用的關係),在這個情境下就能夠產生 timing attack:

Suppose register R1 contains a secret value. If the speculatively executed memory read of array1[R1] is a cache hit, then nothing will go on the memory bus and the read from [R2] will initiate quickly. If the read of array1[R1] is a cache miss, then the second read may take longer, resulting in different timing for the victim thread.

所以相同道理,利用乘法器被佔用的 timing attack 也可以產生攻擊:

if (false but mispredicts as true)
    multiply R1, R2
multiply R3, R4

在論文裡面提到相當多的方法 (甚至連 branch target buffers (BTB) 都可以拿來用),就麻煩去論文裡看了。現在用 cache 算是很有效的方式,所以攻擊手法主要都是透過 cache 在取得資訊。

Spectre 論文提到的 mitigation (workaround) 是透過 mfencelfence 強制程式碼的順序,但這表示 compiler 要針對所有的 branch 加上這段,對效能影響應該蠻明顯的:

In addition, of the three user-mode serializing instructions listed by Intel, only cpuid can be used in normal code, and it destroys many registers. The mfence and lfence (but not sfence) instructions also appear to work, with the added benefit that they do not destroy register contents. Their behavior with respect to speculative execution is not defined, however, so they may not work in all CPUs or system configurations.

Google 推出的 Retpoline 則是想要避免這個問題。Google 在「Retpoline: a software construct for preventing branch-target-injection」這邊詳細說明了 Retpoline 的原理與方法,採取的方向是控制 speculative execution:

However, we may manipulate its generation to control speculative execution while modifying the visible, on-stack value to direct how the branch is actually retired.

這個方式是抽換掉 jmpcall 兩個指令,以 *%r11 為例,他將 jmp *%r11call *%r11 改成 jmp retpoline_r11_trampolinecall retpoline_r11_trampoline (這邊的 jmp 指的是所有 jump 系列的指令,像是 jz 之類的):

retpoline_r11_trampoline:
  call set_up_target;
capture_spec:        
  pause;
  jmp capture_spec;
set_up_target:
  mov %r11, (%rsp); 
  ret;

藉由抽換 %rsp 內容跳回正確位置,然後也利用這樣的程式結構控制 CPU 的 speculative execution。

而在效能損失上,已經有測試報告出來了。其實並沒有像 Google 說的那麼無痛,還是會因為應用差異而有不同等級的效能損失... 可以看到有些應用其實還是很痛:「Benchmarking Linux With The Retpoline Patches For Spectre」。

下半年新出的 CPU 應該會考慮這些問題了吧,不過不知道怎麼提供解法 @_@

純 CSS 的追蹤技巧

Hacker News 上看到的 PoC,程式碼就放在 GitHubjbtronics/CrookedStyleSheets 上。能追蹤的細節當然比較少,不過透過 CSS 還是有不少資訊可以蒐集。

像是連結被觸發時:

#link2:active::after {
    content: url("track.php?action=link2_clicked");
}

瀏覽器的資訊:

@supports (-webkit-appearance:none) {
    #chrome_detect::after {
        content: url("track.php?action=browser_chrome");
    }
}

字型的 fingerprint:

/** Font detection **/@font-face {
    font-family: Font1;
    src: url("track.php?action=font1");
}

#font_detection1 {
    font-family: Calibri, Font1;
}

捲頁行為:

@keyframes pulsate {
    0% {background-image: url("track.php?duration=00")}
    20% {background-image: url("track.php?duration=20")}
    40% {background-image: url("track.php?duration=40")}
    60% {background-image: url("track.php?duration=60")}
    80% {background-image: url("track.php?duration=80")}
    100% {background-image: url("track.php?duration=100")}
}

算是提供了不少除了 <noscript></noscript> 外的手段,不過一般網站要引入這些技巧需要改不少東西就是了... (或是需要透過 server side plugin 的修改進行追蹤)

CPU 成為現代網站的速度瓶頸

在「Tracking CPU with Long Tasks API」這邊提到的現象,雖然是在提新的 API,不過裡面提到了很重要的問題。

以前的網站因為 js 都沒有用的那麼多,所以主要的瓶頸在於網路速度。所以大家最佳化的方向都是往「如何讓傳輸量變小」的方式進行,像是各類 js 的 minify,甚至是對 Gzip 演算法的暴力改善 (維持相容的 Zopfli,以及新的 Brotli):

In the old days, delivering a fast user experience depended primarily on download speed. One reason why the network was the main bottleneck back then is that JavaScript and CSS weren’t used as much as they are now, so CPU wasn’t a critical factor.

而現代網站使用 js 的情況已經是來到了新的境界 (甚至很多網站是沒有 js 就不會動),於是對於 CPU 的能力就愈來愈要求:

According to the HTTP Archive, the top 1000 websites download five times more JavaScript today compared to seven years ago.

而手機也愈來愈普及,CPU 的能力相較起來就更嚴峻了...

LINE 將內部的座位表由 Excel 改成 Web 界面...

LINE 將內部的座位表由 Excel 管理,改用 Web 界面了:「Excel管理の座席表をLeafletでWeb化した話」,這邊不確定是全球的 LINE,還是只有日本的 LINE...

如果跟日本人有過業務合作的話,就會知道他們對 Excel 的用法只能用

出神入化

來形容啊... 所以看到 LINE 特地寫了一篇來說明他們開發內部系統的事情,覺得還蠻有趣的...

起因是今年四月換辦公室,所以就順便換系統,把本來用 Excel 管理的座位表改用 Web 管理 (然後用了 Leaflet 這個 JavaScript Library):

人員の増加に対応するために、今年の4月、LINEはJR新宿ミライナタワーに移転しました。移転に伴い、IT支援室ではいくつかの新しい社内システムを導入しましたが、今日はその1つである「座席表」についてお話させていただきます。

這是 Excel 版本的樣子:

這是新版本的樣子,UI 上有更多互動的界面可以操作:

然後文末提到了總務業務量減少,而且因此變更座位變自由了而大受好評 (大概是不會讓總務煩死,所以就可以更自由換來換去 XDDD):

今回開発した座席表は総務の業務軽減に始まったプロジェクトでした。そして実際に導入後には、座席表の管理にかけていた総務の業務を大幅に削減することに成功しました。また、利用者からもかなり好評で、「これを待っていたんですよ!」といった声もあり、社内コミュニケーションの円滑化に一役買うことができているようです。誰の席でも自由に変更できるという点についても、これまでのところトラブルの報告を受けることなく運用できています。

翻了一下英文版的 blog,好像沒有提到這件事情?XDDD

JSON 的 Object 裡 Key 重複的問題

tl;dr:不要亂來啦... 這是 UB (Undefined behavior) 的一種。

因為看到這則 tweet,所以去查一下 JSON 的資料:

首先是找標準是什麼。在維基百科的 JSON 條目裡提到了有兩份標準,一份是 RFC 7159,一份是 ECMA-404

Douglas Crockford originally specified the JSON format in the early 2000s; two competing standards, RFC 7159 and ECMA-404, defined it in 2013. The ECMA standard describes only the allowed syntax, whereas the RFC covers some security and interoperability considerations.

ECMA-404 裡面就真的只講語法沒講其他東西,而在 RFC 7159 內的 Object 則是有提到 (重點我就用粗體標起來了):

An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The names within an object SHOULD be unique.

   object = begin-object [ member *( value-separator member ) ]
            end-object

   member = string name-separator value

An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates.

JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences.

粗體有描述唯一性,但尷尬的地方在於他用 SHOULD 而非 MUST,所以 library 理論上都要能接受。但後面提到如果不唯一時,行為無法預測 (會到 rm -rf / 嗎?XDDD 最像的應該還是 crash?),所以還是不要亂來啦...

不過如果真的會 crash 的話,應該也會因為 DoS issue 而被發 CVE,所以實務上應該是不會 crash 啦...

Rust 是不錯啦,不過...

作者寫了一篇「Creating Rust-based NodeJS modules」講同樣演算法 Node.js 要跑 3.5 秒,Rust 只要跑 130ms,所以 Rust 很棒棒之類的...

So about 3.5 seconds for an answer, in web time that is like an eternity. Our algorithm is a very straight forward one, basically just a filter on a large array.

The exact same algorithm, with the exact same CSV and coordinates is now executing in about 130ms.

然後仔細看了一下他的範例,holy...

這讓我想到之前在「看到 zmx 貼了之前的連結,更確信 Uber 的問題不是技術問題了...」這篇提到的文章「Unwinding Uber’s Most Efficient Service」:

很想講「傻逼你先把演算法修好再來怪 Node.js 慢」,程式會愈來愈難維護都是你們這種人引入一堆複雜的東西 -_-

GitHub 上有大量重複的程式碼...

扣除掉 fork 的程式碼後,研究人員在 GitHub 上還是發現有大量重複的程式碼:「DéjàVu: a map of code duplicates on GitHub」。

This paper analyzes a corpus of 4.5 million non-fork projects hosted on GitHub representing over 482 million files written in Java, C++, Python, and JavaScript. We found that this corpus has a mere 85 million unique files.

Java/C++/Python/JavaScript 寫的 4.5M 個專案有 482M 個檔案,但只有 85M 個檔案是不一樣的 XD

想一想其實也是... 現在愈來愈多工具產生程式碼了 XD (i.e. Scaffold)

所有主流瀏覽器的最新版都支援 WebAssembly 了

Mozilla 的「WebAssembly support now shipping in all major browsers」提到了最近幾個禮拜,新版的 SafariEdge 都相繼支援 WebAssembly 了:

In the past weeks, both Apple and Microsoft have shipped new versions of Safari and Edge, respectively, that include support for WebAssembly.

由於 ChromeFirefox 都已經支援了,這宣告 WebAssembly 的障礙都已經排除了,接下來只是時間的問題... 對於需要效能的應用程式來說多了一個方式加速。

把 Ptt 網頁版 Imgur 的圖片換回來...

Ptt 網頁版不知道什麼時候開始把 Imgur 的圖片變成 embed 版本了,圖很小又有留白一堆東西,看起來不太舒服...

剛剛寫了個 Greasemonkey script 換回來:「gslin/ptt-imgur-cleaner-gm」。已經有安裝 Userscript 管理軟體的,可以在 OpenUserJS 上安裝:「Ptt Imgur Cleaner」。

程式做幾件事情,一件是加上 meta tag 不要送 Referrer,然後用圖片換掉 Imgur 產生出來的 iframe,另外一個是把 .richcontentmax-width 設為 100%。

這樣看 Ptt 的文章應該會方便一些...

Update:結果有朋友說當初是因為被 Imgur 擋掉所以才換成 embed 的... (大概是量太大的關係)

Archives