Closed3

ソフトウェアデザイン2月号「cURLの脆弱性〜ヒープバッファオーバーフロー〜」を読む

yukiyuki

読んでるのでせっかくだからメモ。

https://www.amazon.co.jp/ソフトウェアデザイン-2021年2月号-伊奈-林太郎/dp/B08QS68VZS/ref=sr_1_2?dchild=1&qid=1611058880&s=books&sr=1-2

Rust に関する書籍を書いた際に、Rust の所有権やライフタイムは実はセキュリティの向上に最終的には貢献している、みたいな話を書いた。それ以来、セキュリティや脆弱性について深く知りたくなった。

今回 cURL の脆弱性に関する記事が掲載されているとのことを知り、買ってみた。ちなみに cURL は今 Rust をバックエンドに導入しようとしている。こうした脆弱性を Rust は未然にある程度防げるから。

https://www.infoq.com/news/2020/10/memory-safe-curl-rust/

yukiyuki

読んでみた結果

  • 今までの curl の実装では、ユーザーが --tftp-blksize で指定した値が blksize として設定されていた。これはデータの送受信を何バイトずつ行うかを指定するもの。
  • この指定内容が 512 バイトを下回る場合に問題があった。
    • リクエストを送信した結果、サーバーから送信される OACK に blksize が含まれて返ってきた場合
      • とくに問題なく100バイトなら100バイトでデータを送受信できた。
    • リクエストを送信した結果、サーバーから送信される OACK に blksize が含まれず返ってきた場合
      • ここが問題で、強制的にデータの送受信が 512 バイトになってしまった。
      • 100バイトしか指定していなかった場合、残りの 412 バイトが要するに余る状態になる。
      • ここにヒープバッファオーバーフロー攻撃できる要素があった。
    • 現在の実装では、blksize がなかった場合(or デフォルトのサイズ 512 バイトを下回る場合)は常に 512 バイトを使用するようにしてある。
      • 「お作法的に良いかはさておき」(で、それ以上何も書いてない)🤔
      • ついでに OACK がサーバーから返ってこなかった場合も想定できるように修正された。
このスクラップは2021/01/21にクローズされました