----- Original Message -----
> > [...]
> > 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.
> >
> > This tackles SGI BZ 1062.
>
> - 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.
The use cases are very different. mmvdump.c attempts to keep going and
to report as much of the mapping as it possibly can (a debugging aid),
whereas pmdammv silently discards mappings at the first sign of trouble.
I agree with the original authors thoughts on this one - implementation
is sufficiently simple as to not bother obfuscating the pmdammv code in
this way, so I don't intend to either.
> - 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.
That's well beyond the scope of the bug fix here - interesting project to
undertake though, so feel free to hack on it. pmlogcheck may also benefit
from such approaches FWLIW.
> - 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.
Seems a bit of a stretch to me (esp. considering setup of MMV mappings
dir is opt-in so unprivileged local programs cannot write by default &
then it depends on which permissions scheme is chosen by local admin).
So, not seeing it as a real issue (relative to the same sorts of attack
being applied to say pmcd itself) - perhaps produce a test case showing
this scenario in practice & I might be convinced. Something as simple
as a max# of MMV files would suffice (ala pmcd max# of connections), if
anyone's genuinely concerned about this though.
cheers.
--
Nathan
|