security_OpenFDs fails and reports open file descriptors for shared objects used by Chrome's symbolizer for non-official chrome binaries
Reported by
sabin.fl...@intel.com,
Oct 6 2016
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 Platform: 8868.0.2016_10_06_1351 (Test Build - XX) developer-build swanky Steps to reproduce the problem: 1. ./setup_board --board=swanky --force 2. ./build_packages --board=swanky --withautotest --showoutput --nowithfactory 3. ./build_image --board=swanky --noenable_rootfs_verification test 4. test_that "ip" security_OpenFDs What is the expected behavior? Test Passes What went wrong? Test Fails. Several descriptors opened for mapped .so(s) Did this work before? N/A Chrome version: 55.0.2880.0 Channel: dev OS Version: 8868.0.2016_10_06_1351 Flash Version: Shockwave Flash 23.0 r0
,
Oct 6 2016
It turns out I'm seeing regular file descriptors for shared libraries on my test device as well. This is quite odd, given that all the mmap()ed libraries shouldn't have open file descriptors. Interestingly, I only observe this for renderers, the browser process is not affected.
,
Oct 6 2016
The zygote process has all the .so descriptors open though, so they're apparently inherited into the renderer processes. Remaining question is to figure out how the zygote process ends up in this state.
,
Oct 6 2016
Looked some more: I think the FDs are opened by the stack dumping code here: https://cs.chromium.org/chromium/src/base/debug/stack_trace_posix.cc?rcl=0&l=592 This code is disabled for OFFICIAL_BUILD, explaining why the test succeeds on our test infrastructure. Thus, the failure is actually a red herring and doesn't indicate a security issue. We might adjust the test to whitelist regular file descriptors for shared modules in case we're dealing with a non-official chrome binary. This introduces the risk of mis-detection though and accidentally allowing these FDs even for release builds... Given that, I'm hesitant to do anything about this. Maybe adjust the test output to alert readers to the fact that this test is expected to fail against non-official Chrome binaries is a reasonable solution? Removing security labels given that there are no security risks for users.
,
Oct 6 2017
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||
►
Sign in to add a comment |
|||
Comment 1 by mnissler@chromium.org
, Oct 6 2016