Libwmf and Google's oss-fuzz

[bobfriesenhahn]

It is great to see libwmf coming back to life here, and maintained by the original developer!

Certainly libwmf has been exposed to some fuzz testing (I have seen bug reports due to it), but it does not appear to be formally a project enrolled in oss-fuzz, or even included as a subordinate library by any project participating in oss-fuzz.

The GraphicsMagick oss-fuzz build includes practically all libraries it can depend on in its oss-fuzz build, except for libwmf.

If I add libwmf into GraphicsMagick's oss-build, is there now a reasonable expectation that libwmf will not immediately crash and burn?

It would be good if libwmf can enroll itself in oss-fuzz as a project in order to test the library, and the various utilities. There is a learning curve, and it would be initially painful, but there would be considerably more confidence in the project after undergoing months of fuzz testing.

Thoughts?

Bob

[bobfriesenhahn]

GraphicsMagick oss-fuzz builds now include libwmf2. The configure options include --disable-heavy.

There is a bug in libwmf's configure.ac in that it is not consistently using LIBWMF_BUILDSTYLE to remove tests in order to support the 'light' build. In particular, the test for freetype errors out and declares "libwmf requires freetype2" if it does not have a freetype directory. There is also a search for a 'freetype-config' program. It appears that the whole block pertaining to freetype and zlib needs to be protected by 'if test $LIBWMF_BUILDSTYLE = heavy', which can be accomplished by moving an existing line up.

[caolanm]

I wanted to have someplace to integrate the various fixes that accumulated over the years. I don't intend any personal development of mine here. But it is someplace to merge any submitted fixes, especially any fixes lingering in distro specific packaging and get them into a release.

I'm familiar with ossfuzz and have an active set of LibreOffice related fuzzers there. Though there indeed isn't a libwmf one. I have no feel for how well libwmf might fare with a fuzzer. Running a local oss-fuzz image for a while is probably needed to see if it would have loads of issues or not.

wrt a build fix, I'm happy to merge any pr's that fix whatever needs to be fixed.

[bobfriesenhahn]

I appreciate you not wanting to do active development and also appreciate that this repository now exists so it can accept fixes submitted by others. We shall see how libwmf fares with oss-fuzz. Also, how GraphicsMagick's old WMF rendering code fares given that it was not developed with hostile input files in mind (but WMF hostility is somewhat muted since it should not produce numbers larger than 16 bits).

[bobfriesenhahn]

We should leave this issue open in order to collect any experience which is gained from the fuzz testing.

[bobfriesenhahn]

The oss-fuzz build now includes libwmf. Immediately, oss-fuzz found a heap overflow under WmfCombineRgn(). Debian/Ubuntu still deliver libwmf ("0.2-7"), and that is what I have been using. I assume that Debian/Ubuntu have added patches, which may or may not be in this official repository. Regardless, the heap overflow is reproducible in the Debian/Ubuntu version.

I will investigate.