• 吃人一口,還人一斗 我思故我在

    字面上意思是說,受別人一點幫助,就要思考如何回報他更多。

    同義的:受人點滴,湧泉以報

    我覺得更值得更深入思考的是,

    當你輕易地要求別人的幫助時,你就得有心理準備,要返還十倍或更多。

    所以,當自己能做到,不輕易要求別人的幫忙。

    (說到這裡,小伙伴會覺得跟我以前說的”情感投入報酬”不一樣,情境不同暫不展開)

    這是台灣的俗語,用台語發音更有味道。

  • 瘋狂宇宙 我思故我在

    這個宇宙太瘋狂,大海掀翻了小池塘。

  • 區塊鏈是工具,要合理的使用;而非商品炒作。我思故我在

  • 賀賀郎,哇嗄哩供喂 我思故我在

    意思就是說,我是一個好好的、正常的人,我幹嘛跟你講話。

    一般用於朋友間小小辨論時,無法說服對方而使用。

    請不要企圖說服價值觀不在同個方向上的人或朋友。

  • Ethereum 塞車體驗 我思故我在
    下午四點,第一次體驗到 Eethereum 的塞車,一個 Uniswap 的交易等了一個鐘頭

    約1600 左右的交易,到 1702 收到通知完成

    不是說好的幾秒鐘,幾分鐘哦。造成這個情況的這是 TPS 限制嗎?還是真的有大量垃圾訊息或攻擊導致的?

  • 中心思想 我思故我在

    行為會改變、技術會改變,但中心思想不會變
    如同你會隨著環境而適應,但你的價值觀沒那麼容易改變

    中心思想、價值觀要改變,需要非常深刻的思考及體會,一般人在成長階段接受了某種價值觀,就不容易再改變了。

  • 現在想想,還好選了 ethereum 入門 我思故我在
    當時本來是想跟 Bruce 在公司的決定一樣,從 Fabric 開始。最近沒聯絡不知道發展得如何?

    還好選了 ethereum 入門

  • 成大事者不拘小節 魔鬼藏在細節裡 我思故我在

    兩句話看似相互矛盾,但其實使用的場景是不同的
    年輕人,把這兩句話串在一起,就定位成幹話

    真的這淺薄嗎?

  • 想像力比知識更重要?我思故我在

    你的問題在於書讀得太少,想得太多。

    如果是可比較的,那請您思考:想像力固然重要,是不是應該讓你的知識追上你的想像力?

  • 學士碩士博士的不同 我思故我在
    學士 學習知識 判斷問題(價值)
    碩士 運用知識 解決問題
    博士 創造知識 發現問題

智能合約的漏洞與攻擊1/3-漏洞1

以太坊 ethereum andy 4周前 (08-31) 134次浏览 已收录 0个评论 扫描二维码

智能合約的漏洞與攻擊-漏洞1

近期在 DeFi 圈裡,發生了不少智能合約的漏洞與攻擊事件,每次都會使數位資產受到一定程度的損害。小則價格下跌,大則代幣被洗劫一空。至於像那種 lendf.me 的事件,先被洗劫又還回來的情況,真的只能說是幸運,如果有下次還會還回來嗎?
我把合約造成的問題分為三種,1、漏洞 2、攻擊 3、管理/機制問題。漏洞指的是開發合約時,對以太坊本身不夠了解所造成的錯誤使用,包括區塊鏈本身及合約語言,而產生的資產損失。攻擊指的是以太坊或智能合約本身出現的問題,而非開發者所導致的遭受攻擊。管理/機制問題,指的是因為功能或是某種機制的設計錯誤,而導致的損失或遭受攻擊。
管理/機制的部份,大多跟實際的業務邏輯有關,並且個案情況都不相同,因此這裡我們不個別說明,僅區分為漏洞及攻擊兩種討論。

整數溢出及下溢

溢出 overflow 發生在數值超過最大值時,比如 60+200 會超過 uint8 的最大值而變成 4。
下溢 underflow 發生在數值小於最小值時,比如 60-200 會低於 uint8 的最小值而變成 116。
在我的經驗裡,新手開發者最常發生在 uint8 uint16 ,因為它們的數值範圍較小。而進階開發者則較容易發生在數值範圍較大的 uint24 之類的。
要完全避免這種問題,應該使用另外建立的程式庫來檢查、計算。或是使用 OpenZeppelin 的 SafeMath 程式庫,用 add、sub、mul、div 、mod 來取代 +=*/%等運算操作

依賴時間戳 Timestamp

用 now 或 block.timestamp 取得的區塊時間戳,產出這個區塊的礦工在產出時可以操作這個時間戳的。使用區塊的時間戳時要注意下面的三點。

