This is basically the same as  Issue 633681 ,  Issue 691975 ,  Issue 757193  and a variety of duplicates. These are outside of Chrome's threat model.

This specific variant was previously reported in May as VN: JVN#79200392 / TN: JPCERT#96154085 

#2: As far as the other crbug references are concerned, they are for chrome installer, which does not claim to cleanup the system, so a big difference there.

Couldn’t find the JPCERT info, could you kindly share the link??

Also for this one, the vulnerability goes against Google’s claim and could instead have adverse effect on the user.

Nevertheless, if it still isn’t a security issue, kindly make it public so that we can post our advisory and video.

Eagerly awaiting your reply.

Thanks,
~ Kushal.

Hi Kushal,

As already mentioned we don't consider this within the scope of Chrome's threat model. We do believe in defence in depth and ensuring the Chrome Cleanup Tool follows best pratices, so we will update the tool to use secure dll loading in the future.

Thanks,

Chris

Hi Chris,

Any specific time-line/deadline for the fix? Accordingly we can proceed with our advisory and video post. 

Thanks,
- Kushal.

If I understand correctly — and I'm not sure I do — it seems like a somewhat plausible attack scenario involves the attacker having previously induced, or forced if possible, a victim to download a malicious DLL with the right name (e.g. "ntmarta.dll") and in the same directory as the Chrome Cleanup Tool.

That would most likely be the user's default download directory, of course.

That scenario does not seem entirely implausible. Is `SetDefaultDllDirectories`, or the right flags to `LoadLibraryEx`, sufficient to solve the problem? If so, we should just do that, right?

If I have all that right, I'm not sure we should WontFix this. The attack would seem to not require local authenticated access on the client. (That *would* be outside our threat model.)

I'm in favor of attack-surface-reduction, which is why I'd proposed this change last year. That said, our general policy in Chrome has been that this is an OS platform vulnerability in Windows and not something we've aimed to address in our code.

It's worth noting that Microsoft's executables (e.g. installers for tools, hotfix installers, etc) do not protect against DLL planting attacks, and MSRC does not deem them a vulnerability worth passing along to the owning product teams. So an attacker hoping to exploit users has many choices of "plausible" executable, including archived (signed) versions of the Chrome Cleanup Tool, Chrome's installer, etc.

> The attack would seem to not require local authenticated access on the client.

In  Issue 539018 , we ensured that Chrome will not drop a DLL into the user's Downloads folder without confirmation (downloaded DLLS were and continue to be scanned by Safe Browsing as well).

If we consider this a vector worth addressing, it would probably be worth investing in Issue 605645, which proposes that downloaded executables automatically get dropped into subfolders of the Downloads folder.

> Is `SetDefaultDllDirectories`, or the right flags to `LoadLibraryEx`, 
> sufficient to solve the problem? If so, we should just do that, right?

In some cases, SetDLLDirectories alone isn't enough (see e.g. https://textslashplain.com/2015/12/18/dll-hijacking-just-wont-die/#comment-755). I think we'd need to watch the startup in a debugger (on each OS) to ensure that nothing is missed.

Apologies for not flipping the bug back from WontFix as seems this caused some confusion. As said in #4 - we are addressing this by landing a defence in depth call to SetDefaultDllDirectories. csharp is already handling this, and he can update on timelines.

#7: Again, OS platform Vulnerability in Windows or not, the point remains that the Vulnerability goes against Google Product's claim "scan and remove software that may cause problems with Chrome" and renders the tool meaningless, if not worse.

In this case, logically the primary belief is that "the system is somehow already compromised" thereby needing the "cleanup" using the Chrome Cleanup Tool!!! Therefore this Vulnerability makes much more sense here, as compared to any other comparison with other vendor products or even Chrome installer.

Yes, running the Binary under a debugger or even Procmon from Sysinternals Suite would help understand the relevant DLLs being loaded and thereafter each could be checked manually using the PoC I shared in the Google Drive link within the original report c#0.

Also one would like to include the SafeBrowsing personnel here as well, since amusingly the Chrome Cleanup Tool was being flagged as "Harmful/Malicious", which technically a Google Signed binary shouldn't be, especially more so within another Google Product (Chrome).

Thanks,
~ Kushal.

can you please raise the

Chrome Cleanup Tool was being flagged as "Harmful/Malicious",

in another bug? How we deal with that will depend on exactly what part of the system is marking it malicious, and we can investigate on a separate bug. Please provide your OS/Browser versions and the exact URL and error you are seeing in your report.

#10: Would you want me to report that separate bug, as a Security Bug or Regular Bug? 

Thanks,
~ Kushal.

a regular bug is fine

#12: Just noticed that the Binary in question has been changed/updated/modified since the report and the "Malicious/Harmful" flag by Chrome browser is no longer occurring, so I don't feel there is a need to file the separate bug for now.

BUT, Yes the video I captured on Oct 16th 2017 [When the Vulnerability was first reported to Google] does have the Chrome Flagging in that.

Thanks,
~ Kushal.

Hi Kushal,

This issue should be fixed in the downloadable version of the tool by Nov 176.

