From: "Hanno Böck" <hanno@hboeck.de>
To: kernel-hardening@lists.openwall.com
Subject: Re: [kernel-hardening] 2015 kernel CVEs
Date: Tue, 19 Jan 2016 12:49:17 +0100 [thread overview]
Message-ID: <20160119124917.6058019b@pc1> (raw)
In-Reply-To: <20160119112812.GA10818@mwanda>
[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]
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.
> There was only one that might have come from a USB fuzzer.
> We probably should be testing those things better.
This is surprising to me. There was a talk at black hat amsterdam in
2014 about a project trying to do exactly this. They sounded like they
have dozends of crashers that just need to be sorted and reported
upstream. Here's the code [2] and the talk [3].
Maybe this project has stalled and needs someone to look at it?
[1]
https://www.coreinfrastructure.org/sites/cii/files/pages/files/2015-09-fuzzing-report.pdf
[2] https://github.com/schumilo/vUSBf
[3] https://www.youtube.com/watch?v=OAbzN8k6Am4
--
Hanno Böck
http://hboeck.de/
mail/jabber: hanno@hboeck.de
GPG: BBB51E42
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-01-19 11:49 UTC|newest]
Thread overview: 26+ 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:49 ` Hanno Böck [this message]
2016-01-19 15:49 ` Quentin Casasnovas
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 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 17:00 ` Josh Boyer
2016-01-19 17:51 ` Greg KH
2016-01-20 7:12 ` Marcus Meissner
2016-01-19 17:57 ` [kernel-hardening] " Theodore Ts'o
2016-01-19 18:00 ` [kernel-hardening] " Al Viro
2016-01-19 22:41 ` 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
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=20160119124917.6058019b@pc1 \
--to=hanno@hboeck.de \
--cc=kernel-hardening@lists.openwall.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).