時間戳是可操作的

礦工在區塊驗証之後15秒內可以自行確定時間戳的值,所以如果你的合約是屬於樂透彩票類的合約,使用 timestamp 來做為中獎的隨機數種子,那可能會有礦工進來買你的彩票,然後透過操作 timestamp 來讓礦工自己中獎。
所以時間戳不應該用來做為隨機數種子。

15秒規則

以太坊的參考手冊黃皮書中沒有限制多少時間要產生多少區塊,但是區塊的 timestamp 必需比父級區塊的時間來得大。但是大多的協議還是拒絕超過15秒的區塊,所以依賴於時間的事件,還是可以15秒為基礎來進行變化。

不要用 block.numer 來預估時間

雖然可以用 block.numer 及平均的區塊時間來預估時間,但是這樣的區塊時間還是可能會改變,可能會破壞合約的功能。所以最好還是不要使用 block.number 來推估時間。

透過 tx.origin 驗証授權

tx.origin 是一個全局變數,返回發起交易的地址。要注意的是,合約可以被其他合約調用,所以當攻擊合約使用 fallback function 來調用時,使用 tx.origin 來驗証授權,就可能出現漏洞。
要防止這種漏洞產生,可以使用 msg.sender 來驗証授權。

浮動式的編譯器版本號 Floating pragma

這樣的設計本來是為了做好程式碼的最佳化,所以指定一個編譯器版本號。但是這個設計就可能會讓開發者指定了一個有問題的編譯器版本,可能會導致 bug ,讓合約處理危險之中。
在開源項目裡面,指定編譯器的版本號,也代表這個程式跟編譯器版本的配合,是經過測試的。除了 library 跟 package 之外,編譯器的版本號要對應本地的編譯器版本。

編譯器版本太舊

新的編譯器會修正已發現的編譯器問題,所以開發者應該保持最新的編譯器版本。

功能函數預設的可見性

函數的可見性可以指定為 public, private, internal, external. 功能函數可見性的預設值是public ,如果開發者沒有指定正確的可見性,沒有把應該私有的設為 private , 就會引來攻擊,可能意外的導致合約狀態改變。

狀態變數預設的可見性

通常開發者會宣告函數的可見性,但是變數的可見性卻很少宣告。狀態變數可以宣告為 public private internal 。還好預設的可見性是 internal 而不是 public 。
這個重點是要明確,明確地限定誰可以訪問這個變數。

沒有保護的 ether 提款

如果沒有適當的訪問控制,有心人可能就可以從合約裡面提領出原本不該提領的 ether 。這可能是由錯誤命名的構造函數所導致的,比如說讓任何人都可以重新初始化合約,進而填入可以操作合約餘額的地址。要防止這種漏洞,限制只允許被授權或按計畫的人提款。然後,構造函數一定要正確地命名。

錯誤的構造函數名稱

在 Solidity 0.4.2 之前,構造函數的名稱只能跟合約同名。在某些情況下,這就可能出問題,比如說,這個合約被改名後重新使用,但是構造函數名稱沒有更改,變成了一般的可調用函數。
在比較新的編譯器版本,可以使用 constructor 這個關鍵字來定義構造函數。這樣就可以避免這個漏洞。

未檢查回傳值

如果低層級調用的返回值未經檢查,可能在調用的函數失敗的時候程式還能繼續往下執行。這樣就會導致程式意外的行為,破壞程式的邏輯。而且調用失敗可能是由攻擊者造成的,這個情況可能被進一步的利用,產生其他種類的問題。
Solidity 裡的低層級調用有 address.call() address.callcode() address.delegatecall() address.send() 或是使用合約來調用,像是 ExternalContract.doSomething() 。這些低層級調用不會 throw exception 而是返回 false 。
使用低層級調用時,確定檢查返回值來處理可能失敗的調用。

沒有保護 selfdestruct 命令

selfdestruct 是刪除合約的命令。如果發生錯誤或不足的權限控制,惡意人士就會用來刪除合約。如果必要的話,可以使用多重簽名來防止這種攻擊。
這種攻擊曾經在 2017年發生,叫做 Parity attack 。一個匿用戶發現並且利用了存在智能合約程式庫裡的漏洞,把他自己變成合約的擁有者,然後刪除了合約,這導致 587 個錢包裡面的資金共 513774.16 eth 被堵住了。

未初始化的存儲指針

資料在 EVM 裡面以 storage memory calldata 三種不同方式儲存。充分了解及正確地初始化是重點。錯誤的初始化存儲指針或是未初始化,就會導致合約漏洞。
在 Solidity 0.5.0 版本之後,未初始化的存儲指針就不再是問題了,因為未初始化的存儲指針不會被編譯。但是充分了解什麼時候使用什麼存儲指針,還是很重要。

