[perl #129012] heap-buffer-overflow Perl_fbm_instr (util.c:974)

On Thu, 08 Sep 2016 01:44:09 -0700, davem wrote:
> On Tue, Sep 06, 2016 at 06:03:20PM -0700, Tony Cook via RT wrote:
> > I'm wondering where the boundaries are on what we consider a security
> > issue.
> >
> > In this case if bigend is beyond the end of the allocated block, and
> > that
> > happens to be unmapped memory, this might be used in a denial-of-
> > service
> > attack (crashing perl.)
> 
> Well until fairly recently (v5.17.4-76-g7016d6e) the regex engine
> wouldn't
> even work with mmapped strings (it assumed amongst other things that
> the
> string would always have a trailing \0). So there is unlikely to be
> much
> production code out there using patterns against mmapped strings.
> 
> Also, if you're passing mmapped strings to the regex engine, then
> you're
> likely to be searching for binary data, so are unlikely to be using a
> UTF-8 pattern against it.

In glibc, malloc() will allocate memory with mmap() instead of from a heap for large blocks so normal PVs can be memory mapped.  There's no need for strange magic from an application.

> Yes, there *could* in theory be circumstances where this would allow a
> DoS
> attack, but its fairly unlikely.
> 
> In principle *all* perl bugs are security issues, but it's a
> subjective
> judgement as to how exploitable a bug is. I don't think this one is
> very
> exploitable. I'm also a lot less worried about DoS than arbitrary
> code execution, for example.

I agree, I was just wondering where we place the boundary between "this is a security issue" and "this is not a security issue".

In any case, the fix is public, so I've made this ticket public.

The issue is fixed, so closing it too.

Tony

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=129012

• [perl #129012] heap-buffer-overflow Perl_fbm_instr (util.c:974) by Tony Cook via RT