A recent topic of discussion during the weekly Ad-hoc phone conference has been management of the external packages which OpenEMR uses. These include:
ADODB
phpMyAdmin
gACL
PostNukeCalendar
Smarty
and of course there has been proposal on the table to add Zend into the mix.
My personal feelings are that if someone is willing to step up to the plate and do the work to test an upgrade/removal/dependency management strategy that would be great. However given the limited resources we have to devote to development, the effort required seems to be far greater than the benefits we would gain.
As an example for ADODB, the version OpenEMR uses is 5.14, and the most recent version is 5.18
Reviewing the change log http://phplens.com/adodb/change.log.html
There are a handful of mysql bug fixes relating to the use of Metadata, but this isn’t a feature OpenEMR uses.
The effort to upgrade this package from a “coding” stand point isn’t that much…
However, to be confident that the upgrade doesn’t break anything would require a lot of testing.
Regarding phpMyAdmin, my personal preference is to remove it from the package, but I do understand the value of keeping it. I also admit that removing it “after installation” is easier than adding it, so it’s not really that big of a deal.
Upgrading phpMyAdmin would probably be useful, given that there have been many security fixes since the version we currently include in OpenEMR was released. http://www.phpmyadmin.net/home_page/security/
Something I’m not sure of is, can the security vulnerabilities in the version of phpMyAdmin in use today be exploited without first authenticating as a valid OpenEMR user?
A similar question could be asked about gACL. In other words if any of gACL’s database queries are not properly escaped can these queries be executed before logging in?
gACL builds queries by concatenation rather than using binding, and parameters aren’t always explicitly escaped before execution; however there are no obvious places where direct user input can make it into a query as an attack vector. If there is enough concern about SQL Injection in gACL, because it uses ADODB, the same strategy we are using to protect against SQL Insertion by using parameter binding would be reasonable to apply to gACL.
Not sure about others on the list but phpMyAdmin is truly external package which only gets the logon ticket from this package.
From operational perspective, we have:
Installed the latest phpMyAdmin as a standalone package in its default directory.
‘database’ link in EMR open standard home page of phpMyAdmin in a separate window.
This allows role of dbadmin who is not a emr admin user. We can also be current on the versions & some new features. This comes at a cost of emr admin having to login separately in phpMyAdmin - since dbadmin has been lazy to configure login tickets…
A relatively simple way to mitigate risk from vulnerabilities in gACL would be to reconfigure it to use a database user that only has permissions to access the gacl_* tables. This way if an attacker exploits any flaws in gACL it would be much harder for SQL Injection to result in leakage of PHI.
phpMyAdmin is heavily used by newer users(especially the DIY variety) that do not have the skillset to install their own phpmyadmin and hook it to the openemr database. Many a times I have asked users on these forums to go to Admin->Other->Database (imagine if I instead stated to install phpmyadmin etc. what would happen to many of these users). It’s sort of like a “bridge” for new users as they learn how to use OpenEMR, open source, customizing, coding etc. It’s also leveraged in other places like the mechanism to install new translations which is generally done by users that may not have the skillset to set up an external phpmyadmin instance( http://www.open-emr.org/wiki/index.php/Install_Translations ). We could always suggest dropping it on the following page to harden OpenEMR security: http://www.open-emr.org/wiki/index.php/Securing_OpenEMR
The gacl codebase is actually rather small and we have basically adopted it (it is no longer maintained) and we have even fixed some bugs in it. It will be much less work to harden this than the alternative (create a new access system from scratch). At this point OpenEMR is barely even scratching the surface of php-gacl usefulness. My guess is that when we get the low level security items dealt with(sql-injection,cross-scripting), then next agenda item will be the user access controls (their are currently a huge number of logic access holes in OpenEMR regarding access controls; and all it takes to fill them is an appropriate acl_check() in addition to further refinement of the acl controls themselves); ie. there will be a news release about how the front staff can view patient medical data in the Reports section… gasp
Something I’ve realized is that the WAMP and XAMPP packages come with copies of PHPMyAdmin. So why do we bother including an outdated copy in the OpenEMR package itself?
OpenEMR version has custom config file that limits OpenEMR user to OpenEMR database and does single sign on - very useful for non-technical user/admins. New versions of phpMyAdmin have additional ways to authenticate users.
It would be cool if the install script detects existing phpMyAdmin and just configures the access. Also if the patch/upgrade script detects the package, it could reconfigure…
