4

"All you'd have to do is build a plugin and you could completely pwn the software."

I'm building an application using plugins. I think all you have to do is build a plugin and copy it into the correct directory and my main program would happily run it. I'd like the main program to be smart enough to detect unauthorized plugins and reject them. An encrypted signature on each plugin would work well. Has anyone done anything toward a secured, and cross platform, framework for Qt plugins? Or a cross platform library for generating signatures for shared libraries?

I'm aware of how windows does this. Linux not so much. I don't need Mac compatibility.

Thanks for your time!

Jay
  • 141
  • 3
  • 3
    Who is the enemy here? The user? As a user, "all I'd have to do" is run the main program in a debugger and skip past the rejection so that my unsigned plugin can run. – bstpierre Dec 01 '11 at 20:57
  • I can't protect from someone who has an ICE or debugger. I hoped to protect the application from virii installing bogus plugins or modifying an existing shared library. – Jay Dec 01 '11 at 23:14
  • Sounds like a reasonable goal. – bstpierre Dec 02 '11 at 04:13

2 Answers2

6

As suggested by bstpierre, you cannot protect yourself against malicious users since a plugin allows by definition to run arbitrary code.

However, if you want to prevent the abuse case where an innocent user downloads a plugin which seems legit but is not, you can do some signature checking with asymmetric crypto to make sure that this does not happen.

When talking about cross-platformness, have a look at Qt Cryptographic Architecture (first google hit on "qt crypto"). Seems to me that this is what you're looking for, although I don't have any experience with this framework myself.

Henri
  • 1,525
  • 10
  • 11
2

I appreciate the way you are trying to protect your users; kudos. However, I also want to inject a small note of caution, so you know what you are getting into. The hardest part is not the cryptography (e.g., public-key signatures). The hardest part is the process for determining which plugins are considered legitimate.

Are you going to act as a gatekeeper, determining which plugins are legitimate? Are you going to build a curated gallery of legitimate plugins? If so, how are you going to tell which ones are legitimate and which ones are not? Are you going to do a careful code review of their source code? If so, have you thought through how you will fund and support that, and what kinds of delays it will impose on plugin developers? Or, if you were thinking that you could just look at the appearance of the plugin and you'd know, then you are probably being too optimistic; it is easy for attackers to create a plugin that looks legitimate but actually contains a backdoor.

This is challenging stuff. This is not a situation where you can just write a few lines of code, and call it a day. Make sure you are aware with what you are biting off, and think through the business process issues carefully.

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 1
    The plugins will all be developed internally. The reason for them being plugins is so I can easily load and unload them to recover RAM when code is no longer needed. I use the Qt plugin system because it has very low overhead and abstracts away the differences between loading shared libraries/DLL's on different operating systems. – Jay Dec 02 '11 at 13:48
  • @Jay, ahh, OK, then my cautions are not relevant! Great, glad to hear that the simple solutions will work well for you. – D.W. Dec 02 '11 at 17:28
  • @Jay, on further thought: if you are only thinking of using plugins for code you write, why do you even provide any facility for users to install their own plugins? If you simply avoid exposing any such facility to users, then the risk goes away. That seems like a simpler solution to me. – D.W. Dec 02 '11 at 17:30
  • I don't *on purpose* provide any way for installing a plugin. All that would be needed to inject malicious code is to get the sample source code for a plugin from a public site, get the un-encrypted signature for my plugins from a hex dump of the existing plugins, and copy it over an existing plugin file. I think the only way to fix it would be to redo their signature test to use an encrypted signature and a hash of the binary. – Jay Dec 02 '11 at 21:07
  • @Jay, but if that's your threat model, we could equally well say "All that would be needed is for the user to get a malicious executive from a public site, and copy it over the executable file for your program". Or, "All that would be needed is for the user to download a malicious executable and run it". It seems more far-fetched that a user would inadvertently copy over an existing plugin file (what would make them go to the trouble to do that?), than that they would inadvertently run a malicious executable file. – D.W. Dec 03 '11 at 04:04
  • True, but neither of those scenarios would make me liable for negligence. I can show that I used all due diligence in protecting others. – Jay Dec 03 '11 at 14:40
  • I don't think any of the three scenarios (not even the one with plugins) makes you liable for negligence. I think you're solving a problem you don't need to solve. Has a lawyer told you that if you don't do this, you'll be liable for negligence? Unless you're getting this from a lawyer, I'd skip it. – D.W. Dec 03 '11 at 21:35