2

i am using MAF to offer user / customers the possibility to enhance our software. The Add-In will run with limited permissions and can be potentially untrusted code for us as well as for the customer in case they bought the add-in form a 3rd party developer.

In our case, Host and Host-Side Adapter run in the Main AppDomain with full permissions and Add-In as well as Add-In Side Adapter run with nearly no permissions.

When I get the Add-In token via AddInStore.FindAddIns, i can only validate that the Add-In Assembly itself is from the vendor which it should be. If an attacker exchanges the Add-In Assembly, then we will find that out and will not activate that assembly. But anyhow, as that runs with nearly no permissions, an attacker could not really harm the application and the environment (host, intranet etc).

But what is also possible, is that an attacker replaces the host-side adapter Assembly. An Attacker need just to place a new assembly in the right folder. As this runs with full permissions, the attacker code could really harm application and environment. As an attacker is then between host and add-in (more or less a man-in-the-middle), it can change also the data which is exchanges between both.

When i debug my code an check in the debugger the add-in token, i can see all the paths to the different assemblies, which the add-in store took to build up the pipeline:

Add-In Token

Unfortunately, the important information about the Assemblies taken, are private and i can't access them.

Is there a workaround to access this information?

Community
  • 1
  • 1
Tobias Lorentz
  • 81
  • 5

1 Answers1

0

One way to prevent this is to not rebuild the pipeline every time you start your application. If the pipeline DLL is different than the DLL and key in the PipelineSegments.Store, then the DLL will not be loaded.

John Koerner
  • 37,428
  • 8
  • 84
  • 134
  • Hi John, but how would i know initially that the pipeline contains the right DLLs? – Tobias Lorentz Jul 01 '15 at 06:32
  • I believe you can generate the `PipelineSegments.Store` as part of your build process, so you know that the dlls are the correct ones when you ship. Unfortunately there is not a lot of good guidance around MAF, so we are stuck figuring this kind of stuff out as we go. – John Koerner Jul 01 '15 at 11:29