Bugzilla Bug 205955

Will Drewry Tavis Ormandy from the Google Security Team discovered two Denial
of Service vulnerabilities in Boost Regex:

An assert fails in regex/v4/perl_matcher_non_recursive.hpp:376 (CVE-2008-0171):
  Error: Assertion `pstate->type == syntax_element_startmark' failed

NULL dereference in basic_regex_creator.hpp:1224 in function get_repeat_type()
(CVE-2008-0172):
  if (state->next.p->next.p->next.p == static_cast<re_alt*>(state)->alt.p)

The fixes are in the upstream SVN already, so this is SEMI-PUBLIC:
  http://svn.boost.org/trac/boost/changeset/42674
  http://svn.boost.org/trac/boost/changeset/42745

Please commit updated ebuilds to CVS and we'll handle stabilization here
privately until details of this bug are no longer under embargo.

Robert seems like this one could be opened now?

Do you know which version of boost are affected?
Because pulling stuff from trunk into 1.33.x most likely results in large
compile failures. But we should probably fix it in 1.34.1 anyway and get that
one stable...

This one is public now. CC'ing herd and unCC'ing maintainer.

I verified that our stable 1.33 is also affected by this. The patch seems to
apply, but it does not compile anymore.
If you want a backported fix, we could use the one from rpath -- otherwise,
just stable a patched 1.34.

Ok, will commit a fixed boost-1.34.1-r2 as soon as possible.

Ok, it might take a bit longer since the tests hang during the regex regression
tests and I have to figure out where the problem is (might as well be the
change I did for fixing some multi-threading problems).

er, actually rpath does this:
r.addPatch('http://svn.boost.org/trac/boost/changeset/42674?format=diff&new=42674')
r.addPatch('http://svn.boost.org/trac/boost/changeset/42745?format=diff&new=42745')

meaning... we apply patches directly from upstream

Oh, the second patch listed fixes the regex tests. That was mentioned on the
vendor-sec thread...

Ok, new ebuild committed as boost-1.34.1-r2 using the
boost-patches-1.34.1-2.tbz2 patchset tarball.

Arch-teams: I experienced endless loops in the test (namely a regex-test), so
keep an eye on it and please report if you see the same.

[...]
testing.capture-output
../bin.v2/libs/regex/test/regex_regress_dll.test/gcc-4.2/release/debug-symbols-none/optimization-none/threading-multi/regex_regress_dll.run

The testsuite should run through even if some tests fail in the middle. This is
just because there are more than 10'000 tests. A report-file is generated in
the end, please attach it to this bug, upload it somewhere or send it to me.
Thanks!

I would not think an infinite loop is acceptable. Does that occur with prior
versions?

The only prior version we have in the tree is boost-1.33.1 which is broken (in
more than one way) with the current stable gcc.

But as I tried to say: I'm running unstable and the chance is good that my
system exhibits a strange behaviour.

Sounds reasonable. Arches, please look at test results then.

Arches, please test and mark stable:
=dev-libs/boost-1.34.1-r2
Target keywords : "alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sh sparc x86"

The diff appears to misapply with sys-devel/patch-2.5.9 (current stable),
probably because it has DOS line-endings.  It results in a compilation error:

gcc.compile.c++
bin.v2/libs/regex/build/gcc-4.1/release/debug-symbols-none/link-static/optimization-none/runtime-link-static/fileiter.o
./boost/regex/v4/basic_regex_parser.hpp: In member function 'bool
boost::re_detail::basic_regex_parser<charT, traits>::parse_repeat(size_t,
size_t)':
./boost/regex/v4/basic_regex_parser.hpp:787: error: case label
'boost::re_detail::syntax_element_backstep' not within a switch statement
./boost/regex/v4/basic_regex_parser.hpp: At global scope:
./boost/regex/v4/basic_regex_parser.hpp:1885: error: expected constructor,
destructor, or type conversion before '=' token
./boost/regex/v4/basic_regex_parser.hpp:1886: error: expected constructor,
destructor, or type conversion before '=' token
./boost/regex/v4/basic_regex_parser.hpp:1887: error: expected unqualified-id
before 'if'

The faulty code after patching is:

      case syntax_element_startmark:
         // can't legally repeat any of the above:
         fail(regex_constants::error_badrepeat, m_position - m_base);
         return false;
      default:
         // do nothing...
         break;
      }
      case syntax_element_backstep:
^M
      insert_point = this->getoffset(this->m_last_state);

where the ^M is a carriage return. 

Thanks. Fixed by bumping the tarball. Please wait a couple of hours until the
updated ebuild and the tarball appear on the mirrors.

x86 stable

alpha/ia64/sparc stable

ppc64 stable

Stable for HPPA.

ppc stable

*** Bug 207385 has been marked as a duplicate of this bug. ***

amd64 stable

GLSA 200802-08

Fixed in release snapshot.