Stack Overflow (72997432, 73012922)

[Google-Autofuzz]

Hello YAML team,

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

To reproduce, we are attaching Dockerfiles which compile 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:

• 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:

=================================================================
==11==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc65f40ef8 (pc 0x0000004b7057 bp 0x7ffc65f41770 sp 0x7ffc65f40f00 T0)
    #0 0x4b7056 in __asan_memcpy (/fuzzing/yaml_fuzzer+0x4b7056)
    #1 0x7fd318ef049d in yaml_parser_save_simple_key /fuzzing/libyaml/src/scanner.c:1119:35
    #2 0x7fd318ee734f in yaml_parser_fetch_flow_collection_start /fuzzing/libyaml/src/scanner.c:1456:10
    #3 0x7fd318ee3257 in yaml_parser_fetch_more_tokens /fuzzing/libyaml/src/scanner.c:846:14
    #4 0x7fd318f06a86 in yaml_parser_parse_flow_sequence_entry /fuzzing/libyaml/src/parser.c:961:13
    #5 0x7fd318f0b4f1 in yaml_parser_load_sequence /fuzzing/libyaml/src/loader.c:355:10
    #6 0x7fd318f0b5cb in yaml_parser_load_sequence /fuzzing/libyaml/src/loader.c:361:22
[...]
    #251 0x7fd318f0b5cb in yaml_parser_load_sequence /fuzzing/libyaml/src/loader.c:361:22

SUMMARY: AddressSanitizer: stack-overflow (/fuzzing/yaml_fuzzer+0x4b7056) in __asan_memcpy
==11==ABORTING

And:

=================================================================
==11==ERROR: AddressSanitizer: stack-overflow on address 0x7ffe61b66f18 (pc 0x0000004b7057 bp 0x7ffe61b67790 sp 0x7ffe61b66f20 T0)
    #0 0x4b7056 in __asan_memcpy (/fuzzing/yaml_fuzzer+0x4b7056)
    #1 0x7fb88e1ad49d in yaml_parser_save_simple_key /fuzzing/libyaml/src/scanner.c:1119:35
    #2 0x7fb88e1a434f in yaml_parser_fetch_flow_collection_start /fuzzing/libyaml/src/scanner.c:1456:10
    #3 0x7fb88e1a0257 in yaml_parser_fetch_more_tokens /fuzzing/libyaml/src/scanner.c:846:14
    #4 0x7fb88e1c4e2e in yaml_parser_parse_flow_mapping_key /fuzzing/libyaml/src/parser.c:1112:13
    #5 0x7fb88e1c8f42 in yaml_parser_load_mapping /fuzzing/libyaml/src/loader.c:418:10
    #6 0x7fb88e1c902e in yaml_parser_load_mapping /fuzzing/libyaml/src/loader.c:424:20
[...]
    #251 0x7f718697402e in yaml_parser_load_mapping /fuzzing/libyaml/src/loader.c:424:20
SUMMARY: AddressSanitizer: stack-overflow (/fuzzing/yaml_fuzzer+0x4b7056) in __asan_memcpy
==11==ABORTING

Without some kind of depth limit (even if the default behavior is "unbounded"),
library users parsing untrusted YAML files need to use workarounds such as
preprocessors that will reject invalid payloads, use separate processes for
parsing to compartmentalize impact of a crash, or prevent them from parsing
non-trusted payloads at all.

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".

We are also pleased to inform you that your project is eligible for inclusion to
the OSS-Fuzz project, which can provide additional continuous fuzzing, and
encourage you to investigate integration options.

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

Google AutoFuzz Team
artifacts_72997432.zip
artifacts_73012922.zip

[perlpunk]

Thanks!
I was able to reproduce it and reduced it to the smallest possible input which is causing it.

I think it should be noted that only the Loader API is affected, because it uses recursion. The Event API seems to be ok.
That means, for example PyYAML and Perl's YAML::XS are not affected by this.

Personally I'm not yet familiar enough with C and stack overflows, so I'm not sure if this happens simply because the recursion is too deep, or the recursive functions accidentally use too much memory and could be improved.
I hope we find someone who can help explaining/fixing this.

[Google-Autofuzz]

Thanks for looking at this issue!

There's a discussion about a similar issue in a JSON parser here, which has some possible solutions (and discussion of drawbacks of them) for recursive based parsers: nlohmann/json#832

As discussed there, a value configurable by library users (ideally with a sane default) that limits how much recursion can occur (and includes an option to disable this limit for those who prefer the old behavior) seems to strike a nice balance between security and functionality.

[perlpunk]

Thanks! This was fixed by #127 and released in 0.2.3