Fatal security vulnerability in Avogadro

Development
1

AFAIK, on startup Avogadro loads any library from some directories. Notably, on *nix it can load plugins form user-writable path ~/.avogadro/plugins. On Windows all pathes are often writable :slight_smile:

If library is proper Avogadro plugin, it will be loaded anyway, and it can execute any malicious code in constructor. It can be virus (do something nasty with user-writable files), trojan horse (send something through network). Virus developer don’t have to code in assembler - all Qt stuff is under his hand!

Regards,
Konstantin

2

I’d like to propose:

  1. Keep book of plugins: which plugins are installed, which are enabled
  2. New plugin disabled by default
  3. When Avogadro is started, and new plugin found, user should be informed and asked, wether he trust this plugin/vendor

Additionally, from viewpoint of Avopkg:

  • additional field “UseNetwork”: user should be informed, if plugin needs network (to prevent trojans). If network isn’t requested, network use must be disallowed for plugin

–
Regards,
Konstantin

3

On Mar 10, 2010, at 5:04 AM, Konstantin Tokarev wrote:

  1. Keep book of plugins: which plugins are installed, which are enabled
  2. New plugin disabled by default
  3. When Avogadro is started, and new plugin found, user should be informed and asked, wether he trust this plugin/vendor

This is a great idea. #1 is already supported through QSettings right now, but #2 and #3 would be good to add. This has the additional benefit that new engines can be installed and added to the user’s list.

-Geoff

4

10.03.10, 14:18, “Geoffrey Hutchison” geoff.hutchison@gmail.com:

On Mar 10, 2010, at 5:04 AM, Konstantin Tokarev wrote:

  1. Keep book of plugins: which plugins are installed, which are enabled
  2. New plugin disabled by default
  3. When Avogadro is started, and new plugin found, user should be informed and asked, wether he trust this plugin/vendor
    This is a great idea. #1 is already supported through QSettings right now, but #2 and #3 would be good to add. This has the additional benefit that new engines can be installed and added to the user’s list.

To clear things, I’d like to add that #2 means “not to run it’s constructor on startup”.

–
Regards,
Konstantin

5

On Wednesday 10 March 2010 04:37:34 Konstantin Tokarev wrote:

AFAIK, on startup Avogadro loads any library from some directories.
Notably, on *nix it can load plugins form user-writable path
~/.avogadro/plugins. On Windows all pathes are often writable :slight_smile:

If library is proper Avogadro plugin, it will be loaded anyway, and it can
execute any malicious code in constructor. It can be virus (do something
nasty with user-writable files), trojan horse (send something through
network). Virus developer don’t have to code in assembler - all Qt stuff
is under his hand!

This is something we discussed at length - security versus extensibility.
Especially if users could just download Python scripts and run them in
Avogadro. How can they be sandboxed? I don’t seriously think there is a thing
any of us can do to fix Windows… It is what it is, and users run it as they
wish.

The user writable directories were added so that new plugins did not have to
be installed in directories only root had access to. I do agree that having
Avogadro pop up a warning before loading a new plugin would be a good thing,
but it does need to be balanced with enabling users to extend Avogadro easily.

I would prefer a system where we maintained the user writable directories, but
did not load the plugin without the users knowledge, whether that is a popup
or whatever. If you are worried about Avogadro loading things from user
writable directories, the user has more problems than that… If an attacker
wished to they could alias ‘avogadro’ to whatever they wanted, including ‘rm -
rf /’ and potentially delete all of the users data… That is with or without
Avogadro at that stage.

We should be careful to ensure the user knows what they are loading, and
Avogadro could certainly improve in this area.

Marcus

6

14.03.10, 19:47, “Marcus D. Hanwell” marcus@cryos.org:

On Wednesday 10 March 2010 04:37:34 Konstantin Tokarev wrote:

AFAIK, on startup Avogadro loads any library from some directories.
Notably, on *nix it can load plugins form user-writable path
~/.avogadro/plugins. On Windows all pathes are often writable :slight_smile:

If library is proper Avogadro plugin, it will be loaded anyway, and it can
execute any malicious code in constructor. It can be virus (do something
nasty with user-writable files), trojan horse (send something through
network). Virus developer don’t have to code in assembler - all Qt stuff
is under his hand!
This is something we discussed at length - security versus extensibility.
Especially if users could just download Python scripts and run them in
Avogadro. How can they be sandboxed?

Python scripts are not dangerous: if it’s doing something nasty it could be easily detected (at least by people who know Python)
Binaries are black horses in this case.

I don’t seriously think there is a thing
any of us can do to fix Windows… It is what it is, and users run it as they
wish.
The user writable directories were added so that new plugins did not have to
be installed in directories only root had access to.

It’s very natural idea. Many applications (OOo, for example) allow to install plugins system wide or for current user
However, don’t forget that any process user run has access to that directories

I do agree that having
Avogadro pop up a warning before loading a new plugin would be a good thing,
but it does need to be balanced with enabling users to extend Avogadro easily.

How it can harm extenibility? If warning is shown only first time,there will be no problem I think

I would prefer a system where we maintained the user writable directories, but
did not load the plugin without the users knowledge, whether that is a popup
or whatever. If you are worried about Avogadro loading things from user
writable directories, the user has more problems than that…

Of course, if user meaningly writes files to these directories, it couldn’t be prevented. But 1)files canbe written by external malicious process 2)malicious plugin could be attached to ‘normal’ as second library.

If an attacker
wished to they could alias ‘avogadro’ to whatever they wanted, including ‘rm -
rf /’ and potentially delete all of the users data…

rm -rf /* can’t be executed by user. Maximum is rm -rf $HOME/* :slight_smile:
Erasing of data isn’t actual for modern malware. Often it’s goal is to still something silently from user and pass through network

–
Regards,
Konstantin

7

How can they be sandboxed? I don’t seriously think there is a thing
any of us can do to fix Windows… It is what it is, and users run it as they
wish.

Well, we can let Windows users configure their firewalls and anti-viruses theirselves…
However, as popularity of Linux grows, security threats one day could become reality for average user. I’m not sure if comlete sanboxing is really needed, but network access from plugins need restriction. I can imagine plugins getting network through libavogadro (if and only if the declare network dependency!), and direct access forbidden by policies of SELinux or AppArmor…
Is it possible?

–
Regards,
Konstantin