I completely agree. I have reviewed the code that went into that bug fix, and there is NOTHING in there prevent other plugins from setting themselves up as 'always trusted'. No validation of any kind. 

I have to completely disable the PDF plugin at this time because the security of my system is far more important than being able to view charts in the print preview from Google Drive. 

marking as Untriage and requesting Dev team to look into this.

Note: able to reproduce this on Win7, Mac OSX 10.11.5 & Ubuntu 14.04 using 51.0.2704.106 Stable, Beta 52.0.2743.60, Dev 53.0.2783.2 & canary 53.0.2785.0 

Chrome PDF viewer is a core component of Chrome and so is enabled by default, just as other core Chrome components are e.g. HTML and Javascript parsing.

If you wish to use another PDF viewer you can do so by disabling it.

Enabled/disabled is not the issue. 

The issue is not having the ability to turn off "Always allowed to run".

I want to enable the Chrome PDF viewer but only run when I deem necessary. Like we were able to do before. 

As answered in #5 - Chrome PDF viewer is a core component of Chrome and like other core components of Chrome it is enabled and will run by default. The component only exists in chrome://plugins to allow it to be disabled for compatibility reasons (e.g. for support of PDF signing in an enterprise environment).

I'm sorry but this just doesn't make sense. 

We can completely turn it off without issue, but we aren't allowed to selectively turn it off? Despite the fact that we could before? 

Also, what about the issue where any other plugin can just make themselves fully trusted now by setting a simple string in their resource JSON file? 

Additionally, what about the whole vulnerability that was fixed in May with the library used by the PDF library Chrome depends on? That is why we want to be able to selectively enable this. 

Would you be able to shed light on the bug that I can't view that triggered this change Will? Bug #509251. The bug system won't let me view it. It might help us understand why the team went and actively removed functionality that your users use to protect themselves. 

You were the one who made the change in the code as shown here: 
https://github.com/nwjs/chromium.src/commit/e53608ba54b3aff711c1e1c68243417f99bcd340

What's to stop any other plugin from just setting their status to "fully_trusted"? 

The plugins_json file is compiled into Chrome and can't just be changed by any plugin.

Chrome PDF is a core component of Chrome and the best defense against any future vulnerability in Chrome component (e.g. Blink, V8, Chrome PDF) is to ensure that you always keep your copy of Chrome updated.

Please also note that some of the tech news articles for CVE-2016-1681 says "arbitrary code execution" but forgot the important detail of "inside a sandbox".

It makes sense that you want this to have the always enabled toggle enabled by default so the functionality works when other plugins are blocked by default. The part that doesn't make sense is hard-wiring the toggle instead of simply setting the default. It's still a plugin that's not present on platforms without plugins like Android, not a core component, so there isn't a technical reason to do that and allowing that toggle to be disabled doesn't mean that it can't be checked by default unlike before so out of the box usability remains good.

JavaScript is *actually* a core component and is much more crucial to the web than PDF support, yet Chromium offers support for disabling it by default and providing a per-site toggle / whitelist. Offering that for PDF rendering again is as straightforward as making it always enabled by default without hard-wiring the setting.

Attack surface reduction is orthogonal to updates and sandboxing. They don't alleviate the lost security from this change. PDFium continues to be a major source of vulnerabilities and the plugin toggle mechanism was a great way to eliminate that risk: https://chromereleases.googleblog.com/2016/12/stable-channel-update-for-desktop.html.

This setting change has allowed malicious popups to hijack the PDF viewer to open links and get around adblock/Chrome's popup blocker. The user should be able to choose if the want to allow PDF viewer to run by default. It's a security risk.

re comment #12 can you be more specific about your security issue? - if possible please raise a new security bug using this link:

http://code.google.com/p/chromium/issues/entry?template=Security%20Bug

You mentioned being able to completed turn off pdf viewer since you can't access it in plugins -- how do you accomplish this? 

I want to second the question in Comment 14. How can the pdf viewer be turned off completely please? 

I just ran into this issue as well. I can find no way to disable, turn off, remove, etc. the PDF viewer in chrome. This is a HUGE issue. Forget selectively disabling it, how can it be permanently removed?  If this is not possible, then chrome will have to be removed from our systems. 

re: #16 I am interested in the reasons behind wanting to disable/turn off/remove the PDF viewer in Chrome and why this is a "HUGE issue".

There are already user-facing options to "always open in external viewer" for downloaded PDF files, are these not sufficient?

It's not sufficient, because there is no way to prevent the PDF from loading in Chrome anymore. For callback generated PDFs there is no way to download the PDF without first opening it in Chrome. Being unable to download and check a file before opening it is bad :( 

Hi, there is a setting in chrome://settings/content and search for "Open PDF files in the default PDF viewer application." - ticking this box should always open the PDF in an external PDF viewer. Is this not sufficient?