can you share the video from Oct 16th 2017 that showed this being flagged during a download? in particular I'd be curious to see which browser, OS, version you were using, and which part of the browser/OS was blocking (i.e. was it Chrome safe browsing, or smartscreen?)

Hello @csharp, @wfh, @elawre..., @palmer, Google Product Security Team,

Good Afternoon.

Firstly, I would like to thank you for accepting this Vulnerability and diligently fixing the same, I sincerely appreciate it.

Secondly, as requested by @wfh in c#15, I am sharing along with the Dropbox Link for the Video, as I was unable to upload it here due to the size constraint. 

Dropbox Link to Video: https://www.dropbox.com/s/m4vs140l9wgftfq/PoC_Video.avi?dl=0

Also I was unable to comprehend the timeline mentioned in c#14, most probably a typo but still it would be nice if you could share the correct date so that I can thereafter re-test the new downloadable binary.

Looking forward to the Bounty and CVE-ID allocation for this one.

Thanking You,

Yours Sincerely,
Kushal Arvind Shah.
Security Researcher | Fortinet's FortiGuard Labs.

Hi Kushal,

Sorry for the typo, the issue should be fixed by Nov 17.

Marking as Low severity since this is a bug in the Chrome Clean Up tool and that's a separate download.

#17: No worries @csharp and thank you for the confirmation, will check the new binary at 00:00hrs PST on 18th Nov 2017. :)

#18: @vakh, Agree to the Tool being a separate download, BUT cannot agree on it being a "Low Severity" Vulnerability since the Tool directly affects/alters the existing Chrome application on the User's Endpoint.

Thanks,
~ Kushal.

#15: @wfh, could you confirm if you were able to access the Video Link shared in c#16 ?? Also please let me know if you need anything else for the same.

Thanks,
~ Kushal.

Re #19: The warning shown in the video at 2:46 is the generic "executables are a Dangerous file type" warning; it's not from AV or SmartScreen.

Re #20: With regard to severity, I'll reiterate that this bug is outside of Chrome's threat model and requires non-trivial user interaction. But the severity debate is moot, insofar as the issue is getting addressed anyway. 

#21: On a fresh install of Chrome, we don't "always" see "executables are a Dangerous file type" warning, so it isn't "generic" AFAIK.

As far as Severity goes, I will re-iterate that it requires "TRIVIAL" User interaction, since a naive User could easily "either directly visit a Malicious Website which would download the malicious dll onto the system OR the user could visit a benign website which could be infected with calling an external malicious website and thereby download the malicious dll". EITHER WAY, all the User is doing is "Regular Browsing" and nothing else significant.

And Yes, I agree the severity debate is moot, just thought I'd share my opinion which was in contrast to the alternative fact..:)

Thanks for Accepting this Vulnerability and thereafter Fixing the same.

Thanks,
~ Kushal.

This issue should now be fixed in the current version of the cleanup tool that users can download.

Hello @csharp, @wfh, @awhalley, Google Product Security Team, 

Good Afternoon.

I would like to confirm that the Vulnerability is now fixed.

Any update on the CVE-ID and reward for the same?

Thanks,
~ Kushal.

Typically, CVEs are assigned when Chrome stable ships but as this isn't in Chrome itself I'm not sure what the process is. Andrew?

In terms of the Vulnerability Rewards program, this is out of scope (and was previously reported by another party).

c#25: @elawre..., 

From my past experiences, I completely understand CVEs are assigned after the Vulnerability is fixed. And since this is fixed, so it should be assigned. Hi Andrew could you kindly help?

Also, so "convenient" that this "was previously reported by another party" and "is out of scope". 

Throughout the entire (one month +) period, the question of duplicate report was never mentioned and now at the mention of a reward, all of a sudden it is "was already reported"??? Shame!!! 

If it was indeed reported, then why didn't you mention it earlier? 

Also why wasn't it fixed by the earlier report then??? 

Also care to share the crbug report of previous report?? 

Lets be transparent, shall we?

As for out of scope, this is "very much in scope" as mentioned in the Chrome Rewards description. 

You do understand that the Chrome Cleanup tool fires up the Chrome Browser and loads up the Settings page to performs activities therein, and this Vulnerability "obviously" interferes in the process and can be used to easily affect the Chrome Browser in every which way, and cause more harm than good!!

Eagerly awaiting your reply.

Thanks,
~ Kushal.

Re #26, kindly read Comment #2.

Re #27, Kindly read Comment #3.

Hello Google Chrome Product Security Team,

Any update on the CVE-ID and Bounty for this one?

Thanks,
~Kushal.

Re #30: With regard to CVE, awhalley@, was a CVE filed for this?

With regard to bounty, let me reiterate-- Even if this were in scope for the Chrome Vulnerability Rewards program (it isn't), any bounty would accrue to the original reporter of the issue (JPCERT).

A CVE has been assigned for this issue. Thanks!

Hello @elawre, Andrew(@awhalley), Google Product Security Team,

Good Evening.

Firstly, I would like to thank you for the CVE allocation.

Secondly, I do not understand why this was not rewarded. Specific Reasons are below:-

1) Since @elawre.. "NEVER" shared the "Supposed" JPCERT link despite asking for the same in c#3. 

