在本文開始之前，請(qǐng)留意這是一份十分冗雜的信息安詳告示。有關(guān)于Windows節(jié)制呼吁符，我大概發(fā)明白一個(gè)可以通過簡(jiǎn)樸批處理懲罰文件舉辦進(jìn)攻的BUG。這個(gè)BUG存在于Windows 2000版本以上的64位以及32位呆板上，它是一個(gè)批處理懲罰理會(huì)錯(cuò)誤。它不需要特別安裝任何軟件（cmd.exe是Windows默認(rèn)安裝的），它可以由任意權(quán)限的用戶提倡（假設(shè)他們可以運(yùn)行cmd.exe，從而理會(huì)批處理懲罰文件）包羅理會(huì)錯(cuò)誤產(chǎn)生的位置（妨礙代碼可以或許表明這個(gè)原因）。這并不是一個(gè)遠(yuǎn)端節(jié)制條理的BUG，僅僅是一個(gè)DoS范例，需要獲得用戶請(qǐng)求才氣運(yùn)行（可能是把其作為一個(gè)開機(jī)啟動(dòng)項(xiàng)）。可是由于他的簡(jiǎn)樸性，以及Windows系統(tǒng)的普及率，我小我私家認(rèn)為它值得你看上那么一眼。
請(qǐng)留意，假如你啟用這些批處理懲罰文件導(dǎo)致系統(tǒng)瓦解我是不認(rèn)真任的！任務(wù)打點(diǎn)器會(huì)竣事這個(gè)失控劇本的PID，以防備你運(yùn)行。
Tldr：一個(gè)僅僅包容^ nul<^ 的批處理懲罰文件會(huì)造成一個(gè)龐大的內(nèi)存泄漏，在一個(gè)僅僅只有 ^|^ 的批處理懲罰文件會(huì)使呼吁行無限遞歸導(dǎo)致瓦解。這些行為大概導(dǎo)致一些有趣的批處理懲罰編程，雖然我是指的在windows2K版本以上的操縱系統(tǒng)中，原因在于cmd.exe在處理懲罰批處理懲罰文件時(shí)產(chǎn)生的邏輯錯(cuò)誤。
當(dāng)我再回覆一位用戶提出的問題時(shí)，我碰著一個(gè)十分有趣的批處理懲罰文件理會(huì)異常，假如^這個(gè)字符是文件的最后一個(gè)字符，就大概產(chǎn)生內(nèi)存泄漏，插入文件的最后一個(gè)字符不可以或許是 n （換行符），由于 r （回車符）在脫字標(biāo)記之前就已經(jīng)執(zhí)行，所以沒有這種環(huán)境產(chǎn)生，理會(huì)器可以或許正常事情，沒有什么可以追蹤到（當(dāng)插入^rt，理會(huì)卻成為了^r “t”就被忽略掉了）。最后留意一下，回車字符是可以或許正常執(zhí)行的，雖然這也是一個(gè)小趣點(diǎn)，我們可以在大大都文本編輯器中對(duì)回車字符造假，在記事本的最后你可以傻逼的認(rèn)為哪里尚有一個(gè)回車符
顛末一系列的折騰，我發(fā)明^字符在文件的最后大概導(dǎo)致內(nèi)存泄漏，可能會(huì)致使呼吁提示符瓦解（詳細(xì)點(diǎn)說就是 command.com 可能cmd.exe措施），我還發(fā)明非凡的批處理懲罰文件（及其序列）會(huì)引起一些有趣的現(xiàn)象。進(jìn)一步的觀測(cè)，引導(dǎo)我去存眷 是否其他人也有碰著過雷同的環(huán)境， a Stack Overflow question where a user noted a memory leak（在Stack Overflow提問中一個(gè)用戶暗示內(nèi)存泄漏）在SS64.com的主題 other interesting behaviors with the caret at the EOF（在文件最后加上回車符引起的有趣現(xiàn)象）。Stack Oveflow上面的提問輔佐我確認(rèn)了這并不是一個(gè)無限輪回范例的環(huán)境，可是并沒有表明清楚到底是怎么一回事，在SS64.com的主題中大部門內(nèi)容都是在接頭從各個(gè)方面讓呼吁提示符瓦解，可是并沒有對(duì)道理舉辦表明。
自然的在我心中發(fā)生了疑問，到底是怎么產(chǎn)生的？怎么產(chǎn)生的呢？這個(gè)環(huán)境是否可以舉辦操作呢？謎底是巨大的，可是辦理要領(lǐng)確是很簡(jiǎn)樸（至少看起來簡(jiǎn)樸），我發(fā)明一些欺騙批處理懲罰文件組合，可以或許發(fā)生內(nèi)存泄漏。是快是慢取決與你放入的批處理懲罰文件是什么（不是插入了幾多字符，而是管道序列，以及行數(shù)長(zhǎng)度）無論是呼吁提示符瓦解照舊內(nèi)存泄漏，理會(huì)代碼一直都是在單線程中駐留，所以CPU的占用量一直在增漲（單核CPU平均占用率到達(dá)98%）
讓呼吁提示符瓦解很簡(jiǎn)樸，一個(gè)沒有換行的批處理懲罰文件只需要包容 ^&^ (可能 ^|^)就足以導(dǎo)致呼吁提示符呈現(xiàn)0xC00000FD錯(cuò)誤 ，這是一個(gè)由于無限遞歸棧/幀呈現(xiàn)的泄漏。這重現(xiàn)了“無限輪回”的場(chǎng)景，但沒有完美表明內(nèi)存泄漏（可能說是為什么這個(gè)無限輪回會(huì)導(dǎo)致瓦解），工作到這個(gè)水平，我開始通過舉辦一些最簡(jiǎn)樸的要領(lǐng)來發(fā)生一個(gè)內(nèi)存泄漏，事實(shí)證明，一個(gè)2字節(jié)的批處理懲罰文件是需要耗損整顆CPU以及吃內(nèi)存的（盡量速度慢的離譜，~8k/5s on a 2.2GHz i7）
我用來測(cè)試的批處理懲罰文件包括以下16進(jìn)制字節(jié)
0x01 0x5E
0X5E 是脫字標(biāo)記(^) ，0X01是標(biāo)題開始的Ascll碼。第一個(gè)16進(jìn)制代碼，在這個(gè)BUG中危險(xiǎn)水平?jīng)]有其它的高，因?yàn)樗荒苁荖ULL（0X00），r, |, 可能 & 這些字符會(huì)導(dǎo)致批處理懲罰文件通過正常途徑退出（也就是 ‘invalid command detected’）。我利用0X01證實(shí)它沒有一個(gè)有效的呼吁（可能顯示出有關(guān)的字符）導(dǎo)致這個(gè)BUG，一個(gè)2字節(jié)的批處理懲罰文件包括一個(gè)簡(jiǎn)樸的^就足夠了。
做一些其他測(cè)試，我發(fā)此刻批處理懲罰文件最后加上^ nul<^是最快也是最簡(jiǎn)樸的耗損CPU的要領(lǐng)。
隨機(jī)的運(yùn)行若干次后，請(qǐng)?zhí)岣吡粢猓@么做去耗損64位系統(tǒng)CPU是很快的。僅僅是花了20S，就吃掉了我14G的RAM（總共16GB，四核I7而且利用超線程技能），最后我不得不重啟電腦。在32位系統(tǒng)上運(yùn)行這個(gè)快速版本，盡量32位系統(tǒng)有2GB的限制，呼吁理會(huì)器也會(huì)很快的因?yàn)閮?nèi)存不敷而竣事任務(wù)。它不會(huì)導(dǎo)致呼吁提示符瓦解，相反的，它好像有一個(gè)檢測(cè)機(jī)制掩護(hù)內(nèi)存分派，當(dāng)它不可以或許直接終止批處理懲罰歷程時(shí)。