Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash on malformed input #32

Closed
Shnatsel opened this issue Sep 7, 2018 · 4 comments
Closed

Crash on malformed input #32

Shnatsel opened this issue Sep 7, 2018 · 4 comments
Labels

Comments

@Shnatsel
Copy link
Contributor

Shnatsel commented Sep 7, 2018

When given a malformed input lewton attempts to allocate enormous amounts of memory and crashes. Testcase: minimized_crash_testcase.ogg.gz (gzipped so that github would accept the upload)

Command to reproduce the crash:
RUSTFLAGS='--cfg=fuzzing' cargo run --release --example perf /path/to/testcase
The output will be:

memory allocation of 4611686018427387908 bytes failed
fish: “env RUSTFLAGS='--cfg=fuzzing' c…” terminated by signal SIGABRT (Abort)

When run in debug mode with command
RUSTFLAGS='--cfg=fuzzing' cargo run --example perf /path/to/testcase the error message is:

thread 'main' panicked at 'attempt to subtract with overflow', src/audio.rs:639:18

Found using afl.rs

@est31
Copy link
Member

est31 commented Sep 8, 2018

Thanks for the next report!

Repacked version of the test case: 32_minimized_crash_testcase.ogg.zip

(needs no --cfg=fuzzing as the CRC sums are fixed)

@est31 est31 added the bug label Sep 8, 2018
@est31
Copy link
Member

est31 commented Sep 8, 2018

Note: I don't consider large allocations a bug. I mean how can you distinguish a legitimate large allocation from an illegitimate one? The problem is solvable far more nicely with failible allocators. Hopefully Rust will get support one day. Until then there has to be a panic.

However I do consider the overflow in debug more to be a bug. Thus I'll push a fix soon.

est31 added a commit that referenced this issue Sep 8, 2018
Badly formatted files managed to allocate giant buffers in release mode,
and trigger an subtraction overflow in debug mode.

While a large allocation doesn't imply a bug, the overflow certainly is
one.
@est31
Copy link
Member

est31 commented Sep 8, 2018

Fixed in commit b20e267

@est31 est31 closed this as completed Sep 8, 2018
@Shnatsel
Copy link
Contributor Author

Shnatsel commented Sep 8, 2018

I don't consider large allocations a bug. I mean how can you distinguish a legitimate large allocation from an illegitimate one?

This is usually done by limiting the amount of allocated memory to some sane default, and letting people override it if they're really dealing with enormous amounts of data. In Rust we can easily allow the API user to override these limits via the builder pattern.

See https://libpng.sourceforge.io/decompression_bombs.html for more info on how a similar issue was solved in libpng. See also the Limits struct from flif crate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants