New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 618146 link

Starred by 0 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Direct-leak in execvpe

Project Member Reported by ClusterFuzz, Jun 7 2016

Issue description

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=6396955840479232

Fuzzer: v8_builtins_generator
Job Type: linux_asan_d8
Platform Id: linux

Crash Type: Direct-leak
Crash Address: 
Crash State:
  execvpe
  v8::ExecSubprocess
  v8::Shell::System
  

Minimized Testcase (0.07 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv96JfgbaajxRUtW6KG8icz07m9HgfKnu1Nh2u7BjFP6Xe5ja7vYWMpNjhuIOzON5KsQcPf4L7Y7veNUsLhurGjkZwPzi0gR5_dfbWIkNwf1zwdCdMbKqHVMw4K85aaaoAw4ZgCBVASB1Kmn9xF8vuJ9TadTGIQ
 var v4 = new Array(); 
 v4[0x80000] = 1; 
 var v33 = os.system(v4); 


Filer: tjbecker

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.
 
Does the v8 team care about these sorts of bugs in the os functions?
From a security standpoint, these don't mean very much. We're considering blacklisting the os functions to avoid the side effects they cause.
Project Member

Comment 2 by ClusterFuzz, Jun 8 2016

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4580506931036160

Fuzzer: v8_builtins_generator
Job Type: linux_asan_d8_v8_arm64_dbg
Platform Id: linux

Crash Type: Direct-leak
Crash Address: 
Crash State:
  execvpe
  v8::Shell::System
  v8::internal::FunctionCallbackArguments::Call
  

Minimized Testcase (0.07 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv94jIXN23_oBZLvrv6wi409pRvS--hOoIjOfVU3gh0urXVe0RqgfDQU8ep_Hh9fV5wRrslR5p3EXRZDP5jv7brsUwjzlTcD6U-WDxCuO6RX-wG4hqH0Z52ILyttmY99NkXSRQhN8yK2tH3varjvZ0kVwAj21LA
 var v9 = new Array(); 
 v9[0x80000] = 1; 
 var v29 = os.system(v9); 


Filer: ishell

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.
Cc: yangguo@chromium.org danno@chromium.org
Good question. My first guess is that we don't care all too much because these functions (e.g. the {os.*} family) is only provided by d8 (our debugging shell) and not exposed via Chrome or any other embedder.

danno@, yangguo@: WDYT?
d8 is not shipped in production, and is only used for testing. Let's blacklist os.*.
This particular issue could be a sanitizer issue. As far as I understand it should handle calls to "exec" is a special way.
Cc: kcc@chromium.org euge...@chromium.org
(+kcc, eugenis FYI)

This looks like a eglibc bug.
See https://ghostbin.com/paste/xcvfh for the up-to-date posix/execvpe.c source from eglibc-2.19 (taken from Ubuntu Trusty)

At line 110 (https://ghostbin.com/paste/xcvfh#L110) execvpe() allocates memory for the path and then calls __execve().
If both calls to __execve() fail with ENAMETOOLONG, we return -1 from the switch statement without freeing the memory.

IIUC the problem is already fixed in glibc (https://github.molgen.mpg.de/git-mirror/glibc/commit/1eb8930608705702d5746e5491bab4e4429fcb83), but not in eglibc.

Comment 7 by ishell@chromium.org, Jun 20 2016

Status: WontFix (was: Available)
Marking as WontFix according to #4 and #6.
Project Member

Comment 8 by sheriffbot@chromium.org, Nov 22 2016

Labels: -Restrict-View-EditIssue
Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment