python format 槽中槽_printf中的槽和实参--对比python struct包
在一個很簡單的printf調用中:
printf( "blit (T:%d, L:%d, W:%d, H:%d) to (T:%d, L:%d, W:%d, H:%d) costs %d
ticks(%dms)\n",
nPositionY, nPositionX, nWidth, nHeight,
nPositionY, nPositionX, nWidth, nHeight,
clkCost, time_ms( clkCost ) );
原意是讓clkCost匹配costs %dticks,讓time_ms(clkCost)匹配(%dms)。
但clkCost是long long類型(8字節),匹配完costs %dticks(4字節)后會侵占后面(%dms)中的位置,直接導致time(clkCost)的值沒有位置輸出。
C中的printf函數沒有參數長度檢查,所以在編譯期間無法發現這個漏洞。
類似的錯誤還有參數長度不足或嚴重不匹配(多見于字符串),直接導致程序crash。
這兩錯誤的本因是printf調用的壓棧、解讀策略:
首先定義兩個名詞:
實參 -- printf中第一個參數之后的參數,即除格式字符串之外的所有參數。
槽?? -- 格式字符串中的匹配點,即%d, %s, %f等。
1. 調用printf壓棧時實參逐個進棧,并不記錄棧中每個實參的具體位置。
2. 解讀格式字符串時每遇到一個槽即從棧中讀取相應字節數進行替換:例如遇到%d則讀4個字節進行替換(讀指針隨即下移);遇到%s則讀取4個字節作為字符串首址讀取字符串并替換(首址錯誤可以導致crash或堆棧溢出);遇到%llx字讀取8個字節進行替換......
這種不檢查長度的替換策略導致的問題中最臭名昭著的莫過于“堆棧溢出攻擊”。本文不詳談。
下面再看看開頭的例子,其中clkCost是8字節類型,進棧后一切變量類型都失去了意義,所有數據只有被解讀時才被賦予意義。cost %dticks中的槽從棧中讀取4字節替換%d,clkCost的高字節則被(%dms)中的槽讀去,格式字符串解讀結束。
不知python的發明人是否多次被此類問題叨擾,在python的"壓棧、解讀"包struct中有明確的長度檢查,即使實參是字符也會要求明確其長度:
cont = 'abcd'
struct.pack( '%ds' % len(cont), cont )
struct.unpack( 's'*len(cont), cont )
不過python中的問題也只有在運行時才會出現,這一點并不比C優越,但python拋出的異常可以提供更多的錯誤信息,比C的直接crash要來的溫和很多。
閱讀(1337) | 評論(0) | 轉發(0) |
總結
以上是生活随笔為你收集整理的python format 槽中槽_printf中的槽和实参--对比python struct包的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: python gridfs_python
- 下一篇: sql server 替换有反斜杠的字符