Re: LAME oss-fuzz integration

Endpoints for websites/apps that ingest untrusted (but legal) user audio
(or video), and transcode/encode to MP3 using libmp3lame could suffer from
stability issues if the code contains bugs (and crashes or hangs for
certain inputs).
Youtube is an example of a website that consumes and processes untrusted
yet legal input (though I don't know if they use libmp3lame).

Another scenario is if LAME inadvertently embeds the values of variables or
buffers that are not initialized into its output. This could cause process
memory to end up in the output stream. This does not presuppose illicit use
of LAME. If such a bug exists, this could happen when a user encodes their
own audio over which they possess copyright. The fuzzer can and will detect
this. (A notable instance of this was OpenSSL Heartbleed).

I wouldn't worry about the 90 day deadline. If you cannot provide a fix
within 90 days, then so be it. Note that the oss-fuzz system will
automatically detect fixes for bugs, so you only need to push the fix to
the repository, and it will get picked up automatically in the next daily
fuzzer build. No other legwork is required.

My fuzzer can be found here: https://github.com/guidovranken/LAME-fuzzers
It is already running on oss-fuzz. You don't need to make any changes to
the LAME source code for it to work; it uses the libmp3lame API. Permission
is hereby granted to integrate my fuzzer into the LAME tree if you wish.

Please consider providing an e-mail address. If you don't, then I will have
to copy-paste information about a crash to your bug tracker each time a
crash is found. And I might have to stop the fuzzing effort as I don't
always have time for this.

To build the fuzzer locally you can do the following:
(Docker is required)

git clone https://github.com/google/oss-fuzz
cd oss-fuzz
python infra/helper.py build_fuzzers

The fuzzer binary ("fuzzer-encoder") can then be found in the out/
directory.

If oss-fuzz finds a crash, a crash file can be downloaded.
You can then replay the crash with the fuzzer binary in debug mode to
output proof-of-concept C code:

./fuzzer-encoder --debug <crash file>

I will file bug reports at the link you provided.

Guido

On Sat, Mar 23, 2019 at 5:38 PM Alexander Leidinger <[email protected]>
wrote:

> Quoting Guido Vranken <[email protected]> (from Tue, 19 Mar 2019
> 11:41:32 +0100):
>
> > Dear list,
> >
> > oss-fuzz is a Google initiative that performs continuous fuzz testing on
> > widely used open source software in pursuit of discovering software
> > vulnerabilities like buffer overflows.
> >
> > I've written a LAME fuzzer that I can request to be merged into oss-fuzz.
> >
> > Is the LAME development team interested in oss-fuzz integration?
>
> In general it is off course beneficial to have such support. It finds
> bugs, and we want to have bugs fixed.
>
> > Please see here what oss-fuzz expects from upstream developers:
> > https://github.com/google/oss-fuzz/blob/master/README.md
>
> I had a look at this when Google announced it. I do not expect that we
> can meet the requirements about responsiveness. "make public" latest
> after 90 days is implying that every issue found is interpreted as a
> security issue (which in general it may or may not be). Due to the
> fact that the LAME project always tells to use LAME on trusted input
> (we don't support music piracy) and as such every input to LAME is by
> definition not malicious and not a security issue (just a bug we off
> course want to fix). The perceptions differ here and the press will
> off course make headlines without looking if we also consider this as
> a security issues or not.
>
> > If you are keen, then for now I only need one or more developer e-mail
> > addresses that are linked to a Google account, and I will take care of
> the
> > integration.
>
> I think we should integrate the necessary code changes in the LAME
> source (best would be a patch in
> https://sourceforge.net/p/lame/patches/ and a little mail to this list
> to inform about it), but if nobody from the team stands up and tells
> that he is willing to tackle issues in-time, or at least monitor and
> act on it in an OKish timeframe, I don't think we can provide such an
> e-mail address.
>
> > On a related note, I've found a memory corruption bug with my fuzzer in
> the
> > LAME encoder. Do you prefer that I post bug details to this public list,
> or
> > should I report it to a specific address?
>
> Please file a bug report at https://sourceforge.net/p/lame/bugs/ or
> maybe if you even have a patch, then use
> https://sourceforge.net/p/lame/patches/ for it.
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net [email protected]: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.org    [email protected]  : PGP 0x8F31830F9F2772BF
>