Do all Acrobat Acrobat plugins that use a broker in protected mode need to be certified?

[James32669025nuzb]

For my company's Acrobat plugin, we require our users to sign into a server to enable the plugin's features.

Just to be safe, I want to ask this probably paranoid question:

Must ALL 3rd party plugins that run when Acrobat is in protected mode have their broker binaries submitted to Adobe for certifying?

Or must only plugins that run when Acrobat is in protected mode AND when Acrobat is in "certified plugins only" mode have their broker binaries submitted to Adobe for certifying?

Background for the question:

Until now, our plugin has never been made to work when Acrobat is in protected mode. Now we are enhancing it to do so.

Our plugin requires the user to have an account with us and sign in to enable the plugin's features. After the plugin sends the login request, it also makes network requests to download preferences and other things from our servers. In order for a plugin to make network requests when Acrobat is in protected mode, Developers need to write the code for a broker process that us started by Acrobat and which is allowed to make network requests when Acrobat is in protected mode. The plugin must route its network requests through the broker.

The page at https://opensource.adobe.com/dc-acrobat-sdk-docs/library/overview/SandboxBrokerExt.html says

START OF QUOTE

Plugin broker (The plugin broker process that extends the broker APIs at runtime)

This is the plugin broker process which is private to the associated plug-in. This implements the plug-in specific broker APIs required for the full functionality of the plug-in in sandbox environment. We call them extended broker APIs, as they extend the existing broker APIs to fulfill the plug-in requirements.

The plug-in, which runs in Protected Mode context, communicates with this process directly over a separate IPC channel, 1 -> 6 -> 4, to service additional functionality outside the sandbox boundary which is not provided by broker APIs.

This process is launched by the broker process; it runs with full user rights and independent of the sandbox context. Also, by default it does not honor any policy restrictions or other security mechanisms.

Thus it is the plug-in developer’s responsibility to design and implement it with security in focus; otherwise it can be used to escape the sandbox context.

Also, this binary along with the description (input and output parameters) of the APIs it exposes have to be submitted to Adobe for code signing.

Please note that signature of the plug-in broker executable is verified before launch if the ‘Use only Certified plug-ins’ is checked, so it is the responsibility of the plug-in developer to ensure that this is signed otherwise this would just not work.

END OF QUOTE

My question is - does that part that says "Also, this binary along with the description (input and output parameters) of the APIs it exposes have to be submitted to Adobe for code signing" mean that ALL plugins that run when Acrobat is in protected mode must have their broker binaries submitted to Adobe for certifying?

Or does it mean that only plugins that run when Acrobat is in protected mode AND when Acrobat is in "certified plugins only" mode must have their broker binaries submitted to Adobe for certifying?

[Thom Parker · Accepted solution]

Code signing by Adobe is only necessary for plug-ins that are used in Reader. 

I don't believe that you can get a 3rd party plug-in to be certified by Adobe. That's something they do with thier own plug-ins. It's not for ordinary 3rd party plug-ins. You'd have to be a close Adobe partner to do that. 

You do not need the broker for performing HTTP operations. Sandboxing is only about the local machine. Internet security is handled differently. 

I also have plug-ins that require authentication through a sever script, and I don't use the broker for those transactions.  But it is used for opening a web URL in the browser, since opening the browser is a local system operation. 

[James32669025nuzb]

Hey Thom, thanks for answering.

If you're right that a broker is not needed for making HTTP requests when Acrobat is in protected mode, then I've wasted quite a bit of my company's time and money 🙂

Our plugin is loaded when Acrobat starts up.

All our plugin's menus and features are disabled until the user logs in to our backend service using HTTP.

The user clicks a menu item in our plugin's menu to sign in, enters their login and password into a dialog box, clicks a button, and then our plugin uses an HTTP client to send a POST request to our API servers to log the user in and get a session token that can be used to make future HTTP requests to our API servers.

What I see is that if I enable protected mode in Acrobat, the HTTP POST request to log the user in begins to fail with

"WebException: Unable to connect to the remote server"

and

"SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond"

These are error messages from the .NET Framework HTTP client code (our plugin is written in C++ and uses an in-proc COM object written in C# / .NET for a lot of its UI and other functionality).

It is the fact that these errors happen only when Acrobat is running in protected mode that led me to conclude  that in order for our plugin to work in protected mode, we need to create a broker as described at https://opensource.adobe.com/dc-acrobat-sdk-docs/library/overview/SandboxBrokerExt.html

After reading your reply, I went looking some more and found this:

https://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/sandboxprotections.html

Will plug-ins that access web services via an URL work?

Yes.

That supports what you say.

But why then when I activate protected mode in Acrobat do all of our plugin's HTTP network requests begin failing? Do you have any ideas?

There is a policy configuration file you can provide for your Acrobat plugin that is used when Acrobat is in protected mode - it is described at https://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/sandboxprotections.html

Here is an example plugin protected mode policy file:

; Files Section
FILES_ALLOW_ANY = c:\temp\*
FILES_ALLOW_ANY=%APPDATA%\Citrix\*
; Processes
PROCESS_ALL_EXEC = %SystemRoot%\system32\calc.exe
; Registry
REG_ALLOW_ANY = HKEY_CURRENT_USER\Software\(SomeProgram)
; Mutants
MUTANT_ALLOW_ANY = *imejp*
; Sections
SECTION_ALLOW_ANY = *imejp*

Looking at that web page, I don't see anything about a policy setting to allow a plugin to perform network communication when Acrobat is in protected mode.

So I'm confused.

[Thom Parker]

The COM object is the problem. It's a local resource.  Use the windows library functions. When using C++, stick with C++. 

I use HttpOpenRequest and HttpSendRequest

[James32669025nuzb]

Now that you say that, I remember that when I first started experimenting with trying to use our plugin when Acrobat was in protected mode, our COM object was absolutely failing to load for exactly the reason you say - it's a resource.

Our plugin's COM object resides in a DLL that we install on the C: drive. When I added this line to our plugin's protected mode policy file:

FILES_ALLOW_ANY = C:\*

to allow access to any files on the C: drive, then our plugin's COM object began to be successfully loaded and its code executed while Acrobat was running in protected mode. 

So my current problem it's not that the COM object DLL resource is failing to be loaded. I can step through the code inside our COM object using the debugger. My problem is that when our COM object tries to use an HTTP client to send a GET, PUT, or POST request when Acrobat is in protected mode, the network requests fail.

That having been said, I may try making an HTTP request using HttpOpenRequest and HttpSendRequest from our C++ code as an experiment - thanks for the suggestion.

[James32669025nuzb]

Well, I tried calling HttpOpenRequest and HttpSendRequest from the C++ code for the BasicPlugin sample plugin that ships with the Adobe Acrobat SDK and the HTTP requests sent using those methods do work when Acrobat is in protected mode.

Which means I implemented a broker for our plugin when I didn't need to.

Our Acrobat plugin is written in C++. It uses an in-proc COM object that is written in C# and .NET to display UI and do other things like sending HTTP requests.

I got fooled by the fact that HTTP requests sent from our COM object fail whenever Acrobat is switched to run in protected mode. Now I'd like to know why that's happening.

Really kicking myself for not asking my original question in this forum sooner.

Thanks so much for your help on this issue Thom, you really saved us from making our plugin more complex than it needs to be.

[Thom Parker]

Happy to help.   Don't worry about wasting time.  With writing code it's a full time learning process. It can always be done differently, and it can always be improved or enhanced.  But simplicity is always best, when it's achievable.

Good Luck with your project!