Assert 違規

從 Solidity 0.4.10 開始,提供 assert() require() revert() 三個錯誤處理函數,這裡針對 assert 來說明
正式的說 assert() 是為了檢查一個不變量,非正式的說 assert() 是一個過度的保鏢,保護合約的過程中也消費燃料。一個運作正常的合約不應該觸及 assert 描述。要嘛是錯誤的使用了 assert() ,要嘛是合約裡有個 bug 把 assert() 置於無效的狀態之中。
如果 assert() 檢查的條件是不變的,可以使用 require() 來代替。

使用已廢棄的函數

有些函數 Solidity 已經廢棄,由更好的函數來代替。不要用到已經廢棄的函數是很重要的,因為會導致意外的效果和編譯錯誤。
下表是已經廢棄的和取代的函數

智能合約的漏洞與攻擊1/3-漏洞1

Delegatecall 調用不被信任的調用目標

Delegatecall 是一種特殊的消息調用,幾乎等同於正規的消息調用,除了1、目標地址的執行環境是在調用合約之中 2、msg.sender 3、msg.value 三項之外,其他全部相同。
delegatecall 實際上可以看做,委托其他合約來修改調用合約的變量。
由於 delegatecall 給予了其他合約很大的權限,所以只能用來調用已經被信任的合約。如果調用的地址是來自於外部,那就必須驗証這個地址是否被信任。

簽名的延展性

通常會以為智能合約使用了加密簽名系統,所以簽名是唯一的,但實際上並不是。Ethereum中的簽名,可以在沒有私鑰的情況下修改,而且是有效的。
例如,橢圓密鑰加密中的v,r,s 值,以正確的方式修改這三個值,可以得到一個有效的簽名,但其實你並沒有正確的密鑰。
要防止這個問題,不要在合約中用簽名來檢查以前的消息簽名,有點繞口,就是不要為了檢查過往的簽名,而在合約裡產生簽名。因為惡意的用戶會找到並且重建簽名。

缺少對簽名重製攻擊的保護

有時候合約需要驗証簽名來提高可用性和燃料成本,就要考慮到實現簽名驗証。

要對簽名重製攻擊的保護,合約應該只允許新的 hash 被處理。這樣能防止惡意用戶反復的執行猜測其他用的簽名。
特別安全的簽名驗証,應該考慮以下的建議:
儲存每個由合約產生的消息的 hash ,在執行函數前檢查消息hash 跟已存在的hash
包括地址在內,確定消息只用在單一合約內
不產生消息hash包括簽名。

重復的狀態變數

在 Solidity 裡面,同名的變數是可能發生的,但是會導致超乎預期的副作用。發生在合約的繼承時特別難以區分,試想一下,父子合約都有同名的 a 變數,但是值是不相同的。在子合約裡使用 a 的值來執行自父合約繼承而來的函數,此時這個函數的結果就會是錯誤的,因為在子合約裡 a 的值跟父合約裡的值已經不一樣了。
要防止這個漏洞,我們就檢查合約系統內所有的合約,看內部是否有重名的變數。編譯器在編譯時也會提出警告,所以注意編譯器的警告也是很重要的。

來自鏈屬性的弱隨機來源

在 Ethereum 的某些應用,使用隨機數來建立公平性。但是隨機數的建立在 Ethereum 上是很困難的,可能存在一些陷阱。

使用鏈的屬性,像是 block.number blockhash block.diffculty 來產生偽隨機數。問題在於礦工可以修改這些數值。
例如在某些博彩應用,有上百萬的彩池,利益足以讓礦工產出一個以上的區塊,然後選擇會贏得彩池的區塊。聽起來不容易辦到,但其實只要權益夠高,這是可以被辦到的。

要防止礦工操控隨機數,有幾種方法

  • 一個承諾的方案,像是 RANDAO 。由所有參與者共同管理的去中心化組織,來產生隨機數。
  • 來自預言機的外部來源
  • 用比特幣的區塊 hash , 或是更去中心化,挖礦更貴的網路。

未完待續…

參考

https://swcregistry.io/
https://github.com/KadenZipfel/smart-contract-attack-vectors
https://medium.com/better-programming/the-encyclopedia-of-smart-contract-attacks-vulnerabilities-dfc1129fdaac
https://solidity.readthedocs.io/en/latest/bugs.html
https://www.parity.io/a-postmortem-on-the-parity-multi-sig-library-self-destruct/


神隊友學長Andy , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:智能合約的漏洞與攻擊1/3-漏洞1
喜欢 (0)
[320208045@qq.com]
分享 (0)
andy
关于作者:
中年大叔,打拼 like young students.
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址