nathans wrote:
> [...]
> Numerous updates to pmdammv to make sure it cannot be coerced
> into accessing memory outside of the memory mapped files that
> it loads. In addition, sensible (but still large) limits are
> placed on the data structures that are allocated to hold data
> representing various parts of the mappings.
>
> The mmvdump utility is updated in a similar way to improve its
> resilience in the presence of bad mappings. It also has some
> slight output refinements (symbolic flag printing, etc).
>
> This tackles SGI BZ 1062.
Thank you for starting work on this old problem. There are some nice
improvements there. Some more suggestions:
- Consider reworking the mmvdump program to rely on pmda_mmv.so to do
the parsing of the mmv shmem region, instead of partly duplicating
the code. That way one gets a single implementation.
- Consider engaging a real fuzzer like afl against pmdammv. This could
work especially effectively if mmvdump links to pmda_mmv.so, so they
could be easily recompiled/run together under afl control.
- The new implementation is still susceptible to a malevolent
unprivileged local programs DoS'ing pmdammv by junk files and/or
rapidly-cycling hdr.g1!=g2 numbers. The core code should consider
backing off suspected problematic slist[] entries in
mmv_reload_maybe.
- FChE
|