Well, it's a work around at least. We can set the default program to none, which will force Chrome to download the file.  But that's a pain, since then the user has to manually open the program for the PDF first. Really, an option that just says always download PDF. Or the ability to disable the pdf viewer would be much better. 

I'm not seeing the same behavior as you, can you confirm which version of Chrome you are using and OS version?

On Chrome stable 56.0.2924.87 on Windows, when I tick "Open PDF files in the default PDF viewer application." in chrome://settings/content (at the bottom of the content settings) then Chrome's PDF viewer is disabled.

See screenshots showing navigator.plugins with option disabled (before), and enabled (after)

Deleted: pdf_option.png 6.4 KB

	pdf_option.png 6.4 KB View Download

Deleted: navigator_plugins_before.png 54.5 KB

	navigator_plugins_before.png 54.5 KB View Download

Deleted: navigator_plugins_after.png 31.5 KB

	navigator_plugins_after.png 31.5 KB View Download

Yes. The chrome viewer is disabled, but there is still no way to SAVE AS FILE. As chrome will pass the PDF directly to the default app. Unless there is no default app.  

Comment 19 is really a useful work around - as, at least for me, the built in PDF viewer is broken in the last days. I could not disable it (in chrome://plugins the "always allowed to run" is grayed out).

*Probably* a related problem is that it is impossible to print from Chrome in (again, for me) in the last days. I still have to check how I disable the print from chrome frame... It will be appreciated if anyone can confirm that the problems are related.

@WFH .. in regards to comment 19 .. *NO IT IS NOT ACCEPTABLE!*

the option to "Open PDF files in the default PDF viewer application" again causes the file to AUTO DOWNLOAD AUTO OPEN AND THUS AUTO RUN!

What part of CONFIRM DOWNLOAD AND SAVE DIRECTORY is not making it through? I'm sorry if this sounds like I'm being the jack-hole here, but really have you NEVER been bitten or had friends been bitten by a something that Auto Downloads, Auto-Opens/Runs regardless of application used?

The DEFAULT options should be to prompt a user where they want the file downloaded, IF, the PDF option (in chrome) is disabled.

By not allowing the user to remove the check mark from "always allowed to run" you force the OTHER check mark and ergo action to auto download and auto run, as one of the other users put it .. causing multiple copies of a document in a single location.

Your setting the PDF options this way means it DOES NOT RESPECT the "Ask where to save each file before downloading" and **THAT** should be respected PERIOD!

Just to add to the above..

Proof PDF's can't be trusted regardless of WHO or WHAT opens them:

Sans Diary .. created a PDF, auto exec's java and drops a EICAR virus trigger
https://isc.sans.edu/diary/Test%2BFile%3A%2BPDF%2BWith%2BEmbedded%2BDOC%2BDropping%2BEICAR%2B/20085

Targetted attacks
https://isc.sans.edu/forums/diary/Targeted+attacks+using+malicious+PDF+files/4330

yes.. 2008 probably before your time.. but ZERO DAY EXISTS and BECAUSE it exists, the SAFEST plan many of us can take is to be PROMPTED before a file is auto downloaded, and auto run without our explicit knowledge and conscent.


CVE - recent Aug 2016
https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3319

The PDF library in Microsoft Windows 8.1, Windows Server 2012 Gold and R2, Windows 10 Gold and 1511, and Microsoft Edge allows remote attackers to execute arbitrary code via a crafted PDF file, aka "Microsoft PDF Remote Code Execution Vulnerability." 

So here is what people like you *seem* to think "not my problem" .. its not a failure in chrome its something external.

Where the arrogance comes from, is believing your sh*t doesn't stink, and that the stuff around you is the sole issue.  Its not, when your browser deliberately ignores the *user preference* to be prompted where to save a file.

I also get after firefox because of THEIR arrogant stupidity .. eg.. you go to a self signed SSL site or even a site with bad SSL (expired date, names don't match, whatever) and while its good they offer the user the ability to "add an exception" for some of those things.. their *DEFAULT* security posture, is to have the "Permanently store this exception"  box checked.  You see, its more secure because the user has to go to "advanced" and then select "add exception" so still allowing the user flexibility, BUT it should *not* default such a check box .. so that you really are requiring the user to make the active choice to save the exception permanently.

So .. don't just think I'm here to nail chrome to the crosses.. there is a seriously fine line between safety, security, and arrogant stupidity.

And here.. 
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pdf

447 vulnerabilites matching PDF 

First one in the list.. Jan 13th 2017
===
CVE-2017-5364

Original release date: 01/13/2017
Last revised: 02/02/2017
Source: US-CERT/NIST
Modified

This vulnerability has been modified since it was last analyzed by the NVD. It is awaiting reanalysis which may result in further changes to the information provided.
Overview

Memory Corruption Vulnerability in Foxit PDF Toolkit v1.3 allows an attacker to cause Denial of Service and Remote Code Execution when the victim opens the specially crafted PDF file. The Vulnerability has been fixed in v2.0.
===

@WFH ... again .. just to re-itterate and to apologize I may sound like a a-hole about this, but its only because so far you've failed to see how bad a decision it is to bypass the download box and not provide the user choice to be prompted.  I don't care if PDF viewing is considered required or core component functionality .. if you can not see this issue is *very* bad you, shouldn't be in this game.

ANY file you auto download and auto launch in an external program should REQUIRE the user's direct consent *or* the bypass - make them select wehre to save the download.

And don't assume that users should be required to "right click - save as" because that does *not* always work as intended.  Bank-statements guy in this and one other thread is a prime example; because some times, you have to go to a secondary page where, if pdf handling is OFF in a browser, the redirect and attempted content download, should become a "Save File" download prompt.

 Issue 680202  (PDFs can no longer just be saved when built in PDF viewer is disabled) is fixed and will be in the next 57 beta.

Comment #24 deserves a beer.  I'm really starting to get tired of Google trying to emulate Apple by making decisions for users that the users cannot override.

I never want PDFs to open in the browser, nor do I want them to auto open.  Never ever?  Never ever ever.

Please fix this before I go hunting for DLLs to delete or something.

The discussion here has moved towards the PDF auto-open in external viewer issue, and  bug 680202 , which sounds similar, has been marked fixed. I would recommend trying out Google Chrome Canary and see if the behavior there is the desired behavior. If so, sit back, have a $beverage, relax, and wait for the fix to roll out.

Issue originator, long absent, chimes in...

My organization doesn't care about or use external PDF viewers unless unavoidable.

Chrome/Chromium's built-in PDF viewer is probably the safe-*est* PDF viewer available.  

In fact, we even use it as the default PDF viewer for operating systems & file managers.

That said, saying "safest PDF viewer" is kind of like referring to someone as the "least dangerous serial killer."
__

We wish we could, once again, set the internal viewer to always ask user first or right-click to run, and add allow easy exception to "Allows trust PDFs from this domain."  

If Google needed "always trust" to make Google Drive/Gsuite and or Chrome printing to work well it should have been done with a default (or persistant) "always trust PDFs from *.google.com" entry or built-in exception(s) like that.  That would have been fine.
__

Any statement "you can always trust X" is likely to be proven false over time.
__

Is no one embarrassed that chrome://plugins/ has devolved to having a user interface control that no one will ever be able to control?

@sco in comment 30, while I respect the first part of what you're saying, because we're both saying similar things, its the latter that has issues.

Google can not be allowed to default the "allow google" permission.  At the best, they might set the option to allow only "google" properly signed certs for self signed documents.

We are always, at best, just a few days behind our virus and malware definitions.

Re comment #31: The auto-open behaviour has been reverted. It was indeed a mistake in the first place and we recognized the same security threats that you do. This is also why even with the manual setting (you can choose from the download bar) for automatically opening files of a particular type we  have special logic for PDFs, where if you have Acrobat as your viewer you can only let it autostart if it is the newest version. 

as for comment 30: I think what you mean is you would want the click to play behavior for pdf just like for flash am i right? In which case this deserves a new bug.

Exactly: My organization "wants the click to play behavior for pdf just like for flash".  

Also, the ability to allow site/pattern based allow/block just like for flash.

...Like it used to be before issue 1857263004.

That was the whole point of starting this issue/bug in the first place.

I would be fine if there was a default and/or upgrade-added *.google.com and/or file:///* allow if that was the motivation behind issue 1857263004.  Others in this thread, like comment 31 trebo..., would perhaps need to know that they could remove, block or prevent any such *.google.com allow exception.

@sco / Comment 33

Yes, I know remove/block/etc ... but the point is you can't have a default of "allow google"

Did you miss the whole eDellRoot certs issue?  
https://www.kb.cert.org/vuls/id/870761

Or IBM's preloaded app doing MIM on https?
https://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/

while these aren't exactly the same .. they have a root together and that is the company trusting themselves, their domains, their apps in ways that users aren't readily prepared for.

Default trust should be something the user chooses ... be it by manually adding entries or by being asked and warned of consequences of allowing defaults.

Google can Recommend but should not assume the position of trust.  Just as all users shouldn't trust so openly, either.

re: comment 34 - to me it sounds like Scott is saying he wants to set his settings to *.google.com. If your concern is that Scott should not do that, feel free to discuss that with him offline.

If your concern is that Google Chrome will whitelist *.google.com by default - I don't think that's happening, as none of the other content settings, e.g. Popups, has *.google.com in it by default AFAIK.

This problem has been raging for nearly a year now and still no fix?  Why can't google move faster than a glacier?