| Summary: | <dev-util/boost-build-1.54.0: Denial of Service | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Nathan Phillip Brink (binki) (RETIRED) <binki> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | alexanderyt, cpp+disabled, iam, zerochaos |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=506064 | ||
| Whiteboard: | B3 [ebuild] | ||
| Package list: | Runtime testing required: | --- | |
+ 07 Apr 2014; Sergey Popov <pinkbyte@gentoo.org> boost-1.53.0-r1.ebuild, + boost-1.54.0-r1.ebuild, boost-1.55.0-r1.ebuild: + Fix parallel compilation with high number of MAKEOPTS jobs, wrt bugs #506064 + and #498134 CCing security@ Please advise, should we take some action on this, cause it's clear build-time DoS failure and i doubt that it can be used for serious things. Oops, i am someway wrong, it's runtime failure of boost-build. Despite the fact i doubt that it is used for something other than building boost, but it seems to be more important that i thought before. This is clearly security related issue. Stabilization of newer versions is not an option, i'd vote for backporting fix. (In reply to Sergey Popov from comment #2) > > This is clearly security related issue. Stabilization of newer versions is > not an option, i'd vote for backporting fix. I don't really see a violation of a trust boundary. You are already able to execute code (`b2' in this case), and given a certain input you can crash said process, or (maybe) use the flaw to execute other code which you however already could when you started b2. (In reply to Alex Legler from comment #3) > (In reply to Sergey Popov from comment #2) > > > > This is clearly security related issue. Stabilization of newer versions is > > not an option, i'd vote for backporting fix. > > I don't really see a violation of a trust boundary. > You are already able to execute code (`b2' in this case), and given a > certain input you can crash said process, or (maybe) use the flaw to execute > other code which you however already could when you started b2. We dealed with vulnerability with sys-apps/file which can be used to crash "file" process itself, why we should skip this? (In reply to Sergey Popov from comment #4) > > We dealed with vulnerability with sys-apps/file which can be used to crash > "file" process itself, why we should skip this? file crashes on input *data* that is usually unknown, with a common use case where it is called automatically with such data (email filtering). This looks like a user setting that causes the issue, not input data. You're also not feeding emails directly into it. Then, the impact is much higher. The file crashes usually consume excessive resources. "A remote attacker could entice you to be a ricer and try to build stuff with >64 jobs, resulting in your job crashing." Somewhat fitting for some hardcore Gentooers, certainly not security though. Ok, i will trust you as a senior security developer. Conclusion: - b2 usually uses just for building Boost; - Boost ebuilds was fixed to not allow more than 64 parallel jobs(recent versions - exits with error without this fix, older ones - just crashed due to this bug); - It's not common to use such high value of parallel jobs for ordinary Gentoo system. So, i assume to close this as fixed. *** Bug 441034 has been marked as a duplicate of this bug. *** *** Bug 427306 has been marked as a duplicate of this bug. *** *** Bug 447782 has been marked as a duplicate of this bug. *** |
Following obtained with =dev-util/boost-build-1.53.0 ohnobinki@gibby ~ $ b2 --version Boost.Build 2011.12-svn ohnobinki@gibby ~ $ mkdir bb-tmp ohnobinki@gibby ~ $ cd bb-tmp ohnobinki@gibby ~/bb-tmp $ echo 'exe a : a.c ;' > Jamroot ohnobinki@gibby ~/bb-tmp $ echo 'int main(){printf("hi\n");return 0;}' > a.c ohnobinki@gibby ~/bb-tmp $ b2 -j999 warning: No toolsets are configured. warning: Configuring default toolset "gcc". warning: If the default is wrong, your build may not work correctly. warning: Use the "toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html ...found 8 targets... ...updating 5 targets... Segmentation fault (core dumped) ohnobinki@gibby ~/bb-tmp $ gdb $(which b2) core GNU gdb (Gentoo 7.5.1 p2) 7.5.1 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". For bug reporting instructions, please see: <http://bugs.gentoo.org/>... Reading symbols from /usr/bin/b2...Reading symbols from /usr/lib64/debug/usr/bin/b2.debug...done. done. [New LWP 15341] warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? Core was generated by `b2 -j999'. Program terminated with signal 11, Segmentation fault. #0 populate_file_descriptors (fmax=0x7fff6cce14e8, fds=0x7fff6cce1420) at execunix.c:397 397 if ( 0 < cmdtab[ i ].fd[ OUT ] ) (gdb) Whenever the -j switch is passed a value greater than 64 (MAXJOBS), the loop in execunix.c:populdate_file_descriptors() reaches beyond the end of the cmdtab array (whose size is MAXJOBS). boost-build-1.54.0 solves this by exiting with an error whenever a high -j value is passed in: ohnobinki@gibby ~/bb-tmp $ b2 -j999 Invalid value for the '-j' option, valid values are 1 through 64. ohnobinki@gibby ~/bb-tmp $ b2 --version Boost.Build 2011.12-svn