linux-kernel - Re: [RFC] In-kernel fuzz testing for apps

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 for Android: free password hash cracker in your pocket

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

Message-ID: <564DECAB.6050602@gmail.com>
Date:	Thu, 19 Nov 2015 10:37:15 -0500
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	Andrey Utkin <andrey.od.utkin@...il.com>,
	linux-kernel@...r.kernel.org, Anton <anton@...apica.im>
Subject: Re: [RFC] In-kernel fuzz testing for apps

On 2015-11-18 18:39, Andrey Utkin wrote:
> Me and my friend have once talked about careful application development,
> which includes awareness about all possible error conditions.
> So we have collected ideas about making kernel (or, in some cases, libc)
> "hostile" to careless application, and we present it so that the idea
> doesn't get lost, and maybe even gets real if somebody wants some
> features from the list.
This is an excellent idea for security testing, however, see below for 
more thoughts.
>
> - (libc) crash instantly if memcpy detects regions overlapping;
I believe there are actually systems out there that do this, but they 
are ancient by now.
> - return EINTR as much as possible;
> - send/recv/etc. returns EAGAIN on non-blocking sockets as much as possible;
> - send/recv tend to result in short writes/reads, e.g. 1 byte at a time,
> to break assumption about sending/receiving some "not-so-big" thing at once;
These three are tricky to do from userspace, but the first two could be 
done with ptrace with some effort (not sure about the third).
> - let write return ENOSPC sometimes;
Ironically, this can be done without much effort using BTRFS (although 
that will hopefully change in the future).
> - scheduler behaves differently from common case (e.g. let it tend to
> stop a thread at some syscalls);
I don't see this one being very useful for any program that isn't 
running realtime or accessing hardware directly.
> - return allocation failures;
I'm pretty certain there is some library out there that you can preload 
to do this.
> - make OOM killer manic!
This isn't hard to do in a VM, either randomly adjust the memory 
balloon, or randomly enter the scan-code for Ctrl-Alt-SysRq-F on the 
console.
> - make clocks which are not monotonic to go backward frequently;
Same as above, but for different reasons.
> - pretend the time is 2038 year or later;
Same as above, also look up a program called 'datefudge'.
> - (arguable) close syscall returns non-zero first time, or randomly;
I'm actually genuinely curious about this one.  What real-world 
circumstances could cause close() to fail?
> - (arguable) special arch having NULL not all zero-bits. Actually I
> don't believe it is feasible to make a lot of modern software to run in
> such situation.
This one is a functional guarantee for almost anything that uses virtual 
memory.  In theory, it might be possible to get a lot of things working 
with NULL = 0xFFFFFFFF (or the equivalent on 64-bit arches), but I don't 
see that being particularly useful (anything that does anything with 
NULL other than check against it and use it as a dummy initializer is 
probably broken in other ways).


Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)