Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 205955 (CVE-2008-0171) - dev-libs/boost < 1.34.1-r2 Two DoS vulnerabilities (CVE-2008-{0171,0172})
Summary: dev-libs/boost < 1.34.1-r2 Two DoS vulnerabilities (CVE-2008-{0171,0172})
Alias: CVE-2008-0171
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
Whiteboard: A3 [glsa]
: 207385 (view as bug list)
Depends on:
Blocks: 209002
  Show dependency tree
Reported: 2008-01-15 13:47 UTC by Robert Buchholz (RETIRED)
Modified: 2020-04-04 10:14 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Robert Buchholz (RETIRED) gentoo-dev 2008-01-15 13:47:16 UTC
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:

Please commit updated ebuilds to CVS and we'll handle stabilization here privately until details of this bug are no longer under embargo.
Comment 1 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2008-01-15 20:49:55 UTC
Robert seems like this one could be opened now?
Comment 2 Tiziano Müller (RETIRED) gentoo-dev 2008-01-16 10:33:35 UTC
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...
Comment 3 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2008-01-16 19:12:14 UTC
This one is public now. CC'ing herd and unCC'ing maintainer.
Comment 4 Robert Buchholz (RETIRED) gentoo-dev 2008-01-17 01:48:06 UTC
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.
Comment 5 Tiziano Müller (RETIRED) gentoo-dev 2008-01-17 16:49:33 UTC
Ok, will commit a fixed boost-1.34.1-r2 as soon as possible.
Comment 6 Tiziano Müller (RETIRED) gentoo-dev 2008-01-19 20:34:04 UTC
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).
Comment 7 Jonathan Smith (RETIRED) gentoo-dev 2008-01-23 19:45:11 UTC
er, actually rpath does this:

meaning... we apply patches directly from upstream
Comment 8 Jonathan Smith (RETIRED) gentoo-dev 2008-01-23 19:46:18 UTC
Oh, the second patch listed fixes the regex tests. That was mentioned on the vendor-sec thread...
Comment 9 Tiziano Müller (RETIRED) gentoo-dev 2008-01-24 08:27:40 UTC
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/

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!
Comment 10 Robert Buchholz (RETIRED) gentoo-dev 2008-01-24 12:17:19 UTC
I would not think an infinite loop is acceptable. Does that occur with prior versions?
Comment 11 Tiziano Müller (RETIRED) gentoo-dev 2008-01-24 12:48:49 UTC
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.
Comment 12 Robert Buchholz (RETIRED) gentoo-dev 2008-01-24 13:51:38 UTC
Sounds reasonable. Arches, please look at test results then.

Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sh sparc x86"
Comment 13 David Leverton 2008-01-24 14:31:46 UTC
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;
         // do nothing...
      case syntax_element_backstep:
      insert_point = this->getoffset(this->m_last_state);

where the ^M is a carriage return. 
Comment 14 Tiziano Müller (RETIRED) gentoo-dev 2008-01-24 15:49:09 UTC
Thanks. Fixed by bumping the tarball. Please wait a couple of hours until the updated ebuild and the tarball appear on the mirrors.
Comment 15 Christian Faulhammer (RETIRED) gentoo-dev 2008-01-24 19:11:16 UTC
x86 stable
Comment 16 Raúl Porcel (RETIRED) gentoo-dev 2008-01-25 10:53:26 UTC
alpha/ia64/sparc stable
Comment 17 Markus Rothe (RETIRED) gentoo-dev 2008-01-25 19:02:04 UTC
ppc64 stable
Comment 18 Jeroen Roovers (RETIRED) gentoo-dev 2008-01-26 12:22:37 UTC
Stable for HPPA.
Comment 19 Tobias Scherbaum (RETIRED) gentoo-dev 2008-01-26 13:10:27 UTC
ppc stable
Comment 20 Randy Johnson 2008-01-26 15:26:44 UTC
*** Bug 207385 has been marked as a duplicate of this bug. ***
Comment 21 Samuli Suominen (RETIRED) gentoo-dev 2008-02-05 15:42:55 UTC
amd64 stable
Comment 22 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-02-15 09:24:43 UTC
GLSA 200802-08
Comment 23 Peter Volkov (RETIRED) gentoo-dev 2008-02-23 18:01:05 UTC
Fixed in release snapshot.