2) Also could you kindly explain how this is not in scope for the Chrome Vulnerability Rewards Program? The link "https://www.google.com/about/appsecurity/chrome-rewards/" clearly states any "Bug/Vulnerability manifesting through Chrome is eligible" and "components that we ship or use", and this product clearly fits the bill as mentioned on the chrome-rewards website.

Eagerly awaiting your response.

Thanks & Regards,
~ Kushal.

Hello Kushal,

The JPCrt report came in via email on 2017-05-31 (subject is "[chromium-security] [1-4550000017777] VN: JVN#79200392 / TN: JPCERT#96154085" for those with access to security@chromium.org). Since it didn't come in via the bug tracker I'm afraid there's no link to share, but I can confirm it was received before this report.  So this section of the rules applies:

"Only the first report of a given issue that we were previously unaware of is eligible. In the event of a duplicate submission, the earliest filed bug report in the bug tracker is considered the first report."

Thanks!

Hello Andrew, Google Product Security Team,

Good Evening.

Firstly, I figured that there would be no legitimate link for the JPCERT notification from any other researcher, since there is no mention of it anywhere on the Internet.

Secondly, I would agree with your policy that the Reward goes to the First Reporter, BUT the funny and suspicious part in this case is that "according to Google PSIRT the supposed JPCERT report came in on 31st May 2017" and for FIVE '5' WHOLE MONTHS no action was taken. 

BUT when I reported this issue on Oct 30 (crbug.com) and previously on Oct 16(via Google VRP), Google Engineers immediately started working on this Vulnerability the "VERY NEXT DAY" as seen in c#6, "ASSIGNED on October 31st and fixed it inside of 45days.

My question to the 'Respectable' Google PSIRT team is this: -

If the supposed JPCERT report did come in on May 31st 2017 then why was no action taken for 5 whole months? And then when I reported this issue on Oct 30, immediately it became a critical issue worthy of a fix? And to add to the collusion, upon asking for the supposed previous JPCERT report, there is no trace of it. Could you kindly explain this ???

No matter who found it first (I believe I did because there is no legitimate trace of the other party), someone needs to be rewarded (in compliance with Google policy) and I would like to see that reward at least being given to someone, unlike numerous reports stuck on reward-topanel for years on this portal.

Eagerly awaiting your response.

Thanking You,

Yours Sincerely,
Kushal Arvind Shah.
Security Researcher | Fortinet's FortiGuard Labs.

The tone of comments in #35 seem to reflect a misunderstanding about Chrome's vulnerability rewards program. The reality is that the Chrome organization and its employees *love* to pay out bounties for security issues that are in scope, as described in the program's terms: https://www.google.com/about/appsecurity/chrome-rewards/. We seek to give out more bounties, not fewer; granting bounties is one of the most satisfying perks of the job. 

> since there is no mention of it anywhere on the Internet.

JPCert reported this issue directly to the vendor. If you'd like, you could request that JPCert make report #79200392 publicly visible on their notifications page: https://jvn.jp/en/report/index.html along with the many similar reports (search for "Libraries" to see many public duplicates).

> for FIVE '5' WHOLE MONTHS no action was taken.

No action was taken because the bug was triaged WONTFIX, based on the triage criteria which are *explicitly* called out in the first two sentences of https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Why-arent-physically_local-attacks-in-Chromes-threat-model. 

> immediately it became a critical issue

No, it did not become "critical", it was triaged to Severity-Low.

So, you may be wondering what changed between the original report and your new report that resulted in a fix landing for this issue? Simple: The mitigation code had already been written for a different application, and was trivially copied to the Chrome cleanup tool.

> someone needs to be rewarded (in compliance with Google policy)

If you read the policy, you'll note: "We will typically focus on critical, high and medium impact bugs, but any clever vulnerability at any severity might get a reward."

This vulnerability was in no way clever, and relies upon a broadly understood weakness in the Windows platform. For instance, you'll notice that I blogged about this exact platform weakness exactly two weeks before joining Google: https://textslashplain.com/2015/12/18/dll-hijacking-just-wont-die/ and similar posts go back many years. 

@ c#36: Yes, Chrome organization and it's employees 'love' to pay out bounties for issues that are in scope... Numerous crbug reports show how much 'love' there is and how many are waiting on 'reward-topanel' for years to see that 'love'...and the discrepancies between Chrome responses to similar/same reports from different researchers.

For 5 whole months this was triaged WONTFIX, then WHY FIX IT??? If it wasn't an issue earlier then how come the mindset changed thereafter?? ESPECIALLY when you Yourself know very well about the type of Vulnerability and its implications (referring to 'YOUR' Own Blog).

Its ridiculous that you blog about something as a "serious security bug" in Dec 2015 and in 2017 your own product has the same vulnerability, which you "NOW" say is non-critical, but fix it nonetheless and thereafter have the audacity to cheapen out...SHAME!!!! But not completely your fault, wouldn't expect more in this time and age of Trump!!

Peace Out!!!

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