[RFC] In-kernel fuzz testing for apps

[RFC] In-kernel fuzz testing for apps

[Andrey Utkin]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

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.

- (libc) crash instantly if memcpy detects regions overlapping;
- 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;
- let write return ENOSPC sometimes;
- scheduler behaves differently from common case (e.g. let it tend to
stop a thread at some syscalls);
- return allocation failures;
- make OOM killer manic!
- make clocks which are not monotonic to go backward frequently;
- pretend the time is 2038 year or later;
- (arguable) close syscall returns non-zero first time, or randomly;
- (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.

These horrific modes should be enabled per-process or per-executable-file.

Thanks for your time and for any kind comment.

-- 
OpenPGP usage is appreciated (it also helps your letter to bypass spam
filters). To email me with encryption easily, go
https://encrypt.to/0xC6FCDB11


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]

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).


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

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

[Laura Abbott]

On 11/18/2015 03:39 PM, 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.
>
> - (libc) crash instantly if memcpy detects regions overlapping;
> - 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;
> - let write return ENOSPC sometimes;
> - scheduler behaves differently from common case (e.g. let it tend to
> stop a thread at some syscalls);
> - return allocation failures;
> - make OOM killer manic!
> - make clocks which are not monotonic to go backward frequently;
> - pretend the time is 2038 year or later;
> - (arguable) close syscall returns non-zero first time, or randomly;
> - (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.
>
> These horrific modes should be enabled per-process or per-executable-file.
>
> Thanks for your time and for any kind comment.
>

Check out CONFIG_FAULT_INJECTION, lib/fault_inject.c . There are a few things
there already. You could expand on that for other functionality.

Thanks,
Laura

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

[Pavel Machek]

Hi!

> 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.
> 
> - (libc) crash instantly if memcpy detects regions overlapping;
> - 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;
> - let write return ENOSPC sometimes;
> - scheduler behaves differently from common case (e.g. let it tend to
> stop a thread at some syscalls);
> - return allocation failures;
> - make OOM killer manic!
> - make clocks which are not monotonic to go backward frequently;
> - pretend the time is 2038 year or later;
> - (arguable) close syscall returns non-zero first time, or randomly;
> - (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.

Most of these should be doable with ptrace. You could use for example
subterfugue as a base.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html