Memory leak (71768558)

[Google-Autofuzz]

Hello YAML team,

As part of our fuzzing efforts at Google, we have identified an issue affecting
YAML (tested with revision * master d050fe3).

To reproduce, we are attaching a Dockerfile which compiles the project with
LLVM, taking advantage of the sanitizers that it offers. More information about
how to use the attached Dockerfile can be found here:
https://docs.docker.com/engine/reference/builder/

TL;DR instructions:
artifacts_71768558.zip

• mkdir project
• cp Dockerfile.YAML /path/to/project/Dockerfile
• docker build --no-cache /path/to/project
• docker run -it image_id_from_docker_build

From another terminal, outside the container:
docker cp /path/to/attached/reproducer running_container_hostname:/fuzzing/reproducer
(reference: https://docs.docker.com/engine/reference/commandline/cp/)

And, back inside the container:
/fuzzing/repro.sh /fuzzing/reproducer

Alternatively, and depending on the bug, you could use gcc, valgrind or other
instrumentation tools to aid in the investigation. The sanitizer error that we
encountered is here:

INFO: Seed: 1568918539
/fuzzing/yaml_fuzzer: Running 1 inputs 1 time(s) each.
Running: /tmp/poc
Executed /tmp/poc in 2 ms

=================================================================
==11==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x4ce128 in __interceptor_malloc (/fuzzing/yaml_fuzzer+0x4ce128)
    #1 0x7f1a9c500c89 in yaml_parser_scan_plain_scalar /fuzzing/libyaml/src/scanner.c:3400:10
    #2 0x7f1a9c4eddf8 in yaml_parser_fetch_plain_scalar /fuzzing/libyaml/src/scanner.c:1903:10
    #3 0x7f1a9c4e7257 in yaml_parser_fetch_more_tokens /fuzzing/libyaml/src/scanner.c:846:14
    #4 0x7f1a9c507193 in yaml_parser_parse_node /fuzzing/libyaml/src/parser.c:582:21
    #5 0x7f1a9c50a767 in yaml_parser_parse_block_mapping_value /fuzzing/libyaml/src/parser.c:919:20
    #6 0x50dd01 in emitter_main /fuzzing/security-research-pocs/autofuzz/yaml_fuzzer.cc:2634:18
    #7 0x50e858 in LLVMFuzzerTestOneInput /fuzzing/security-research-pocs/autofuzz/yaml_fuzzer.cc:2814:13
    #8 0x51544c in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/fuzzing/yaml_fuzzer+0x51544c)
    #9 0x50e91c in main (/fuzzing/yaml_fuzzer+0x50e91c)

SUMMARY: AddressSanitizer: 16 byte(s) leaked in 1 allocation(s).

We will gladly work with you so you can successfully confirm and reproduce this
issue. Do let us know if you have any feedback surrounding the documentation.

Once you have reproduced the issue, we'd appreciate to learn your expected
timeline for an update to be released. With any fix, please attribute the report
to "Google Autofuzz project".

Don't hesitate to let us know if you have any questions!

Google AutoFuzz Team

[ingydotnet]

Thank you for your report. I was able to run your reproduction strategy and get the leak report.

We will look into fixing this bug.

You should note that there is a bug in your repro code. You reported the bug against commit d050fe3 but the reproduction uses 01f3a87 (HEAD).

Is there a public repository where we can report issues about the autofuzzing project. There are a few things I'd like to report.

[ingydotnet]

@Google-Autofuzz I appreciate your work, but I find your reproduction methodology to be unnecessarily complicated. I took the liberty of streamlining some things so that it is simple and exact to reproduce. Here is how I would have reported this strategy:

---

You can reproduce our findings by running the following commands in a terminal:

wget https://github.com/yaml/libyaml/files/1794405/autofuzz-libyaml-111.zip
unzip autofuzz-libyaml-111.zip
cd autofuzz-libyaml-111
docker build --tag=autofuzz-libyaml-111 .
docker run -t autofuzz-libyaml-111

To run this interactively, use:

docker run -it autofuzz-libyaml-111 bash

Then run this command in the container:

./repro.sh ./reproducer

---

Take a look at that zip file. The changes I made are:

• Put the files in a wrapper directory
• Added 4 commands to the end of your Dockerfile
• Added a symlink to your reproducer file
• Added a ReadMe file

Here is the benefit:

• The reproduction commands are exact. You can literally cut/paste all the commands into a terminal at once, and they will run exactly. Try it!
• It is common courtesy to zip or tar a single directory, rather than a bunch of files. But in addition, now the user doesn't need to do your mkdir step. They just unzip and the build directory is there.
• No reason to copy over the reproducer file in a separate step and in a separate terminal session. This makes people think your setup is going to be a pain in the butt, when it's really not. The file is copied over in the build step. All the user needs to do is a docker build ... and a docker run.
• I found this line to be a doozy:

  docker cp /path/to/attached/reproducer running_container_hostname:/fuzzing/reproducer
  

  You give the user all these fake paths that are probably obvious to you, but totally confusing to the user. WTH is /path/to/attached/reproducer?? I had to guess that it was poc-9b6dc82a78647c1c2c906f1d29f81ac93777df493f5f6dee87aa16b045bb37ed_min
  Now the commands and paths are all exact and literal. No guessing as to what you are trying to say.

I hope this helps you come up with a better way to report your bugs. If you are interested, I have more ideas on how to polish this process. For now I just concentrated on a clean end-user experience.