New issue
Advanced search Search tips

Issue 846240 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2018
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: ----
Type: Bug-Security



Sign in to add a comment

Security: Chrome Update DLL Hijack to privilege escalation

Reported by alei...@gmail.com, May 24 2018

Issue description

This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different
template.

Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com
/chromium/src/+/master/docs/security/faq.md

Please see the following link for instructions on filing security bugs:
https://www.chromium.org/Home/chromium-security/reporting-security-bugs

NOTE: Security bugs are normally made public once a fix has been widely
deployed.

VULNERABILITY DETAILS

During the update of Google Chorme version 66.0.3359.181 with updater 1.3.33.15, if updater is executed as NT SYSTEM, it will use folder C:\Windows\Temp as part of instalation process. This folder is user writable in Win10, so it's possible to Hijack DLL in order to elevate privileges from User to NTSYSTEM.

VERSION
Chrome Version: [66.0.3359.181] + [stable]
Operating System: [Windows 10 Enterprise, version 1709, OS Build 16299.371]

REPRODUCTION CASE
To reproduce the bug you'll need to plant a DLL, which is not a knownDLL, as User into the folder C:\WINDOWS\TEMP\CR_951A1.tmp\ an then at the start of the installation Setup.exe will load it, and execute as SYSTEM. For example could use wtsapi32.dll...
 
chorme.jpg
51.0 KB View Download
Labels: OS-Windows
Summary: Security: Chrome Update DLL Hijack to privilege escalation (was: Security: Google Chrome Update version 66.0.3359.181 DLL Hijack to privilege escalation - Win10 64 bits)
To clarify, please explain how the attacker's code predicts the CR_951A1 path name, and how you determined that the path in question was not individually ACL'd by the installer to something other than USER?

Comment 2 by alei...@gmail.com, May 24 2018

You are right, my icacls script automation was messed up, folder permisions are right.

Thanks and best regards,
Status: WontFix (was: Unconfirmed)
Project Member

Comment 4 by sheriffbot@chromium.org, Aug 31

Labels: -Restrict-View-SecurityTeam allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

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

Sign in to add a comment