linux-kernel - Re: [PATCH] kconfig: Add kernel config option for fuzz testing.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191217155206.GA824812@mit.edu>
Date:   Tue, 17 Dec 2019 10:52:06 -0500
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Andi Kleen <ak@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Arnd Bergmann <arnd@...db.de>, Jiri Slaby <jslaby@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kconfig: Add kernel config option for fuzz testing.

On Tue, Dec 17, 2019 at 09:36:43AM +0100, Dmitry Vyukov wrote:
> Yes, what Tetsuo says. Only syscall numbers and top-level arguments to
> syscalls are easy to filter out. When indirect memory is passed to
> kernel or (fd,ioctl) pairs are involved it boils down to solving the
> halting problem.

I disagree that it's equivalent to solving the halting problem.
Otherwise, we couldn't filter in the kernel.  Let's think about ways
we can solve this.  One is to simply do what valgrind does; this
handles even self-modifying code, since you're essentially running an
x86-to-x86 emulator, and then you find an attempted trap to the
kernel, you can transfer control to a program which vets the arguments
to the system call.

Another approach might be to do this filtering in an BPF hook
installed at syscall entry.  Technically this is being done in the
kernel, but the advantage of this approach is that the BPF program can
be distributed alongside Syzkaller, and it can be Syzkaller-specific.
That way when we need to add a new blacklist entry, it can be done
without needing to wait for a kernel patch.

And note that there may *always* be some ioctls which we will need to
suppress.  For example, an attempt to send a SANITIZE ERASE to a
storage device; or an attempt to freeze the root file system, etc.
And I'm not sure all of these are ones that we can prevent by using
the lockdown setting.  There may very well be some commands that a
legitamate system administrator might want to execute that will, when
executed in the wrong circumstances causes the system to crash.  But
so long as it doesn't violate the trusted boot semantics which are the
whole point of lockdown, we would need to allow them.

So I suspect that some kind of filtering which is Syzkaller specific
is going to be inevitably needed, if you want to throw random binary
code and see what causes problem, and you insist on allowing these
random binary bits to be run as root.  Trying to prevent root from
being able to kill or self-DOS a machine goes way beyond any of our
current security mechanisms, and is something which is only really
needed by Fuzzers.  Personally, I suspect some kind of BPF filtering
is probably your best bet, since it will a bit more architecturally
portable than using some kind of Valgrind-like approach.  (Although
Valgrind *does* most of the architectures that I suspect we're going
to care about.)

						- Ted