Question about security - trust certificate xlls best practice

[Kedar Kulkarni]

I am not a security expert. The following is just a figment of my imagination.

I am recently seeing a lot of posts about xlls being used as a way to introduce a virus in a system, I am trying to understand if there is a way to address the following scenario or if my concerns are not valid.

We usually just add our certificate to the xll files. As I understand they remain unchanged during build process and the DNA file would have the information of the DLLs to be loaded. Now for an unpacked addin, a threat actor can just pick the xll, modify DNA and combine it with their dlls and distribute, and essentially excel would load without raising any red flags where the certificate is already trusted. 

Because the xll is not at all modified and it solely relies on dna file to load dlls. Can this be done in a way where the build process could add the checksum of the dna file or the checksum of the dll files so that any tampering could break the signature to the xll or xll only loads dlls that are digitally signed with the same security certificate.

Or do we have a better way to deal with this scenario and this is already addressed?

thanks

[Govert van Drimmelen]

Hi Kedar,

Making a signed unpacked .xll (which is basically just the generic ExcelDna template .xll) would indeed be a problem and a bad idea as you describe

Instead, the intention is taht you only sign the packed add-ins. These have the .dna file in and hopefully the other assemblies too. The signed, packed .xll should be tamper-proof.

But I'm not a security expert either.

-Govert

[Kedar Kulkarni]

thanks for the confirmation that it is a bad idea. I think I would at least avoid that and make it more difficult though not impossible to exploit the trust certificate.