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

Minidump susceptible to DOS #24

Open
pd-fkie opened this issue Sep 10, 2021 · 1 comment
Open

Minidump susceptible to DOS #24

pd-fkie opened this issue Sep 10, 2021 · 1 comment

Comments

@pd-fkie
Copy link

pd-fkie commented Sep 10, 2021

When minidump parses a module list it takes the number of modules directly from the input file:

mml.NumberOfModules = int.from_bytes(buff.read(4), byteorder = 'little', signed = False)

And afterwards it loops over the unconstrained number of modules and fills a list with MINIDUMP_MODULE objects:

for _ in range(mml.NumberOfModules):
    mml.Modules.append(MINIDUMP_MODULE.parse(buff))

This makes applications using minidump susceptible to DOS since a malicious minidump file could cause allocations of
4294967295 MINIDUMP_MODULE objects taking up a lot of memory on the host.

Would it be possible to limit the number of module objects to prevent the DOS?

This pattern where minidump takes a number of items directly from the input stream and loops over that
number can be found in a lot of other places too. MINIDUMP_MODULE_LIST is not the only class with this weakness.

An example file that lets minidump consume a lot of memory is the following:
oom-0b4dee5bb1227364f2bfc342047532c1212b05ae

@skelsec
Copy link
Owner

skelsec commented Sep 10, 2021

Hello, thank you for submitting this issue.
I don't think that this issue is worth mitigating. Reasons:

  1. (the political one) The specification of the minidump file format doesn't mention anything about imposing arbitrary limitations be that the amount of modules to be parsed or other.
  2. (the not so political one) Dealing with all the possible DoS issues in this library would easily take more effort than actually writing the library itself. I do not wish to put in that much time just to mitigate against a scenario that this library was never intended to be in (read: production code)
    I will leave this issue here in case someone would like to revisit this.

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

No branches or pull requests

2 participants