Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 498134 - <dev-util/boost-build-1.54.0: Denial of Service
Summary: <dev-util/boost-build-1.54.0: Denial of Service
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B3 [ebuild]
Keywords:
: 427306 441034 447782 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-01-15 06:41 UTC by Nathan Phillip Brink (binki) (RETIRED)
Modified: 2014-06-19 08:35 UTC (History)
4 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2014-01-15 06:41:22 UTC
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
Comment 1 Sergey Popov gentoo-dev 2014-04-07 10:58:40 UTC
+  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.
Comment 2 Sergey Popov gentoo-dev 2014-04-07 11:13:00 UTC
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.
Comment 3 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-04-07 14:31:26 UTC
(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.
Comment 4 Sergey Popov gentoo-dev 2014-04-08 07:13:22 UTC
(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?
Comment 5 Alex Legler (RETIRED) archtester Gentoo Infrastructure gentoo-dev Security 2014-04-08 07:46:39 UTC
(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.
Comment 6 Sergey Popov gentoo-dev 2014-04-08 10:29:17 UTC
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.
Comment 7 Sergey Popov gentoo-dev 2014-06-19 08:35:21 UTC
*** Bug 441034 has been marked as a duplicate of this bug. ***
Comment 8 Sergey Popov gentoo-dev 2014-06-19 08:35:34 UTC
*** Bug 427306 has been marked as a duplicate of this bug. ***
Comment 9 Sergey Popov gentoo-dev 2014-06-19 08:35:43 UTC
*** Bug 447782 has been marked as a duplicate of this bug. ***