Android 簽名漏洞分析
前面介紹了,Android 的簽名在理論上可以防止別人破環(huán)丁軟恩代碼)
能以作者的名義發(fā)布.但是Android 的簽名機(jī)制最近接連暴露了兩個(gè)涌洞,導(dǎo)致整個(gè)簽名機(jī)
第一個(gè)漏洞是由國外的安全公司 Bluebox Security 發(fā)現(xiàn)的,這個(gè)漏洞目 Android 1.6以來就
同虛設(shè).
直存在,號(hào)稱對(duì) 99%的Android 設(shè)各造成了影響.惡意軟件制作者可以在不破壞原有apk
的前提下,利用這個(gè)漏洞來修改 apk 的代碼并繞開 Android 應(yīng)用的簽名驗(yàn)證機(jī)制。
這個(gè)漏洞的原理是安裝apk 文件時(shí),如果apk 包中同時(shí)存在著兩個(gè) classes.dex 文件,安裝
讀到第二個(gè) classcs.dex 時(shí)會(huì)覆蓋掉第一個(gè).這樣實(shí)際進(jìn)行簽名檢驗(yàn)的是第二個(gè) classes.dex.
在運(yùn)行時(shí)仍然執(zhí)行的是第一個(gè)classes.dex,因此,只要設(shè)法在一個(gè)apk 文件中放置兩個(gè)classes.de
并使它們按照惡意classes.dex在前,正常classes.dex在后的順序出現(xiàn)在文件中,就可以繞開務(wù)
檢驗(yàn)并安裝成功.
這段出問題的代碼位于 libcore/luni/src/main/java/java/util/zip/ZipFile.java中,看看下面這段從
版本Android 4.2.2中摘錄的代碼:
private void readCentralDir()throws IOException{
.
// Seek to the first CDE and read all entries.
RAFStream rafs=new RAFStream(mRaf,centralDiroffset);
BufferedInputStream bin=new BufferedInputStream(rafs,4096);
byte[] hdrBuf-new byte[CENHDR];// Reuse the same buffer for each entry.
for(int i=0;i< numEntries;++i){
ZipEntry newEntry =new ZipEntry(hdrBuf,bin);
mEntries.put(newEntry.getName(),newEntry);
很明顯,最后這段for循環(huán)的代碼有問題,循環(huán)中讀取了壓縮包的內(nèi)容并逐項(xiàng)加入到 mEntries
中,而mEntries 是一個(gè)類型為LinkedHashMap的變量,調(diào)用 put0函數(shù)時(shí)如果有重名的項(xiàng),會(huì)覆
蓋前一項(xiàng)。
下面再看看Android5.0版本中的代碼,就知道Google 如何修復(fù)這個(gè)漏洞了:
private void readCentralDir()throws IOException{
RAFStream rafStreamnew RAFStream(raf,centralDiroffset);
BufferedInputStream buf feredstream =new BufferedInputstream(rafstream,4096);
byte[] hdrBuf=new byte[CENHDR];//Reuse the same buffer for each entry.
for(int i0;i< numEntries;++i){
ZipEntry newEntry=new ZipEntry(hdrBuf,bufferedstream);
if(newEntry,localHeaderRelOffset > centralDiroffset){
Hinu aoitsxin
throw new ZipException("Local file header offset is after
central directory");
String entryNamenewEntry.getName())
if(entries,put(entryName,newEntry)!null){
throw new ZipException("Duplicate entry name:"+entryName);
}
}
}
新的代碼會(huì)先檢查 entries 中是否已經(jīng)存在同名的項(xiàng),如果有就會(huì)拋出異常。這個(gè)漏洞任
Android4.3中就已經(jīng)修正了。
2.4 Android中的簽名
可能有人會(huì)感興趣,如何制造一個(gè)這樣的 apk 文件呢?其實(shí)很簡單,這里就不介紹了。當(dāng)然
檢測(cè)這種惡意程序也很簡單,只要發(fā)現(xiàn)一個(gè)apk中有兩個(gè)classes.dex就可以判定,正常的apk文
件不會(huì)包含兩個(gè) classes.dex 文件.
第二個(gè)Andorid 簽名漏洞最早由國內(nèi)的安全 team 發(fā)現(xiàn)并提交給 Google,Google 很快修復(fù)了
該漏洞。這個(gè)漏洞利用了在Android 簽名驗(yàn)證過程中,對(duì)Zip 文件進(jìn)行16位數(shù)的讀取時(shí),沒有考
慮到大于2~15的情況。這樣在將short 型表示的塊大小轉(zhuǎn)換成int型時(shí),會(huì)把大于215的數(shù)轉(zhuǎn)換成
int 型的負(fù)數(shù)。但是,在native 層執(zhí)行時(shí),并不會(huì)出錯(cuò)。因?yàn)镴ava的int,short,long都是有符號(hào)
數(shù),而不像C/C++中還有無符號(hào)數(shù)。
具體的漏洞原理就不分析了,有興趣的讀者可以上網(wǎng)搜索。
