web-dev-qa-db-ja.com

CVE-2016-2324はリモートコード実行を許可しましたか？

この種類のコード があるとしましょう：

// In revision.c
char *path_name(const struct name_path *path, const char *name) // by design, name_path->len is a 32 bits int, but this doesn’t concern name
{
      const struct name_path *p;
      char *n, *m;
      int nlen = strlen(name); // the size is converted to a positive number (the correct size was allocated previously with an unsigned long). I got 705804100
      int len = nlen + 1;

      for (p = path; p; p = p->up) { //loop is skipped (except in another case fixed since 2.7.1)
          if (p->elem_len)
              len += p->elem_len + 1;
      }
      n = xmalloc(len); // if len is negative, it will also be converted to a negative 64 bits integer *(which explains it is normally trying to allocate serveral Pb of ram most of the time)* which will be read as positive after that. // but this isn’t the run case that is interesting here.
      m = n + len - (nlen + 1); // the size of m is lower than name
      strcpy(m, name); // strcpy rely on the null terminating character. The result is written in an unallocated memory from heap. This is the definition of heap overflow enabling server side remote code execution if name[] contains Assembly, and have the correct size. This open the way to defeat canaries aslr, and nx combined see http://security.stackexchange.com/q/20497/36301#comment182004_20550
      for (p = path; p; p = p->up) {
          if (p->elem_len) {
              m -= p->elem_len + 1;
              memcpy(m, p->elem, p->elem_len);
              m[p->elem_len] = '/';
          }
      }
      return n;
}

システムがリモートコード実行へのパスを完全に閉じたままオーバーフローを発生させる場合がありましたか？

Gitデータベースの細工されたパス（gitツリー）には、リモートコード実行を実行するためのバイナリコードが含まれている必要があります。ただし、パスにthe nulbyteを含めることはできません（gitツリーで区切り文字として使用されているため）。

特定のケース が必要な場合、それは bunt であり、 linux バージョン<3.16で、すべてのセキュリティ保護が有効になっています（ nx aslrとdepを組み合わせたものですが、カナリアは除きます）。アーキテクチャは x86_64 です。 libcは glibc の古い（ただしセキュリティパッチが適用された）バージョンです。

更新：

さて、証明を作成する もっと簡単なはずです 。

linuxccveaslrdep
5
user2284570

（「書き込み」種類の）バッファオーバーフローは、攻撃者がオーバーフローを調整して、他の何かに使用されるareである他のバイトをオーバーフローさせることができる場合にのみ、攻撃者に利点をもたらします。プロセスはいつでもアドレススペースで実行され、そのほとんどは未割り当てです。オーバーフローしたバッファがアドレス空間の最後にある場合、またはその後に未使用のバイトがあり、その後にマップされていないページが続く場合、オーバーフローは攻撃者を助けません。

SunOS 4.1.4（sparcシステム）のrloginコマンドラインツールのケースを覚えています。これはルートsuidであり、TERM環境変数に64文字を超える文字列が含まれていると、segfaultになる可能性があります。ただし、オーバーフローしたバッファはデータセクションの最後にあり、それ以外に上書きするものはありません。

ただし、そのmalloc()は、割り当てられた各ブロックの前後に追加のバイトを使用して、割り当てられているブロックを追跡する場合があります。 malloc()の実装によっては、これらのバイトを変更しても、攻撃者に役立つ場合とそうでない場合があります。要点は、一部のバッファオーバーフローを悪用することはできませんが、通常、バッファオーバーフローを悪用することは確認するのが非常に困難です。バッファオーバーフローは劇的な結果につながる可能性があり、まったく発生しないと想定する方が安全です。

7
Thomas Pornin

すべてのバッファオーバーフローがリモートコードの実行につながるわけではありません。これは、バッファの割り当て方法と、攻撃者が命令ポインタを制御できるかどうかによって異なります。リモートでコードが実行される可能性があるかどうかには、多くの要因があります。

1
RoraΖ

buntuが使用データ実行保護 。これにより、プロセスのデータ部分でメモリから実行されるコードが停止します。これにより、バッファオーバーフローを介して挿入されたコードを実行できなくなります。そのため、実行はできませんが、オーバーフローが発生する可能性があります。 [〜＃〜] rop [〜＃〜] などの手法を使用して、DEPを回避します。

0
Neil Smithline