From: Quentin Casasnovas <quentin.casasnovas@oracle.com>
To: kernel-hardening@lists.openwall.com
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Subject: Re: [kernel-hardening] 2015 kernel CVEs
Date: Tue, 19 Jan 2016 16:49:23 +0100 [thread overview]
Message-ID: <20160119154923.GA5130@chrystal.uk.oracle.com> (raw)
In-Reply-To: <20160119124917.6058019b@pc1>
On Tue, Jan 19, 2016 at 12:49:17PM +0100, Hanno Böck wrote:
> On Tue, 19 Jan 2016 14:28:12 +0300
> Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> > There was only a coupls CVEs that looks like they came from a
> > filesystem fuzzer where you create a corrupt filesystems and then try
> > use them.
>
> I tried that, but it didn't lead to any results in the kernel [1].
> What I did:
> * Use filesystem checking tools (fsck) and fuzz them with afl
> * Use the queue created by afl and try to mount these with a
> kasan-enabled kernel
>
> My conclusion was that the filesystem code in the kernel is relatively
> robust (at least robust enough for this trivial fuzzing).
> But it led to a number of bugs discovered in filesystem fsck tools.
>
As an experimental toy project, we've managed to implement the glue to have
AFL run on the kernel code, using either a patched afl-as wrapper or a
slightly modified GCC extension written by Dmitry Vyukov for syzkaller
(-fsanitize-coverage=trace-pc), and our conclusion is quite different.
In the month Vegard Nossum has been using it, he reported at least a dozen
problems at mount or readdir time:
btrfs:
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg48448.html
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg48976.html
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg49011.html
ext4:
http://marc.info/?l=linux-ext4&m=144898824424465&w=2
https://lkml.org/lkml/2015/12/13/187
hfs:
http://marc.info/?l=linux-fsdevel&m=144900215929323&w=2
isofs:
https://marc.info/?l=linux-kernel&m=144933509518680&w=2
udf:
https://lkml.org/lkml/2015/12/10/438
https://lkml.org/lkml/2015/12/11/526
vfat:
https://lkml.org/lkml/2015/11/13/782
https://lkml.org/lkml/2015/11/23/36
xfs:
https://marc.info/?l=linux-xfs&m=144904267207656&w=2
It should be noted that most of these problems were found relatively
quickly and without changing much the filesystem code, checksums weren't
disabled for example a part for superblock checksum in btrfs. And that was
mostly fuzzing the mount/readdir syscalls so a lot more can probably be
found there.
Thanks,
Quentin
next prev parent reply other threads:[~2016-01-19 15:49 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-19 11:28 [kernel-hardening] 2015 kernel CVEs Dan Carpenter
2016-01-19 11:28 ` Dan Carpenter
2016-01-19 11:49 ` [kernel-hardening] " Hanno Böck
2016-01-19 15:49 ` Quentin Casasnovas [this message]
2016-01-20 11:19 ` Hanno Böck
2016-01-20 14:15 ` Wade Mealing
2016-01-20 17:48 ` Hanno Böck
2016-01-19 13:13 ` Wade Mealing
2016-01-19 14:56 ` [kernel-hardening] " One Thousand Gnomes
2016-01-19 14:56 ` One Thousand Gnomes
2016-01-19 16:32 ` [kernel-hardening] " Ben Hutchings
2016-01-19 17:54 ` Greg KH
2016-01-20 17:05 ` Ben Hutchings
2016-01-20 18:04 ` Greg KH
2016-01-21 15:18 ` Jiri Kosina
2016-01-21 18:46 ` Ben Hutchings
2016-01-19 16:57 ` [kernel-hardening] " Peter Hurley
2016-01-19 16:57 ` Peter Hurley
2016-01-19 17:00 ` [kernel-hardening] " Josh Boyer
2016-01-19 17:00 ` Josh Boyer
2016-01-19 17:51 ` [kernel-hardening] " Greg KH
2016-01-19 17:51 ` Greg KH
2016-01-20 7:12 ` [kernel-hardening] " Marcus Meissner
2016-01-19 17:57 ` [kernel-hardening] " Theodore Ts'o
2016-01-19 18:00 ` [kernel-hardening] " Al Viro
2016-01-19 18:00 ` Al Viro
2016-01-19 22:41 ` [kernel-hardening] " Eric W. Biederman
2016-01-19 22:47 ` [kernel-hardening] " Eric W. Biederman
2016-01-20 20:11 ` Jann Horn
2016-01-20 21:26 ` One Thousand Gnomes
2016-01-19 23:35 ` Kees Cook
2016-01-20 9:57 ` [kernel-hardening] " Miroslav Benes
2016-01-20 9:57 ` Miroslav Benes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160119154923.GA5130@chrystal.uk.oracle.com \
--to=quentin.casasnovas@oracle.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=vegard.nossum@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.