4

私の理解では、典型的なバッファ オーバーフロー攻撃は、攻撃によってスタック上のメモリ バッファがオーバーフローしたときに発生するため、攻撃者は悪意のあるコードを挿入し、そのコードを指すようにスタック上のリターン アドレスを書き換えることができます。

sscanfこれは、ある領域から別の領域にデータをやみくもにコピーし、終了バイトをチェックする関数 ( など) を使用する場合によくある問題です。

char str[8];                               /* holds up to 8 bytes of data */
char *buf = "lots and lots of foobars";    /* way more than 8 bytes of data */
sscanf(buf, "%s", str);                    /* buffer overflow occurs here! */

sysfs_ops storeLinux カーネルの一部の関数が、Linux カーネルのsscanf関数のバージョンで実装されていることに気付きました。

static char str[8];    /* global string */
static ssize_t my_store(struct device *dev,
                        struct device_attribute *attr,
                        const char *buf, size_t size)
{
        sscanf(buf, "%s", str);    /* buf holds more than 8 bytes! */
        return size;
}

このstoreコールバック関数が書き込み可能なsysfs属性に設定されているとします。write悪意のあるユーザーは、呼び出しを介して意図的にバッファをオーバーフローさせることができますか?

通常、読み取りバイト数の制限など、バッファー オーバーフロー攻撃に対するガードを期待しますが、かなりの数の関数 (たとえば、drivers/scsi/scsi_sysfs.c ) には何もありません。

Linux カーネル バージョンの実装は、sscanfバッファ オーバーフロー攻撃から保護しますか? それとも別の理由がありますか? Linux カーネルが内部でどのように動作するかを考えると、おそらくバッファー オーバーフロー攻撃は不可能なのでしょうか?

4

1 に答える 1

3

Linuxsscanf()はバッファ オーバーフローに対して脆弱です。ソースの検査はこれを示しています。幅指定子を使用して、 a が書き込むことができる量を制限でき%sます。ある時点で、あなたもそれを実行したにstr違いありません。ユーザー空間がガベージ ポインターをカーネルに渡すcopy_from_user()可能性があります。

引用したLinuxのバージョンでは、scsi_sysfs.cにバッファオーバーフローがあります。最新バージョンはそうではありません。コミットされた修正により、表示されている問題が修正されるはずです。

于 2013-05-02T00:50:19.520 に答える