conmon fuzz target

[evverx]

I ran into containers/conmon#315 (comment) the other day and then I found https://ostif.org/wp-content/uploads/2022/06/CRI-O-audit-by-ada-logics-chainguard-ostif.pdf where scenarios like that were included in the threat model

... and
input from the container’s are also handled in Conmon. These are areas of potential attack
surface against Conmon.

and as far as I understand there should be a fuzz target:

We also developed a fuzzer for Conmon to analyse the logging and parsing routines in conmon/src/ctr_logging.c.

@DavidKorczynski I can't seem to find that fuzz target anywhere. Is there any chance you could point me in the right direction?

[DavidKorczynski]

This particular fuzz target was not uploaded to OSS-Fuzz (or anywhere else public) -- it was a bit non-timeless and a bit forced into the build system so we decided to leave it out.

The main target was write_to_logs and our intentions were to test write_journald and write_journald.

[DavidKorczynski]

Quite interesting with containers/conmon#315 (comment)

I'll try to dig out the fuzz target and see why we did not catch that.

[evverx]

it was a bit non-timeless and a bit forced into the build system so we decided to leave it out.

Got it. Thanks!

I'll try to dig out the fuzz target and see why we did not catch that.

My guess would be that it wasn't linked against libsystemd (where messages and their lengths are used by sd_journal_sendv).

[evverx]

FWIW as far as I understand conmon is being rewritten in Rust so I'm not sure whether it would make sense to resurrect that particular fuzz target long term. It would certainly help to test patches and make sure new regressions aren't introduced though.

[evverx]

My guess would be that it wasn't linked against libsystemd

Before I forget I think https://google.github.io/oss-fuzz/getting-started/new-project-guide/#static-and-dynamic-linking-of-libraries makes it unnecessarily hard to fuzz codebases with external dependencies like glib and libsystemd. Because of that I missed (and keep missing) quite a few bugs and have to run a bunch of fuzz targets outside of OSS-Fuzz. It would be great if it was possible to lift those restrictions on at least ClusterFuzzLite. As far as I can remember I already kind of complained about that (and it didn't work out at the time) but maybe it's time to try again.

Anyway I'd keep this issue open. Rust should eventually help to eliminate some bugs but it would still make sense to fuzz the parser to catch panics, stack overflows and stuff like that.