| Summary: | dev-libs/boost < 1.34.1-r2 Two DoS vulnerabilities (CVE-2008-{0171,0172}) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Robert Buchholz (RETIRED) <rbu> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cpp+disabled, levertond, theraptor2005 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://issues.rpath.com/browse/RPL-2143 | ||
| Whiteboard: | A3 [glsa] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 209002 | ||
|
Description
Robert Buchholz (RETIRED)
2008-01-15 13:47:16 UTC
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. |