作者：vivo 網際網路大前端團隊 - Ma Lian
本文主要描述了FileProvider，startAnyWhere實現，Parcel不對稱漏洞以及這三者結合產生的漏洞利用實戰，另外闡述了漏洞利用的影響和修復預防措施，這個漏洞波及了幾乎所有的Android手機，希望能帶給讀者提供一些經驗和啟發。
一、背景
大家應該看到過一篇《2022年的十大安全漏洞與利用》的文章，文章中提到一個漏洞：
利用Android Parcel序列化和反序列不匹配，藉助應用FileProvider未限制路徑，可以獲取系統級startAnyWhere能力，從而獲取使用者敏感資訊，修改系統配置，獲取系統特權等等。
這裡面有三個關鍵詞：
-
Parcel不匹配漏洞
-
startAnyWhere
-
FileProvider未限制路徑
看到以上，大家可能會就其中涉及到的幾個點有些疑問：
-
startAnyWhere是什麼意思，是什麼樣的能力？
-
Parcel不匹配漏洞是什麼原理，是如何產生的？
-
FileProvider的作用是什麼，未限制路徑又是什麼問題？
-
這幾者之間存在什麼關聯，又會帶來哪些風險？
二、FileProvider
2.1 功能簡介
首先我們來簡單講一下FileProvider，FileProvider其實就是用來程序間共享檔案的。
上方左側圖是早期的應用間共享檔案的方案，就是A應用把檔案存在外接儲存，然後把檔案的實體地址給到B應用，B應用去這個地址去取。
那麼這樣的方式存在哪些問題呢？有以下幾點：
-
許可權無法控制：檔案存放的位置，要保證都能訪問，這樣無法精確控制許可權；
-
許可權無法回收：檔案一旦共享，無法撤銷；
-
目錄結構暴露：檔案共享需要公開原始的檔案地址，暴露了目錄結構；
-
隱私內容洩露：部分私有目錄檔案共享存在安全隱私洩露的風險。
基於以上問題，google基於ContentProvider設計了FileProvider，如上方右側圖，檔案共享必須基於FileProvider，由AMS來管控許可權，提供的協議也是定製的content協議。
2.2 使用簡介
瞭解了FileProvider出現的背景，下面介紹一下FileProvider的使用，使用FileProvider需要提供四個引數：
-
Uri(檔案地址)
-
Action(接收方資訊)
-
Type(檔案型別)
-
Flags(授予許可權)
如下面程式碼，最終透過startActivity來發起共享，記住這個startActivity，很重要。
Intent intent = new Intent();
intent.setAction("");
Uri uri = FileProvider.getUriForFile(getContext(), "", file);
intent.setType(getContext().getContentResolver().getType(uri));
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_GRANT_PERSISTABLE_URI_PERMISSION);
startActivity(intent);2.3 URI簡介
content URI和普通的Http協議一樣，也擁有scheme，authorities，path。
示例：content://authorities /XXX/xxx.txt。
Android提供了xml配置，如下程式碼所示，把實際的路徑對映成一個虛擬的名稱，這樣的優勢就是限制了路徑，可以把指定目錄的路徑共享出去。
看到這裡，大家就可以理解未限制路徑的含義了，簡單講就是把系統根目錄給共享出去了，正確的做法是隻共享需要使用的目錄。
<provider
android:name="androidx.core.content.FileProvider"
android:authorities="${applicationId}.file"
android:exported="false"
android:grantUriPermissions="true">
<meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/******_paths" />
</provider>
<?xml version="1.0" encoding="utf-8"?>
<resources>
<paths>
<files-path name="test_in" path="/test/file" />
<external-path name="test_external" path="/test/file" />
</paths>
</resources>2.4 許可權簡介
FLAG_GRANT_READ_URI_PERMISSION：檔案讀許可權；
FLAG_GRANT_WRITE_URI_PERMISSION：檔案寫許可權；
FLAG_GRANT_PERSISTABLE_URI_PERMISSION：持久授權，直至裝置重啟或者主動呼叫revokeUriPermission；
FLAG_GRANT_PREFIX_URI_PERMISSION：相同字首路徑統一授權。
2.5 授權方式
//第一種授權方式
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
//第二種授權方式
getContext().grantUriPermission("packageName", uri, Intent.FLAG_GRANT_READ_URI_PERMISSION);2.5.1 第一種授權方式：
一次授權，用完即止。
2.5.2 第二種授權方式：
-
不含持久授權flag的，許可權依附於程序存活；
-
包含持久授權flag的，重啟或者主動拒絕許可權才會消失。
2.6 小結
上面主要簡單介紹了一下FileProvider的設計思想、技術方案、使用方式，由此我們可以對文章開頭提出的一些疑問進行解答。
1、FileProvider的作用
答：跨程序共享檔案，一般透過startActivity的方式。
2、未限制路徑
答：沒有指定需要共享的檔案目錄，將系統根目錄共享出去了。
3、存在什麼風險，如何進行攻擊
答：單針對FileProivider來看，風險較小，光依賴FileProvider這個問題還是沒法進行攻擊的，原因如下：
-
檔案共享需要業務主動透過startActivity才能發起
-
讀寫許可權交由系統來管理
三、startAnyWhere
接下來講一下上文中提到的startAnyWhere，顧名思義，就是應用想開啟哪個頁面就開啟哪個頁面，那麼在Android系統中，誰才有這個能力呢？
3.1 實現原理
能夠實現startAnyWhere的只有系統SystemUid應用，這類應用在startActivity進行許可權校驗的時候是直接放行的，無論Activity是否exported，都能開啟，最常見的應用比如系統設定。
下面是一個系統設定開啟第三方應用的案例，透過設定可以直接開啟第三方的賬戶登入頁。
3.2 實現流程
透過設定頁面的新增賬號的功能，可以直接拉起對應應用的介面，這個是今天漏洞的核心，我們來看一下系統呼叫流程。
如下圖，首先系統設定呼叫AccountManager的addAccount，然後透過SystemServer中的AccountManagerService，一直呼叫到目標APP本身的AddAccount實現。
由APP本身提供一個Bundle，Bundle裡面本身包含了一個intent的由設定進行開啟。
這個裡面其實存在一個風險，第三方應用可以隨意提供一個惡意Intent，系統會直接呼叫startActivity，隨之而來的風險很大。
上圖中還存在一個第0步，即這個流程的發起方可以是三方應用本身，不一定需要從設定進入，那麼這個整個流程就閉環了，完全無需使用者介入，使用者也可以完全無感知。
不過這個風險呢，google在Android4.4之後已經修復了，4.4之後增加了對intent內容的校驗。
程式碼如下：
if (result != null&& (intent = result.getParcelable(AccountManager.KEY_INTENT)) != null) {
if (!checkKeyIntent(Binder.getCallingUid(),intent)) {
onError(AccountManager.ERROR_CODE_INVALID_RESPONSE,"invalid intent in bundle returned");
return;
}
}上面程式碼就是取出外部傳入的KEY-INTENT進行校驗，這裡面已經出現了今天的主角Parcel，整個攻擊也是透過Parcel漏洞使得惡意的KEY-INTENT繞過系統的檢查。
四、Parcel
下面我們看一下parcel漏洞及原理。
4.1 Parcel 簡介
parcel是專門為Android提供的一個序列化的類，parcel的原理其實很簡單，就是一個嚴格的對稱讀寫，如下程式碼所示。
public void writeToParcel(Parcel dest, int flags) {
dest.writeInt(mSize);
}
public void readFromParcel(Parcel in) {
mSize = in.readInt();
}同時序列化遵循基本的TLV格式，也就是Tag-Length-Value，Tag代表型別，Length代表長度，Value代表值，當然一些特殊情況：
-
Length不描述：有固定長度的型別可以不描述length，比如long，int等等；
-
Tag不描述：bundle序列化時，key一定是string型別，所以不需要描述Tag。
回到對稱讀寫這一塊，如果這個程式碼不對稱了會出現什麼情況呢，google曾經在android原始碼中出現了很多類似不對稱的錯誤，看一下下面幾個案例。
4.2 Parcel 不對稱讀寫案例
4.2.1 案例1
如下圖，這是一個典型且明顯的不對稱，writeLog&readInt，為什麼不對稱，很簡單，int和long對應的長度不一樣。
4.2.2 案例2
這是一個比較隱晦的不對稱案例，是Android原生的WorkSource類，這個不對稱一眼無法看出，以致於最近的Android版本這個問題一直存在，這個類也是此次漏洞攻擊真正被利用的一個類。
下面簡單看一下WorkSource序列化和反序列化的流程。
-
序列化
如下述程式碼，WorkSource序列化時，如果mChains是一個長度為0的空list，那麼就會走else分支，此時序列化會連續寫兩個0。
序列化：
public void writeToParcel(Parcel dest, int flags) {
dest.writeInt(mNum);
dest.writeIntArray(mUids);
dest.writeStringArray(mNames);
if (mChains == null) {
dest.writeInt(-1);
} else { // 當mChains不為空的時候，這時候寫了兩個0
dest.writeInt(mChains.size());// 寫第一個0
dest.writeParcelableList(mChains, flags);// 寫第二個0
}
}- 反序列化
如下述程式碼，WorkSource反序列化時，當讀到第一個0也就是numChains=0的時候，這個對應mChains長度為0，同樣也會走else分支，此時mChains直接被置為null，但是序列化其實是寫了兩個0，這時候後面還有一個0沒有讀，這樣序列化和反序列化就造成了不對稱。
反序列化：
WorkSource(Parcel in) {
mNum = in.readInt();
mUids = in.createIntArray();
mNames = in.createStringArray();
int numChains = in.readInt(); // 讀第一個0
if (numChains > 0) {
mChains = new ArrayList<>(numChains);
in.readParcelableList(mChains, WorkChain.class.getClassLoader());
} else { // 當讀到numChains=0的時候，這時候直接就將mChains置為null，第二個0還沒有讀
mChains = null;
}
}當然實際上不對稱的類還有很多，大家可以看下網上洩露出來的漏洞利用原始碼，有很多這樣的類，這裡就不列出來了，知道了漏洞的本質是因為Parcel讀寫不對稱，我們接下來看一下其中的原理。
4.3 parcel 漏洞原理
瞭解parcel漏洞真正的原理之前，首先來看一下系統校驗intent的序列化流程。
4.3.1 系統校驗序列化流程
首先攻擊者手動會序列化一次需要傳給系統的bundle，然後系統會反序列化一次進行校驗，校驗完之後又會重新序列化交給設定，然後設定真正去開啟頁面的時候會再次反序列化，這樣就經歷了兩次序列化與反序列化，因為其中讀寫不對稱，所以給了攻擊者有機可趁的機會。
4.3.2 漏洞原理簡介
這個漏洞核心就是前後一共經歷了兩次序列化和反序列化。我們以上面4.2.1案例1的不對稱舉例（readInt()對應writeLong()），當出現不對稱讀寫之後，兩次序列化與反序列化會有什麼後果？如下圖所示可以看到：
第一次序列化：輸入兩個int 1；
第二次反序列化：讀的時候是readInt()，讀出兩個int 1；
第三次序列化：寫的時候是writeLong()，這是分別寫了long 1和int 1，long的長度是int長度的雙倍；
第四次反序列化：讀的時候是readInt(),第一個long 1會被分成兩個int來讀，所以就一次讀成了101。
而攻擊者也正是藉助這個不對稱，導致實際輸入和輸出不一樣，隱藏了惡意的KEY-INTENT，從而繞過了系統的校驗，以此開啟任意一個頁面，實現startAnyWhere。
4.3.3 漏洞原理實踐
因為案例1比較明顯，google早已經修復該漏洞，而WorkSource因為比較隱晦，所以該漏洞一直存在，我們接下來看一下如何利用WorkSource來構造攻擊實現。
下面一張圖帶你搞明白如何透過兩次序列化和反序列化達到我們的目的：
由上述文章可知，最終給到系統校驗的是一個bundle型別的資料結構，bundle是儲存key-value型別的，而我們目的就是要將惡意的KEY-INTENT隱藏起來然後繞過系統的校驗。接下來詳細講一下實現步驟：
1、手動序列化：
如上圖左側第一列，手動序列化這個bundle，這個bundle序列化時攜帶了三個key-value：
-
第一個key-value：WorkSource相關的；
-
第二個key-value：經過精心構造；
-
第三個key-value：隱藏惡意的KEY-INTENT。
第一次序列化後的bundle透過16進位制列印出來如下圖所示：
2、系統進行反序列化
經過系統第一次反序列化，沒有觸發不對稱，系統是讀不到這個惡意的KEY-INTENT的，所以自然校驗透過。
3、系統重新序列化
系統校驗完需要重新序列化，這時候由於讀寫不對稱，最終紅色區域【1，-1】兩個值變成了【0，0】。
4、setting反序列化
setting再次反序列化，上面也講到了，由於不對稱，原本兩個0只讀了1個0。
5、解析最終的key-value
-
讀第一個key-value：由於上述WorkSource的不對稱，原本兩個0只讀了1個0；
-
讀第二個key-value：由於讀第一個時少讀了一個0，剩餘的0變成了第二個key-value的內容，整體內容錯位，由於遵循TLV的格式，錯位之後，0和13變成了第二個key-value的key，惡意KEY-INTENT前的所有值都變成了第二個key-value的value；
-
讀第三個key-value：此時真正惡意的KEY-INTENT變成我們需要的第三個key-value。
五、漏洞攻擊實戰
透過上面兩節，我們可以看到，藉助startAnyWhere和parcel漏洞，可以繞過系統校驗任意開啟一個頁面，下面來看兩個真實案例：
5.1 實戰案例1
可以看到在虛擬機器上，透過這個漏洞直接就開啟了鎖屏密碼的設定頁面，然後可以直接繞過密碼校驗將鎖屏密碼改掉。
5.2 實戰案例2
案例1已經足以反應出問題和風險，但是實際上國內的手機經過改造，基本不會存在這個問題，那麼我們來看一下真機上的使用案例：
在講這個案例之前，我們要先額外講一下XXSDK中存在的一個AsistActivity，裡面存在一段程式碼，如下所示。
這個程式碼很簡單，就是接受外部的intent的然後直接startActivity了，這裡面又提到了startActivity，上面檔案共享也是這樣呼叫的，正好符合了FileProvider的使用邏輯。
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//此處省略部分程式碼
Intent intent = getIntent().getParcelableExtra(Intent.EXTRA_INTENT);
int intExtra = intent == null ? 0 : intent.getIntExtra("", 0);
//此處省略部分程式碼
startActivityForResult(intent, intExtra);
}藉助這個類，我們便可以模擬一個完整的攻擊流程，如下圖所示：
-
第一步：攻擊APP構造一個intent1，這個intent1的意圖是開啟上述AssistActivity；intent1中攜帶了惡意的intent2，這個intent2的意圖開啟攻擊APP的指定頁面，然後讓應用共享指定檔案了；
-
第二步：呼叫andorid系統新增賬號頁面；
-
第三步：業務APP中由於整合了AssistActivity，接受惡意的intent2會直接startActivity進行共享檔案；
經過以上三步，直接就把APP的一些隱私檔案共享給攻擊APP，同時攻擊APP可以在惡意intent中授權直接修改檔案。
5.3 惡意intent的程式碼
下面看一下惡意intent的程式碼：
private Intent makeFileIntent() {
Intent intent1 = new Intent().setComponent(new ComponentName("XXX", "xxx.xxx.AssistActivity")); // 開啟AssistActivity
Uri uri = Uri.parse("content://xxxx/xxx_info");
Intent intent2 = new Intent(mContext, SecondActivity.class); // 開啟攻擊者的頁面並且共享指定URI的檔案
intent2.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
intent2.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
intent2.setType(mContext.getContentResolver().getType(uri));
intent2.setData(uri);
intent1.putExtra("key", intent2);// 惡意intent2放入intent1中
return intent;
}5.4 惡意序列化的程式碼
目前漏洞均已修復，為避免風險，不展示所有程式碼。
private static Bundle makeEvilIntent(Intent intent) {
Bundle bundle = new Bundle();
Parcel obtain = Parcel.obtain();
Parcel obtain2 = Parcel.obtain();
Parcel obtain3 = Parcel.obtain();
obtain2.writeInt(3);// bundle中key-va長度
obtain2.writeString("firstKey");
obtain2.writeInt(4); //VAL_PARCELABLE
obtain2.writeString("android.os.WorkSource");
obtain2.writeInt(-1);//mNum
obtain2.writeInt(-1);//mUids
obtain2.writeInt(-1);//mNames
obtain2.writeInt(1);//mChains.length
obtain2.writeInt(-1);
...此處省略一些構造程式碼
bundle.readFromParcel(obtain);
return bundle;
}以下是影片演示，透過上面這一段攻擊程式碼，拿到了手機上某個APP存在應用私有目錄下的賬號資訊， 同樣為了隱私，此處部分脫敏。
六、漏洞利用影響
透過上文的介紹，我們知道藉助這個漏洞可以實現對系統任意檔案的修改，下面列出了漏洞帶來的影響：
-
讀取使用者隱私資訊；
-
安裝惡意應用；
-
改寫動態載入的程式碼；
-
改寫系統配置；
-
獲取特殊許可權。
七、漏洞修復措施
除了發現問題更重要的是解決問題，下面列出了修復這個漏洞對應的一些方案：
系統層：
-
修復pacel漏洞的不對稱；
-
系統校驗的時候，做兩次序列化與反序列化；
應用層：
-
FileProvider增加路徑限制；
-
接受intent的Activity要著重注意校驗，設定黑白名單。
八、漏洞預防措施
漏洞其實是不可避免的，下面是面對層出不窮漏洞的一些預防措施：
-
元件能不匯出就不匯出；
-
可匯出的元件建議增加簽名或者包名校驗；
-
接受intent或者url引數務必校驗；
-
檔案共享務必遵循最小化原則；
-
敏感內容需要進行加密。
九、總結
接下來簡單回顧一下，本文主要講了5方面內容：
-
第1方面：主要描述了FileProvider，闡述了其出現背景、設計原理、使用方式、優缺點等；
-
第2方面：主要描述了startAnyWhere，闡述了其實現原理、實現方式；
-
第3方面：主要描述了Parcel不對稱漏洞，闡述了Parcel的設計原理、不對稱漏洞、漏洞案例、漏洞原理以及漏洞利用方案；
-
第4方面：主要描述了漏洞攻擊實戰，從模擬器到真機，從原理到程式碼，演示了透過漏洞攻擊手機、獲取使用者隱私資訊的流程；
-
第5方面：主要是講了漏洞帶來的影響、漏洞的修復和預防措施。
整體來講，這個漏洞波及了所有的Android手機，無論是對使用者，對企業都造成了巨大的損失。
作為開發者的我們需要從自身做起，守護好每一個環節，避免讓攻擊者有隙可乘。