Gnumeric and PCRE

As some of you might have noticed, at least one distribution has
issued a security
fix to Gnumeric based on a bug in the PCRE library that Gnumeric includes.

Short version: I do not think the bug is exploitable via Gnumeric.

Long version: the PCRE library is a library that can be used to match strings
against patterns expressed as so-called regular expressions.  Evidently,
PCRE has a bug that means that a carefully constructed pattern can be used
to take control of the machine.

For Gnumeric to be vulnerable based on this, it would have to be possible to
construct a data file in a format understood by Gnumeric that would cause this
carefully constructed pattern to make it to Gnumeric's embedded copy of

As far as I can tell, that is not possible.  There are two potential routes: via
spreadsheet-level functions that handle patterns and via cell formats which
are used to construct regular expressions matching allowed strings.  In either
case, the generated regular expressions are quite simple and not of the class
for which PCRE has problems.

Unless, of course, Gnumeric has a bug in that code.  Regular expressions in
the flavour used by PCRE can be quite complicated, so it is not inconceivable
that we handle something wrong.  As a precaution I will therefore release a
new version of GOffice (where the PCRE copy lives these days) in the next
few days.

It has been suggested that we use the system-supplied PCRE instead of having
our on copy.  It is a nice idea, but at least on SuSE (version 9.3 checked) that
is a non-starter as the system PCRE is severely lobotomized.  Specifically, the
UTF-8 support is missing.

Morten Welinder

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]