-
Notifications
You must be signed in to change notification settings - Fork 276
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
wild-addr-write found by fuzz #215
Comments
#214 a way to fix |
How can this be triggered? |
i just run fuzzer_encoder(build by oss-fuzz) locally, here is my crash-corpus |
by the way, ARCHITECTURE is i386 |
How it is triggered is important for many reasons, not just debugging. It helps us understand if this can legitimately be triggered by a user and if so, represents a security risk. |
Yeah, you can run |
This is only triggered by submitting a specially crafted input to the encoder . It would be a far bigger issue if this was in the decoder. |
[Erik de Castro Lopo]
This is only triggered by submitting a specially crafted input to the
*encoder* . It would be a far bigger issue if this was in the decoder.
Absolutely. But given these web streaming days, even encoding might
provide an avenue into the system. :)
…--
Happy hacking
Petter Reinholdtsen
|
Is there potential for more than a crash / denial of service? |
@ltx2018 I've tried to reproduce this, but I seem to be bumping into this problem with clang/LLVM, which prevents me from building fuzzer_encoder on a 32-bit system. Anyway, I have a hunch about what might be triggering the problem. Would you mind checking whether PR #252 solves this problem? I know #214 should already fix the problem, but I think #252 might be fixing the root cause. Please let me know. |
This is fixed with the merge of #419 |
FYI, this flaw is being tracked by CVE-2020-22219. |
I think the analysis of CVE-2020-22219 is wrong. The vulnerability described in CVE-2020-22219 is in libFLAC. However, this vulnerability is only exploitable when the program calling the library does not fulfill a key requirement of the library API: the calling program has to supply values that are out-of-bounds. This requirement is mentioned here, here and here. This means that there is no way to exploit the vulnerability through the flac command line tool that is provided by the project: it does not violate this requirement, it only supplies values that are within bounds. So, the vulnerability is only exploitable with a program calling libFLAC that is does not properly check whether inputs are bounded or not. That seems a pretty important omission in the current analysis. |
On second thought, there is another way to exploit this, but that is very unreliable: when running out of memory. As FLAC uses only a tiny amount of memory and the failing realloc only allocates a small amount of memory, this is probably hard to turn into an exploit. In short, this buffer overflow only happens after an unhandled memory allocation failure. |
Doesn't the attacker control how much memory will the encoder need? With flac it causes a double free, but I guess other applications might do something with the encoder after the reallocation failed. |
No, the encoding parameters bound how much memory is used, so an attacker cannot let libFLAC use an arbitrary amount of memory, except when the program allows for supplying invalid data. The problem here was that invalid input made the encoder go beyond those bounds. That is why #273 adds an explicit check that input is valid, #252 added a limit to the bitwriter size (which was increased in #378) and #419 fixed handling of the allocation failure. |
we found wild-addr-write by fuzzing flac-master:
here is my debug info:
bw->buffer was realloc here
later, bw->buffer was freed but it's value NOT set to 0
The text was updated successfully, but these errors were encountered: