| Message ID | 20210117230924.449676-4-alxndr@bu.edu (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fuzz: Add 9p generic-fuzz configs | expand |
On Montag, 18. Januar 2021 00:09:24 CET Alexander Bulekov wrote: > virtio-9p devices are often used to expose a virtual-filesystem to the > guest. There have been some bugs reported in this device, such as > CVE-2018-19364, and CVE-2021-20181. We should fuzz this device > > This patch adds two virtio-9p configurations: > * One with the widely used -fsdev local driver. This driver leaks some > state in the form of files/directories created in the shared dir. > * One with the synth driver. While it is not used in the real world, this > driver won't leak leak state between fuzz inputs. > > Signed-off-by: Alexander Bulekov <alxndr@bu.edu> > --- > CC: Christian Schoenebeck <qemu_oss@crudebyte.com> > CC: Greg Kurz <groug@kaod.org> > > I considered adding an atexit handler to remove the temp directory, > however I am worried that there might be some error that results in a > call to exit(), rather than abort(), which will cause problems for > future fork()-ed fuzzers. I don't think there are such calls in the 9p > code, however there might be something in the APIs used by 9p. As this > code is primarily for ephemeral OSS-Fuzz conainers, this shouldn't be > too much of an issue. Yes, dealing with signal handlers for that is probably a bit intransparent and would leave a questionable feeling about its reliability. What about __attribute__((destructor)) to auto delete the fuzzer directory, like virtio-9p-test.c does for the same task? > tests/qtest/fuzz/generic_fuzz_configs.h | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/tests/qtest/fuzz/generic_fuzz_configs.h > b/tests/qtest/fuzz/generic_fuzz_configs.h index 1a133655ee..f99657cdbc > 100644 > --- a/tests/qtest/fuzz/generic_fuzz_configs.h > +++ b/tests/qtest/fuzz/generic_fuzz_configs.h > @@ -19,6 +19,16 @@ typedef struct generic_fuzz_config { > gchar* (*argfunc)(void); /* Result must be freeable by g_free() */ > } generic_fuzz_config; > > +static inline gchar *generic_fuzzer_virtio_9p_args(void){ > + char tmpdir[] = "/tmp/qemu-fuzz.XXXXXX"; > + g_assert_nonnull(mkdtemp(tmpdir)); > + > + return g_strdup_printf("-machine q35 -nodefaults " > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " > + "-fsdev local,id=hshare,path=%s,security_model=mapped-xattr," > + "writeout=immediate,fmode=0600,dmode=0700", tmpdir); > +} > + > const generic_fuzz_config predefined_configs[] = { > { > .name = "virtio-net-pci-slirp", > @@ -60,6 +70,16 @@ const generic_fuzz_config predefined_configs[] = { > .name = "virtio-mouse", > .args = "-machine q35 -nodefaults -device virtio-mouse", > .objects = "virtio*", > + },{ > + .name = "virtio-9p", > + .argfunc = generic_fuzzer_virtio_9p_args, > + .objects = "virtio*", > + },{ > + .name = "virtio-9p-synth", > + .args = "-machine q35 -nodefaults " > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " > + "-fsdev synth,id=hshare", > + .objects = "virtio*", > },{ > .name = "e1000", > .args = "-M q35 -nodefaults "
On 210118 1334, Christian Schoenebeck wrote: > On Montag, 18. Januar 2021 00:09:24 CET Alexander Bulekov wrote: > > virtio-9p devices are often used to expose a virtual-filesystem to the > > guest. There have been some bugs reported in this device, such as > > CVE-2018-19364, and CVE-2021-20181. We should fuzz this device > > > > This patch adds two virtio-9p configurations: > > * One with the widely used -fsdev local driver. This driver leaks some > > state in the form of files/directories created in the shared dir. > > * One with the synth driver. While it is not used in the real world, this > > driver won't leak leak state between fuzz inputs. > > > > Signed-off-by: Alexander Bulekov <alxndr@bu.edu> > > --- > > CC: Christian Schoenebeck <qemu_oss@crudebyte.com> > > CC: Greg Kurz <groug@kaod.org> > > > > I considered adding an atexit handler to remove the temp directory, > > however I am worried that there might be some error that results in a > > call to exit(), rather than abort(), which will cause problems for > > future fork()-ed fuzzers. I don't think there are such calls in the 9p > > code, however there might be something in the APIs used by 9p. As this > > code is primarily for ephemeral OSS-Fuzz conainers, this shouldn't be > > too much of an issue. > > Yes, dealing with signal handlers for that is probably a bit intransparent and > would leave a questionable feeling about its reliability. > > What about __attribute__((destructor)) to auto delete the fuzzer directory, > like virtio-9p-test.c does for the same task? > My worry is that we will end up deleting it while it is still in use. The scenario I am worried about: [parent process ] set up temp directory for virtio-9p [parent process ] initialize QEMU [parent process ] fork() and wait() [child process 1] Run the fuzzing input. [child process 1] Once the input has been executed, call _Exit(). This should skip the atexit()/__attribute((destructor)) handlers. For reasons related to libfuzzer, we need to do this so that libfuzzer doesn't treat each child exit()-ing as a crash. [parent process ] wait() returns. [parent process ] generate a new input.. fork() and wait() [child process 2] Run the fuzzing input. [child process 2] Somewhere we hit an abort(). libfuzzer hooks the abort and dumps the crashing input and stack trace. Since abort() doesn't call exit handlers, it will skip over atexit()/__attribute((destructor)) handlers [parent process ] wait() returns. [parent process ] generate a new input.. fork() and wait() [child process 3] Run the fuzzing input. [child process 3] Somewhere we hit an exit(). This will dump the input/stacktrace and it will run the exit handlers (removing the shared 9p directory) [parent process ] wait() returns. generate a new input.. fork() and wait() [child process 4] ... Now all the subsequent forked children will refer to a shared directory that we already removed. Ideally, we would run the cleanup handler only after the parent process exit()s. I think there are some ways to do this, by placing the atexit() call in a place only reachable by the parent. However, on OSS-Fuzz this shouldn't be a problem as everything is cleaned up automatically anyway.. I am more worried about the fact that files/directories/links that are created by 9p in the child processes, persist across inputs. I think Thomas suggested a way to work-around this for PATCH 1/3. We could have a function that runs in the parent after each wait() returns, that would remove all the files in the temp directory and scrub the extended attributes applied by 9p to the shared dir. -Alex > > tests/qtest/fuzz/generic_fuzz_configs.h | 20 ++++++++++++++++++++ > > 1 file changed, 20 insertions(+) > > > > diff --git a/tests/qtest/fuzz/generic_fuzz_configs.h > > b/tests/qtest/fuzz/generic_fuzz_configs.h index 1a133655ee..f99657cdbc > > 100644 > > --- a/tests/qtest/fuzz/generic_fuzz_configs.h > > +++ b/tests/qtest/fuzz/generic_fuzz_configs.h > > @@ -19,6 +19,16 @@ typedef struct generic_fuzz_config { > > gchar* (*argfunc)(void); /* Result must be freeable by g_free() */ > > } generic_fuzz_config; > > > > +static inline gchar *generic_fuzzer_virtio_9p_args(void){ > > + char tmpdir[] = "/tmp/qemu-fuzz.XXXXXX"; > > + g_assert_nonnull(mkdtemp(tmpdir)); > > + > > + return g_strdup_printf("-machine q35 -nodefaults " > > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " > > + "-fsdev local,id=hshare,path=%s,security_model=mapped-xattr," > > + "writeout=immediate,fmode=0600,dmode=0700", tmpdir); > > +} > > + > > const generic_fuzz_config predefined_configs[] = { > > { > > .name = "virtio-net-pci-slirp", > > @@ -60,6 +70,16 @@ const generic_fuzz_config predefined_configs[] = { > > .name = "virtio-mouse", > > .args = "-machine q35 -nodefaults -device virtio-mouse", > > .objects = "virtio*", > > + },{ > > + .name = "virtio-9p", > > + .argfunc = generic_fuzzer_virtio_9p_args, > > + .objects = "virtio*", > > + },{ > > + .name = "virtio-9p-synth", > > + .args = "-machine q35 -nodefaults " > > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " > > + "-fsdev synth,id=hshare", > > + .objects = "virtio*", > > },{ > > .name = "e1000", > > .args = "-M q35 -nodefaults " > > >
On Sunday, 2021-01-17 at 18:09:24 -05, Alexander Bulekov wrote: > virtio-9p devices are often used to expose a virtual-filesystem to the > guest. There have been some bugs reported in this device, such as > CVE-2018-19364, and CVE-2021-20181. We should fuzz this device > > This patch adds two virtio-9p configurations: > * One with the widely used -fsdev local driver. This driver leaks some > state in the form of files/directories created in the shared dir. > * One with the synth driver. While it is not used in the real world, this > driver won't leak leak state between fuzz inputs. > > Signed-off-by: Alexander Bulekov <alxndr@bu.edu> > --- > CC: Christian Schoenebeck <qemu_oss@crudebyte.com> > CC: Greg Kurz <groug@kaod.org> > > I considered adding an atexit handler to remove the temp directory, > however I am worried that there might be some error that results in a > call to exit(), rather than abort(), which will cause problems for > future fork()-ed fuzzers. I don't think there are such calls in the 9p > code, however there might be something in the APIs used by 9p. As this > code is primarily for ephemeral OSS-Fuzz conainers, this shouldn't be > too much of an issue. As I understand it, this creation of a new directory should happen a lot less than the amount of actual executions of the target, since it is only run on the first 'parent' target process executed, prior to the process cloning operations that the fork execution performs - or any time that 'parent' target process is renewed, after several thousand cloned processes. Is that correct? Or am I misunderstanding when the generic_fuzzer_virtio_9p_args() function is run? Thanks, Darren. > tests/qtest/fuzz/generic_fuzz_configs.h | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/tests/qtest/fuzz/generic_fuzz_configs.h b/tests/qtest/fuzz/generic_fuzz_configs.h > index 1a133655ee..f99657cdbc 100644 > --- a/tests/qtest/fuzz/generic_fuzz_configs.h > +++ b/tests/qtest/fuzz/generic_fuzz_configs.h > @@ -19,6 +19,16 @@ typedef struct generic_fuzz_config { > gchar* (*argfunc)(void); /* Result must be freeable by g_free() */ > } generic_fuzz_config; > > +static inline gchar *generic_fuzzer_virtio_9p_args(void){ > + char tmpdir[] = "/tmp/qemu-fuzz.XXXXXX"; > + g_assert_nonnull(mkdtemp(tmpdir)); > + > + return g_strdup_printf("-machine q35 -nodefaults " > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " > + "-fsdev local,id=hshare,path=%s,security_model=mapped-xattr," > + "writeout=immediate,fmode=0600,dmode=0700", tmpdir); > +} > + > const generic_fuzz_config predefined_configs[] = { > { > .name = "virtio-net-pci-slirp", > @@ -60,6 +70,16 @@ const generic_fuzz_config predefined_configs[] = { > .name = "virtio-mouse", > .args = "-machine q35 -nodefaults -device virtio-mouse", > .objects = "virtio*", > + },{ > + .name = "virtio-9p", > + .argfunc = generic_fuzzer_virtio_9p_args, > + .objects = "virtio*", > + },{ > + .name = "virtio-9p-synth", > + .args = "-machine q35 -nodefaults " > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " > + "-fsdev synth,id=hshare", > + .objects = "virtio*", > },{ > .name = "e1000", > .args = "-M q35 -nodefaults " > -- > 2.28.0
On Monday, 2021-01-18 at 10:30:33 -05, Alexander Bulekov wrote: > On 210118 1334, Christian Schoenebeck wrote: >> On Montag, 18. Januar 2021 00:09:24 CET Alexander Bulekov wrote: >> > virtio-9p devices are often used to expose a virtual-filesystem to the >> > guest. There have been some bugs reported in this device, such as >> > CVE-2018-19364, and CVE-2021-20181. We should fuzz this device >> > >> > This patch adds two virtio-9p configurations: >> > * One with the widely used -fsdev local driver. This driver leaks some >> > state in the form of files/directories created in the shared dir. >> > * One with the synth driver. While it is not used in the real world, this >> > driver won't leak leak state between fuzz inputs. >> > >> > Signed-off-by: Alexander Bulekov <alxndr@bu.edu> >> > --- >> > CC: Christian Schoenebeck <qemu_oss@crudebyte.com> >> > CC: Greg Kurz <groug@kaod.org> >> > >> > I considered adding an atexit handler to remove the temp directory, >> > however I am worried that there might be some error that results in a >> > call to exit(), rather than abort(), which will cause problems for >> > future fork()-ed fuzzers. I don't think there are such calls in the 9p >> > code, however there might be something in the APIs used by 9p. As this >> > code is primarily for ephemeral OSS-Fuzz conainers, this shouldn't be >> > too much of an issue. >> >> Yes, dealing with signal handlers for that is probably a bit intransparent and >> would leave a questionable feeling about its reliability. >> >> What about __attribute__((destructor)) to auto delete the fuzzer directory, >> like virtio-9p-test.c does for the same task? >> > > My worry is that we will end up deleting it while it is still in use. > The scenario I am worried about: > [parent process ] set up temp directory for virtio-9p > [parent process ] initialize QEMU > [parent process ] fork() and wait() > [child process 1] Run the fuzzing input. > [child process 1] Once the input has been executed, call _Exit(). This > should skip the atexit()/__attribute((destructor)) handlers. For reasons > related to libfuzzer, we need to do this so that libfuzzer doesn't treat > each child exit()-ing as a crash. > [parent process ] wait() returns. > [parent process ] generate a new input.. fork() and wait() > [child process 2] Run the fuzzing input. > [child process 2] Somewhere we hit an abort(). libfuzzer hooks the abort > and dumps the crashing input and stack trace. Since abort() doesn't call > exit handlers, it will skip over atexit()/__attribute((destructor)) handlers > [parent process ] wait() returns. > [parent process ] generate a new input.. fork() and wait() > [child process 3] Run the fuzzing input. > [child process 3] Somewhere we hit an exit(). This will dump the > input/stacktrace and it will run the exit handlers (removing the shared > 9p directory) > [parent process ] wait() returns. generate a new input.. fork() and wait() > [child process 4] ... OK, that answer's my question :) > Now all the subsequent forked children will refer to a shared directory > that we already removed. Ideally, we would run the cleanup handler only > after the parent process exit()s. I think there are some ways to do > this, by placing the atexit() call in a place only reachable by the > parent. However, on OSS-Fuzz this shouldn't be a problem as everything > is cleaned up automatically anyway.. Yep, agreed. > I am more worried about the fact that files/directories/links that are > created by 9p in the child processes, persist across inputs. I think > Thomas suggested a way to work-around this for PATCH 1/3. We could have > a function that runs in the parent after each wait() returns, that would > remove all the files in the temp directory and scrub the extended > attributes applied by 9p to the shared dir. Hmm, that sounds like something to consider, but it may also end up slowing down the execution during the turn-around - guess it depends on how much noise is being generated. Thanks, Darren. > -Alex > > >> > tests/qtest/fuzz/generic_fuzz_configs.h | 20 ++++++++++++++++++++ >> > 1 file changed, 20 insertions(+) >> > >> > diff --git a/tests/qtest/fuzz/generic_fuzz_configs.h >> > b/tests/qtest/fuzz/generic_fuzz_configs.h index 1a133655ee..f99657cdbc >> > 100644 >> > --- a/tests/qtest/fuzz/generic_fuzz_configs.h >> > +++ b/tests/qtest/fuzz/generic_fuzz_configs.h >> > @@ -19,6 +19,16 @@ typedef struct generic_fuzz_config { >> > gchar* (*argfunc)(void); /* Result must be freeable by g_free() */ >> > } generic_fuzz_config; >> > >> > +static inline gchar *generic_fuzzer_virtio_9p_args(void){ >> > + char tmpdir[] = "/tmp/qemu-fuzz.XXXXXX"; >> > + g_assert_nonnull(mkdtemp(tmpdir)); >> > + >> > + return g_strdup_printf("-machine q35 -nodefaults " >> > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " >> > + "-fsdev local,id=hshare,path=%s,security_model=mapped-xattr," >> > + "writeout=immediate,fmode=0600,dmode=0700", tmpdir); >> > +} >> > + >> > const generic_fuzz_config predefined_configs[] = { >> > { >> > .name = "virtio-net-pci-slirp", >> > @@ -60,6 +70,16 @@ const generic_fuzz_config predefined_configs[] = { >> > .name = "virtio-mouse", >> > .args = "-machine q35 -nodefaults -device virtio-mouse", >> > .objects = "virtio*", >> > + },{ >> > + .name = "virtio-9p", >> > + .argfunc = generic_fuzzer_virtio_9p_args, >> > + .objects = "virtio*", >> > + },{ >> > + .name = "virtio-9p-synth", >> > + .args = "-machine q35 -nodefaults " >> > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " >> > + "-fsdev synth,id=hshare", >> > + .objects = "virtio*", >> > },{ >> > .name = "e1000", >> > .args = "-M q35 -nodefaults " >> >> >>
On 210118 1536, Darren Kenny wrote: > On Sunday, 2021-01-17 at 18:09:24 -05, Alexander Bulekov wrote: > > virtio-9p devices are often used to expose a virtual-filesystem to the > > guest. There have been some bugs reported in this device, such as > > CVE-2018-19364, and CVE-2021-20181. We should fuzz this device > > > > This patch adds two virtio-9p configurations: > > * One with the widely used -fsdev local driver. This driver leaks some > > state in the form of files/directories created in the shared dir. > > * One with the synth driver. While it is not used in the real world, this > > driver won't leak leak state between fuzz inputs. > > > > Signed-off-by: Alexander Bulekov <alxndr@bu.edu> > > --- > > CC: Christian Schoenebeck <qemu_oss@crudebyte.com> > > CC: Greg Kurz <groug@kaod.org> > > > > I considered adding an atexit handler to remove the temp directory, > > however I am worried that there might be some error that results in a > > call to exit(), rather than abort(), which will cause problems for > > future fork()-ed fuzzers. I don't think there are such calls in the 9p > > code, however there might be something in the APIs used by 9p. As this > > code is primarily for ephemeral OSS-Fuzz conainers, this shouldn't be > > too much of an issue. > > As I understand it, this creation of a new directory should happen a lot > less than the amount of actual executions of the target, since it is > only run on the first 'parent' target process executed, prior to the > process cloning operations that the fork execution performs - or any > time that 'parent' target process is renewed, after several thousand > cloned processes. > > Is that correct? Or am I misunderstanding when the > generic_fuzzer_virtio_9p_args() function is run? Correct. It happens once: before we initialize QEMU in the parent fuzzing process. There are two questions: 1. What is the best way to remove the directory after the parent process exits(and not after child processes exit())? 2. Should we do any cleanup on the temp directory between input executions. -Alex > > Thanks, > > Darren. > > > tests/qtest/fuzz/generic_fuzz_configs.h | 20 ++++++++++++++++++++ > > 1 file changed, 20 insertions(+) > > > > diff --git a/tests/qtest/fuzz/generic_fuzz_configs.h b/tests/qtest/fuzz/generic_fuzz_configs.h > > index 1a133655ee..f99657cdbc 100644 > > --- a/tests/qtest/fuzz/generic_fuzz_configs.h > > +++ b/tests/qtest/fuzz/generic_fuzz_configs.h > > @@ -19,6 +19,16 @@ typedef struct generic_fuzz_config { > > gchar* (*argfunc)(void); /* Result must be freeable by g_free() */ > > } generic_fuzz_config; > > > > +static inline gchar *generic_fuzzer_virtio_9p_args(void){ > > + char tmpdir[] = "/tmp/qemu-fuzz.XXXXXX"; > > + g_assert_nonnull(mkdtemp(tmpdir)); > > + > > + return g_strdup_printf("-machine q35 -nodefaults " > > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " > > + "-fsdev local,id=hshare,path=%s,security_model=mapped-xattr," > > + "writeout=immediate,fmode=0600,dmode=0700", tmpdir); > > +} > > + > > const generic_fuzz_config predefined_configs[] = { > > { > > .name = "virtio-net-pci-slirp", > > @@ -60,6 +70,16 @@ const generic_fuzz_config predefined_configs[] = { > > .name = "virtio-mouse", > > .args = "-machine q35 -nodefaults -device virtio-mouse", > > .objects = "virtio*", > > + },{ > > + .name = "virtio-9p", > > + .argfunc = generic_fuzzer_virtio_9p_args, > > + .objects = "virtio*", > > + },{ > > + .name = "virtio-9p-synth", > > + .args = "-machine q35 -nodefaults " > > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " > > + "-fsdev synth,id=hshare", > > + .objects = "virtio*", > > },{ > > .name = "e1000", > > .args = "-M q35 -nodefaults " > > -- > > 2.28.0
On 210118 1540, Darren Kenny wrote: > On Monday, 2021-01-18 at 10:30:33 -05, Alexander Bulekov wrote: > > On 210118 1334, Christian Schoenebeck wrote: > >> On Montag, 18. Januar 2021 00:09:24 CET Alexander Bulekov wrote: > >> > virtio-9p devices are often used to expose a virtual-filesystem to the > >> > guest. There have been some bugs reported in this device, such as > >> > CVE-2018-19364, and CVE-2021-20181. We should fuzz this device > >> > > >> > This patch adds two virtio-9p configurations: > >> > * One with the widely used -fsdev local driver. This driver leaks some > >> > state in the form of files/directories created in the shared dir. > >> > * One with the synth driver. While it is not used in the real world, this > >> > driver won't leak leak state between fuzz inputs. > >> > > >> > Signed-off-by: Alexander Bulekov <alxndr@bu.edu> > >> > --- > >> > CC: Christian Schoenebeck <qemu_oss@crudebyte.com> > >> > CC: Greg Kurz <groug@kaod.org> > >> > > >> > I considered adding an atexit handler to remove the temp directory, > >> > however I am worried that there might be some error that results in a > >> > call to exit(), rather than abort(), which will cause problems for > >> > future fork()-ed fuzzers. I don't think there are such calls in the 9p > >> > code, however there might be something in the APIs used by 9p. As this > >> > code is primarily for ephemeral OSS-Fuzz conainers, this shouldn't be > >> > too much of an issue. > >> > >> Yes, dealing with signal handlers for that is probably a bit intransparent and > >> would leave a questionable feeling about its reliability. > >> > >> What about __attribute__((destructor)) to auto delete the fuzzer directory, > >> like virtio-9p-test.c does for the same task? > >> > > > > My worry is that we will end up deleting it while it is still in use. > > The scenario I am worried about: > > [parent process ] set up temp directory for virtio-9p > > [parent process ] initialize QEMU > > [parent process ] fork() and wait() > > [child process 1] Run the fuzzing input. > > [child process 1] Once the input has been executed, call _Exit(). This > > should skip the atexit()/__attribute((destructor)) handlers. For reasons > > related to libfuzzer, we need to do this so that libfuzzer doesn't treat > > each child exit()-ing as a crash. > > [parent process ] wait() returns. > > [parent process ] generate a new input.. fork() and wait() > > [child process 2] Run the fuzzing input. > > [child process 2] Somewhere we hit an abort(). libfuzzer hooks the abort > > and dumps the crashing input and stack trace. Since abort() doesn't call > > exit handlers, it will skip over atexit()/__attribute((destructor)) handlers > > [parent process ] wait() returns. > > [parent process ] generate a new input.. fork() and wait() > > [child process 3] Run the fuzzing input. > > [child process 3] Somewhere we hit an exit(). This will dump the > > input/stacktrace and it will run the exit handlers (removing the shared > > 9p directory) > > [parent process ] wait() returns. generate a new input.. fork() and wait() > > [child process 4] ... > > OK, that answer's my question :) > > > Now all the subsequent forked children will refer to a shared directory > > that we already removed. Ideally, we would run the cleanup handler only > > after the parent process exit()s. I think there are some ways to do > > this, by placing the atexit() call in a place only reachable by the > > parent. However, on OSS-Fuzz this shouldn't be a problem as everything > > is cleaned up automatically anyway.. > > Yep, agreed. > > > I am more worried about the fact that files/directories/links that are > > created by 9p in the child processes, persist across inputs. I think > > Thomas suggested a way to work-around this for PATCH 1/3. We could have > > a function that runs in the parent after each wait() returns, that would > > remove all the files in the temp directory and scrub the extended > > attributes applied by 9p to the shared dir. > > Hmm, that sounds like something to consider, but it may also end up > slowing down the execution during the turn-around - guess it depends on > how much noise is being generated. > I've ben running the fuzzer for a couple days, and I haven't noticed any issues with unreproducible inputs (yet). Is this something we can add later, if it becomes a problem? -Alex > Thanks, > > Darren. > > > -Alex > > > > > >> > tests/qtest/fuzz/generic_fuzz_configs.h | 20 ++++++++++++++++++++ > >> > 1 file changed, 20 insertions(+) > >> > > >> > diff --git a/tests/qtest/fuzz/generic_fuzz_configs.h > >> > b/tests/qtest/fuzz/generic_fuzz_configs.h index 1a133655ee..f99657cdbc > >> > 100644 > >> > --- a/tests/qtest/fuzz/generic_fuzz_configs.h > >> > +++ b/tests/qtest/fuzz/generic_fuzz_configs.h > >> > @@ -19,6 +19,16 @@ typedef struct generic_fuzz_config { > >> > gchar* (*argfunc)(void); /* Result must be freeable by g_free() */ > >> > } generic_fuzz_config; > >> > > >> > +static inline gchar *generic_fuzzer_virtio_9p_args(void){ > >> > + char tmpdir[] = "/tmp/qemu-fuzz.XXXXXX"; > >> > + g_assert_nonnull(mkdtemp(tmpdir)); > >> > + > >> > + return g_strdup_printf("-machine q35 -nodefaults " > >> > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " > >> > + "-fsdev local,id=hshare,path=%s,security_model=mapped-xattr," > >> > + "writeout=immediate,fmode=0600,dmode=0700", tmpdir); > >> > +} > >> > + > >> > const generic_fuzz_config predefined_configs[] = { > >> > { > >> > .name = "virtio-net-pci-slirp", > >> > @@ -60,6 +70,16 @@ const generic_fuzz_config predefined_configs[] = { > >> > .name = "virtio-mouse", > >> > .args = "-machine q35 -nodefaults -device virtio-mouse", > >> > .objects = "virtio*", > >> > + },{ > >> > + .name = "virtio-9p", > >> > + .argfunc = generic_fuzzer_virtio_9p_args, > >> > + .objects = "virtio*", > >> > + },{ > >> > + .name = "virtio-9p-synth", > >> > + .args = "-machine q35 -nodefaults " > >> > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " > >> > + "-fsdev synth,id=hshare", > >> > + .objects = "virtio*", > >> > },{ > >> > .name = "e1000", > >> > .args = "-M q35 -nodefaults " > >> > >> > >>
On Tuesday, 2021-01-19 at 10:12:29 -05, Alexander Bulekov wrote: > On 210118 1540, Darren Kenny wrote: >> On Monday, 2021-01-18 at 10:30:33 -05, Alexander Bulekov wrote: >> > On 210118 1334, Christian Schoenebeck wrote: >> >> On Montag, 18. Januar 2021 00:09:24 CET Alexander Bulekov wrote: >> >> > virtio-9p devices are often used to expose a virtual-filesystem to the >> >> > guest. There have been some bugs reported in this device, such as >> >> > CVE-2018-19364, and CVE-2021-20181. We should fuzz this device >> >> > >> >> > This patch adds two virtio-9p configurations: >> >> > * One with the widely used -fsdev local driver. This driver leaks some >> >> > state in the form of files/directories created in the shared dir. >> >> > * One with the synth driver. While it is not used in the real world, this >> >> > driver won't leak leak state between fuzz inputs. >> >> > >> >> > Signed-off-by: Alexander Bulekov <alxndr@bu.edu> >> >> > --- >> >> > CC: Christian Schoenebeck <qemu_oss@crudebyte.com> >> >> > CC: Greg Kurz <groug@kaod.org> >> >> > >> >> > I considered adding an atexit handler to remove the temp directory, >> >> > however I am worried that there might be some error that results in a >> >> > call to exit(), rather than abort(), which will cause problems for >> >> > future fork()-ed fuzzers. I don't think there are such calls in the 9p >> >> > code, however there might be something in the APIs used by 9p. As this >> >> > code is primarily for ephemeral OSS-Fuzz conainers, this shouldn't be >> >> > too much of an issue. >> >> >> >> Yes, dealing with signal handlers for that is probably a bit intransparent and >> >> would leave a questionable feeling about its reliability. >> >> >> >> What about __attribute__((destructor)) to auto delete the fuzzer directory, >> >> like virtio-9p-test.c does for the same task? >> >> >> > >> > My worry is that we will end up deleting it while it is still in use. >> > The scenario I am worried about: >> > [parent process ] set up temp directory for virtio-9p >> > [parent process ] initialize QEMU >> > [parent process ] fork() and wait() >> > [child process 1] Run the fuzzing input. >> > [child process 1] Once the input has been executed, call _Exit(). This >> > should skip the atexit()/__attribute((destructor)) handlers. For reasons >> > related to libfuzzer, we need to do this so that libfuzzer doesn't treat >> > each child exit()-ing as a crash. >> > [parent process ] wait() returns. >> > [parent process ] generate a new input.. fork() and wait() >> > [child process 2] Run the fuzzing input. >> > [child process 2] Somewhere we hit an abort(). libfuzzer hooks the abort >> > and dumps the crashing input and stack trace. Since abort() doesn't call >> > exit handlers, it will skip over atexit()/__attribute((destructor)) handlers >> > [parent process ] wait() returns. >> > [parent process ] generate a new input.. fork() and wait() >> > [child process 3] Run the fuzzing input. >> > [child process 3] Somewhere we hit an exit(). This will dump the >> > input/stacktrace and it will run the exit handlers (removing the shared >> > 9p directory) >> > [parent process ] wait() returns. generate a new input.. fork() and wait() >> > [child process 4] ... >> >> OK, that answer's my question :) >> >> > Now all the subsequent forked children will refer to a shared directory >> > that we already removed. Ideally, we would run the cleanup handler only >> > after the parent process exit()s. I think there are some ways to do >> > this, by placing the atexit() call in a place only reachable by the >> > parent. However, on OSS-Fuzz this shouldn't be a problem as everything >> > is cleaned up automatically anyway.. >> >> Yep, agreed. >> >> > I am more worried about the fact that files/directories/links that are >> > created by 9p in the child processes, persist across inputs. I think >> > Thomas suggested a way to work-around this for PATCH 1/3. We could have >> > a function that runs in the parent after each wait() returns, that would >> > remove all the files in the temp directory and scrub the extended >> > attributes applied by 9p to the shared dir. >> >> Hmm, that sounds like something to consider, but it may also end up >> slowing down the execution during the turn-around - guess it depends on >> how much noise is being generated. >> > > I've ben running the fuzzer for a couple days, and I haven't noticed any > issues with unreproducible inputs (yet). Is this something we can add > later, if it becomes a problem? Sure, I'm good with that: Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Thanks, Darren. > -Alex > >> Thanks, >> >> Darren. >> >> > -Alex >> > >> > >> >> > tests/qtest/fuzz/generic_fuzz_configs.h | 20 ++++++++++++++++++++ >> >> > 1 file changed, 20 insertions(+) >> >> > >> >> > diff --git a/tests/qtest/fuzz/generic_fuzz_configs.h >> >> > b/tests/qtest/fuzz/generic_fuzz_configs.h index 1a133655ee..f99657cdbc >> >> > 100644 >> >> > --- a/tests/qtest/fuzz/generic_fuzz_configs.h >> >> > +++ b/tests/qtest/fuzz/generic_fuzz_configs.h >> >> > @@ -19,6 +19,16 @@ typedef struct generic_fuzz_config { >> >> > gchar* (*argfunc)(void); /* Result must be freeable by g_free() */ >> >> > } generic_fuzz_config; >> >> > >> >> > +static inline gchar *generic_fuzzer_virtio_9p_args(void){ >> >> > + char tmpdir[] = "/tmp/qemu-fuzz.XXXXXX"; >> >> > + g_assert_nonnull(mkdtemp(tmpdir)); >> >> > + >> >> > + return g_strdup_printf("-machine q35 -nodefaults " >> >> > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " >> >> > + "-fsdev local,id=hshare,path=%s,security_model=mapped-xattr," >> >> > + "writeout=immediate,fmode=0600,dmode=0700", tmpdir); >> >> > +} >> >> > + >> >> > const generic_fuzz_config predefined_configs[] = { >> >> > { >> >> > .name = "virtio-net-pci-slirp", >> >> > @@ -60,6 +70,16 @@ const generic_fuzz_config predefined_configs[] = { >> >> > .name = "virtio-mouse", >> >> > .args = "-machine q35 -nodefaults -device virtio-mouse", >> >> > .objects = "virtio*", >> >> > + },{ >> >> > + .name = "virtio-9p", >> >> > + .argfunc = generic_fuzzer_virtio_9p_args, >> >> > + .objects = "virtio*", >> >> > + },{ >> >> > + .name = "virtio-9p-synth", >> >> > + .args = "-machine q35 -nodefaults " >> >> > + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " >> >> > + "-fsdev synth,id=hshare", >> >> > + .objects = "virtio*", >> >> > },{ >> >> > .name = "e1000", >> >> > .args = "-M q35 -nodefaults " >> >> >> >> >> >>
On Dienstag, 19. Januar 2021 16:44:31 CET Darren Kenny wrote: > On Tuesday, 2021-01-19 at 10:12:29 -05, Alexander Bulekov wrote: > > On 210118 1540, Darren Kenny wrote: > >> On Monday, 2021-01-18 at 10:30:33 -05, Alexander Bulekov wrote: > >> > On 210118 1334, Christian Schoenebeck wrote: > >> >> On Montag, 18. Januar 2021 00:09:24 CET Alexander Bulekov wrote: > >> >> > virtio-9p devices are often used to expose a virtual-filesystem to > >> >> > the > >> >> > guest. There have been some bugs reported in this device, such as > >> >> > CVE-2018-19364, and CVE-2021-20181. We should fuzz this device > >> >> > > >> >> > This patch adds two virtio-9p configurations: > >> >> > * One with the widely used -fsdev local driver. This driver leaks > >> >> > some > >> >> > > >> >> > state in the form of files/directories created in the shared dir. > >> >> > > >> >> > * One with the synth driver. While it is not used in the real > >> >> > world, this > >> >> > > >> >> > driver won't leak leak state between fuzz inputs. > >> >> > > >> >> > Signed-off-by: Alexander Bulekov <alxndr@bu.edu> > >> >> > --- > >> >> > CC: Christian Schoenebeck <qemu_oss@crudebyte.com> > >> >> > CC: Greg Kurz <groug@kaod.org> > >> >> > > >> >> > I considered adding an atexit handler to remove the temp directory, > >> >> > however I am worried that there might be some error that results in > >> >> > a > >> >> > call to exit(), rather than abort(), which will cause problems for > >> >> > future fork()-ed fuzzers. I don't think there are such calls in the > >> >> > 9p > >> >> > code, however there might be something in the APIs used by 9p. As > >> >> > this > >> >> > code is primarily for ephemeral OSS-Fuzz conainers, this shouldn't > >> >> > be > >> >> > too much of an issue. > >> >> > >> >> Yes, dealing with signal handlers for that is probably a bit > >> >> intransparent and would leave a questionable feeling about its > >> >> reliability. > >> >> > >> >> What about __attribute__((destructor)) to auto delete the fuzzer > >> >> directory, > >> >> like virtio-9p-test.c does for the same task? > >> > > >> > My worry is that we will end up deleting it while it is still in use. > >> > The scenario I am worried about: > >> > [parent process ] set up temp directory for virtio-9p > >> > [parent process ] initialize QEMU > >> > [parent process ] fork() and wait() > >> > [child process 1] Run the fuzzing input. > >> > [child process 1] Once the input has been executed, call _Exit(). This > >> > should skip the atexit()/__attribute((destructor)) handlers. For > >> > reasons > >> > related to libfuzzer, we need to do this so that libfuzzer doesn't > >> > treat > >> > each child exit()-ing as a crash. > >> > [parent process ] wait() returns. > >> > [parent process ] generate a new input.. fork() and wait() > >> > [child process 2] Run the fuzzing input. > >> > [child process 2] Somewhere we hit an abort(). libfuzzer hooks the > >> > abort > >> > and dumps the crashing input and stack trace. Since abort() doesn't > >> > call > >> > exit handlers, it will skip over atexit()/__attribute((destructor)) > >> > handlers [parent process ] wait() returns. > >> > [parent process ] generate a new input.. fork() and wait() > >> > [child process 3] Run the fuzzing input. > >> > [child process 3] Somewhere we hit an exit(). This will dump the > >> > input/stacktrace and it will run the exit handlers (removing the shared > >> > 9p directory) > >> > [parent process ] wait() returns. generate a new input.. fork() and > >> > wait() > >> > [child process 4] ... > >> > >> OK, that answer's my question :) > >> > >> > Now all the subsequent forked children will refer to a shared directory > >> > that we already removed. Ideally, we would run the cleanup handler only > >> > after the parent process exit()s. I think there are some ways to do > >> > this, by placing the atexit() call in a place only reachable by the > >> > parent. However, on OSS-Fuzz this shouldn't be a problem as everything > >> > is cleaned up automatically anyway.. > >> > >> Yep, agreed. > >> > >> > I am more worried about the fact that files/directories/links that are > >> > created by 9p in the child processes, persist across inputs. I think > >> > Thomas suggested a way to work-around this for PATCH 1/3. We could have > >> > a function that runs in the parent after each wait() returns, that > >> > would > >> > remove all the files in the temp directory and scrub the extended > >> > attributes applied by 9p to the shared dir. > >> > >> Hmm, that sounds like something to consider, but it may also end up > >> slowing down the execution during the turn-around - guess it depends on > >> how much noise is being generated. > > > > I've ben running the fuzzer for a couple days, and I haven't noticed any > > issues with unreproducible inputs (yet). Is this something we can add > > later, if it becomes a problem? > > Sure, I'm good with that: > > Reviewed-by: Darren Kenny <darren.kenny@oracle.com> > > Thanks, > > Darren. Same with me: Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Best regards, Christian Schoenebeck
diff --git a/tests/qtest/fuzz/generic_fuzz_configs.h b/tests/qtest/fuzz/generic_fuzz_configs.h index 1a133655ee..f99657cdbc 100644 --- a/tests/qtest/fuzz/generic_fuzz_configs.h +++ b/tests/qtest/fuzz/generic_fuzz_configs.h @@ -19,6 +19,16 @@ typedef struct generic_fuzz_config { gchar* (*argfunc)(void); /* Result must be freeable by g_free() */ } generic_fuzz_config; +static inline gchar *generic_fuzzer_virtio_9p_args(void){ + char tmpdir[] = "/tmp/qemu-fuzz.XXXXXX"; + g_assert_nonnull(mkdtemp(tmpdir)); + + return g_strdup_printf("-machine q35 -nodefaults " + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " + "-fsdev local,id=hshare,path=%s,security_model=mapped-xattr," + "writeout=immediate,fmode=0600,dmode=0700", tmpdir); +} + const generic_fuzz_config predefined_configs[] = { { .name = "virtio-net-pci-slirp", @@ -60,6 +70,16 @@ const generic_fuzz_config predefined_configs[] = { .name = "virtio-mouse", .args = "-machine q35 -nodefaults -device virtio-mouse", .objects = "virtio*", + },{ + .name = "virtio-9p", + .argfunc = generic_fuzzer_virtio_9p_args, + .objects = "virtio*", + },{ + .name = "virtio-9p-synth", + .args = "-machine q35 -nodefaults " + "-device virtio-9p,fsdev=hshare,mount_tag=hshare " + "-fsdev synth,id=hshare", + .objects = "virtio*", },{ .name = "e1000", .args = "-M q35 -nodefaults "
virtio-9p devices are often used to expose a virtual-filesystem to the guest. There have been some bugs reported in this device, such as CVE-2018-19364, and CVE-2021-20181. We should fuzz this device This patch adds two virtio-9p configurations: * One with the widely used -fsdev local driver. This driver leaks some state in the form of files/directories created in the shared dir. * One with the synth driver. While it is not used in the real world, this driver won't leak leak state between fuzz inputs. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> --- CC: Christian Schoenebeck <qemu_oss@crudebyte.com> CC: Greg Kurz <groug@kaod.org> I considered adding an atexit handler to remove the temp directory, however I am worried that there might be some error that results in a call to exit(), rather than abort(), which will cause problems for future fork()-ed fuzzers. I don't think there are such calls in the 9p code, however there might be something in the APIs used by 9p. As this code is primarily for ephemeral OSS-Fuzz conainers, this shouldn't be too much of an issue. tests/qtest/fuzz/generic_fuzz_configs.h | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)