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.
