User Administration creates too powerful database accounts

[tburba]

A customer's IT manager complains:

any pacsone user (even without grants) can go to the pacsone/meddream address and open phpmyadmin and make modifications in the DB

(He probably means something different by "grants", but that's insignificant.)

I had a vague suspicion that it's correct, and checked what queries are made by "User Administration" to create a new user. Indeed:

Code: Select all

insert into privilege (username,firstname,lastname,middlename,email,viewprivate,modifydata,forward,query,move,download,print,export,import,upload,monitor,mark,notifynewstudy,admin,changestore,expire) values('u10','10','u','-',NULL,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,DATE_ADD(NOW(), INTERVAL 60 DAY));
SELECT firstname,middlename,lastname FROM privilege WHERE username='u10';
INSERT INTO journal (timestamp,username,did,what,uuid,details) VALUES(NOW(),'root','Add','User','u10','Username: u10<br>Full Name:  10 - u<br>');
GRANT SELECT (host, user) ON `mysql`.`user` TO 'u10'@'localhost' IDENTIFIED BY PASSWORD '*15B4A9F089BEC4C84A24C5148B14A80C14651492';
GRANT UPDATE (password) ON `mysql`.`user` TO 'u10'@'localhost' IDENTIFIED BY PASSWORD '*15B4A9F089BEC4C84A24C5148B14A80C14651492';
GRANT RELOAD ON *.* TO 'u10'@'localhost' IDENTIFIED BY PASSWORD '*15B4A9F089BEC4C84A24C5148B14A80C14651492';
flush privileges;
grant update (firstname,lastname,middlename,email,importdir,importdrive,importdest,exportdir,expire,sharenotes,pagesize,viewerdir,studynoteicon,refreshperiod) on PACS2.privilege to 'u10'@'localhost';
grant select on PACS2.privilege to 'u10'@'localhost';
grant select on PACS2.smtp to 'u10'@'localhost';
grant insert on PACS2.journal to 'u10'@'localhost';
grant select on PACS2.groupmember to 'u10'@'localhost';
grant select on PACS2.userfilter to 'u10'@'localhost';
grant all privileges on PACS2.applentity to 'u10'@'localhost';
grant all privileges on PACS2.autoroute to 'u10'@'localhost';
grant all privileges on PACS2.coercion to 'u10'@'localhost';
grant all privileges on PACS2.dbjob to 'u10'@'localhost';
grant all privileges on PACS2.image to 'u10'@'localhost';
grant all privileges on PACS2.patient to 'u10'@'localhost';
grant all privileges on PACS2.procedurecode to 'u10'@'localhost';
grant all privileges on PACS2.protocolcode to 'u10'@'localhost';
grant all privileges on PACS2.referencedpatient to 'u10'@'localhost';
grant all privileges on PACS2.referencedpps to 'u10'@'localhost';
grant all privileges on PACS2.referencedstudy to 'u10'@'localhost';
grant all privileges on PACS2.referencedvisit to 'u10'@'localhost';
grant all privileges on PACS2.requestedprocedure to 'u10'@'localhost';
grant all privileges on PACS2.scheduledps to 'u10'@'localhost';
grant all privileges on PACS2.series to 'u10'@'localhost';
grant all privileges on PACS2.study to 'u10'@'localhost';
grant all privileges on PACS2.worklist to 'u10'@'localhost';
grant all privileges on PACS2.export to 'u10'@'localhost';
grant all privileges on PACS2.conceptname to 'u10'@'localhost';
grant all privileges on PACS2.autopurge to 'u10'@'localhost';
grant all privileges on PACS2.postroute to 'u10'@'localhost';
grant all privileges on PACS2.config to 'u10'@'localhost';
grant all privileges on PACS2.annotation to 'u10'@'localhost';
grant all privileges on PACS2.cronjob to 'u10'@'localhost';
grant all privileges on PACS2.studynotes to 'u10'@'localhost';
grant all privileges on PACS2.imagenotes to 'u10'@'localhost';
grant all privileges on PACS2.attachment to 'u10'@'localhost';
grant all privileges on PACS2.download to 'u10'@'localhost';
grant all privileges on PACS2.commitment to 'u10'@'localhost';
grant all privileges on PACS2.exportedstudy to 'u10'@'localhost';
grant all privileges on PACS2.autoscan to 'u10'@'localhost';
grant all privileges on PACS2.importscan to 'u10'@'localhost';
grant all privileges on PACS2.monitor to 'u10'@'localhost';
grant all privileges on PACS2.aefilter to 'u10'@'localhost';
grant all privileges on PACS2.matchworklist to 'u10'@'localhost';
grant all privileges on PACS2.performedprotocode to 'u10'@'localhost';
grant all privileges on PACS2.discontreasoncode to 'u10'@'localhost';
grant all privileges on PACS2.performedps to 'u10'@'localhost';
grant all privileges on PACS2.performedprocedurecode to 'u10'@'localhost';
grant all privileges on PACS2.autoconvert to 'u10'@'localhost';
grant all privileges on PACS2.anonymity to 'u10'@'localhost';
grant all privileges on PACS2.studyview to 'u10'@'localhost';
grant all privileges on PACS2.commitmentreq to 'u10'@'localhost';
grant all privileges on PACS2.commitsopref to 'u10'@'localhost';
grant all privileges on PACS2.commitmentqueue to 'u10'@'localhost';
grant all privileges on PACS2.aeassigneduser to 'u10'@'localhost';
grant all privileges on PACS2.otherpatientids to 'u10'@'localhost';
grant all privileges on PACS2.patientspeciescode to 'u10'@'localhost';
grant all privileges on PACS2.patientbreedcode to 'u10'@'localhost';
grant all privileges on PACS2.breedregistration to 'u10'@'localhost';
grant all privileges on PACS2.patientview to 'u10'@'localhost';
grant all privileges on PACS2.performedseries to 'u10'@'localhost';
grant all privileges on PACS2.xscriptemplate to 'u10'@'localhost';
grant all privileges on PACS2.xscriptbookmark to 'u10'@'localhost';
grant all privileges on PACS2.worklistfromhl7 to 'u10'@'localhost';
grant all privileges on PACS2.studyfilter to 'u10'@'localhost';
grant all privileges on PACS2.aegroup to 'u10'@'localhost';
grant all privileges on PACS2.hl7application to 'u10'@'localhost';
grant all privileges on PACS2.hl7message to 'u10'@'localhost';
grant all privileges on PACS2.hl7job to 'u10'@'localhost';
grant all privileges on PACS2.hl7route to 'u10'@'localhost';
grant all privileges on PACS2.hl7patientid to 'u10'@'localhost';
grant all privileges on PACS2.hl7patientname to 'u10'@'localhost';
grant all privileges on PACS2.hl7mothersmaidenname to 'u10'@'localhost';
grant all privileges on PACS2.hl7patientalias to 'u10'@'localhost';
grant all privileges on PACS2.hl7race to 'u10'@'localhost';
grant all privileges on PACS2.hl7patientaddress to 'u10'@'localhost';
grant all privileges on PACS2.hl7homephone to 'u10'@'localhost';
grant all privileges on PACS2.hl7businessphone to 'u10'@'localhost';
grant all privileges on PACS2.hl7mothersid to 'u10'@'localhost';
grant all privileges on PACS2.hl7ethnicgroup to 'u10'@'localhost';
grant all privileges on PACS2.hl7citizenship to 'u10'@'localhost';
grant all privileges on PACS2.hl7attendingdoc to 'u10'@'localhost';
grant all privileges on PACS2.hl7referringdoc to 'u10'@'localhost';
grant all privileges on PACS2.hl7consultingdoc to 'u10'@'localhost';
grant all privileges on PACS2.hl7admittingdoc to 'u10'@'localhost';
grant all privileges on PACS2.hl7ambulatorystatus to 'u10'@'localhost';
grant all privileges on PACS2.hl7financialclass to 'u10'@'localhost';
grant all privileges on PACS2.hl7enteredby to 'u10'@'localhost';
grant all privileges on PACS2.hl7verifiedby to 'u10'@'localhost';
grant all privileges on PACS2.hl7orderingprovider to 'u10'@'localhost';
grant all privileges on PACS2.hl7actionby to 'u10'@'localhost';
grant all privileges on PACS2.hl7callbackphone to 'u10'@'localhost';
grant all privileges on PACS2.hl7entererloc to 'u10'@'localhost';
grant all privileges on PACS2.hl7collectorid to 'u10'@'localhost';
grant all privileges on PACS2.hl7resultcopiesto to 'u10'@'localhost';
grant all privileges on PACS2.hl7quantitytiming to 'u10'@'localhost';
grant all privileges on PACS2.hl7reasonforstudy to 'u10'@'localhost';
grant all privileges on PACS2.hl7assistantresultinterpreter to 'u10'@'localhost';
grant all privileges on PACS2.hl7technician to 'u10'@'localhost';
grant all privileges on PACS2.hl7transcriptionist to 'u10'@'localhost';
grant all privileges on PACS2.hl7transportlogistics to 'u10'@'localhost';
grant all privileges on PACS2.hl7collectorscomment to 'u10'@'localhost';
grant all privileges on PACS2.hl7plannedtransportcomment to 'u10'@'localhost';
grant all privileges on PACS2.hl7orderingfacilityname to 'u10'@'localhost';
grant all privileges on PACS2.hl7orderingfacilityaddr to 'u10'@'localhost';
grant all privileges on PACS2.hl7orderingfacilityphone to 'u10'@'localhost';
grant all privileges on PACS2.hl7orderingprovideraddr to 'u10'@'localhost';
grant all privileges on PACS2.hl7universalserviceid to 'u10'@'localhost';
grant all privileges on PACS2.hl7assignedpatientloc to 'u10'@'localhost';
grant all privileges on PACS2.hl7priorpatientloc to 'u10'@'localhost';
grant all privileges on PACS2.hl7temporaryloc to 'u10'@'localhost';
grant all privileges on PACS2.hl7pendingloc to 'u10'@'localhost';
grant all privileges on PACS2.hl7priortemporaryloc to 'u10'@'localhost';
grant all privileges on PACS2.hl7abnormalflag to 'u10'@'localhost';
grant all privileges on PACS2.hl7natureofabnormaltest to 'u10'@'localhost';
grant all privileges on PACS2.hl7observationmethod to 'u10'@'localhost';
grant all privileges on PACS2.hl7responsibleobserver to 'u10'@'localhost';
grant all privileges on PACS2.hl7allergyreaction to 'u10'@'localhost';
grant all privileges on PACS2.hl7operatorid to 'u10'@'localhost';
grant all privileges on PACS2.hl7priorpatientname to 'u10'@'localhost';
grant all privileges on PACS2.hl7segpid to 'u10'@'localhost';
grant all privileges on PACS2.hl7segpv1 to 'u10'@'localhost';
grant all privileges on PACS2.hl7segorc to 'u10'@'localhost';
grant all privileges on PACS2.hl7segobr to 'u10'@'localhost';
grant all privileges on PACS2.hl7segobx to 'u10'@'localhost';
grant all privileges on PACS2.hl7segal1 to 'u10'@'localhost';
grant all privileges on PACS2.hl7segzds to 'u10'@'localhost';
grant all privileges on PACS2.hl7segevn to 'u10'@'localhost';
grant all privileges on PACS2.hl7segmrg to 'u10'@'localhost';
grant all privileges on PACS2.hl7procedurecode to 'u10'@'localhost';
grant all privileges on PACS2.hl7procedurecodemodifier to 'u10'@'localhost';
flush privileges;

You did a correct thing in "grant update ... on PACS2.privilege": the privilege flags can't be modified by the user himself, even if he connects directly to the database. But, other tables and patient data are at risk.

As seen in the first statement, the account doesn't even have the Modify privilege. Because it is explained in User Administration as Privilege to modify PacsOne Server database tables, the user might incorrectly believe that such an account is "safe" to give away to less-trusted individuals.

This account also doesn't have neither Forward nor Export privileges, however the functionality is basically achieved by inserting a record into dbjob table and there's nothing to stop it. Such a limited user doesn't even need the SELECT privilege on dbjob table, or am I mistaken?

I think at the moment you could give recommendations what privileges on what tables can be revoked without breaking the web interface. Suppose that the user has only privileges "View private data", "Upload", "Export" and "Forward" -- in my experience these are usually given to ordinary doctors.

[pacsone]

The User Privileges (e.g., View Private, Upload, Export, Download, etc) are proprietary settings in PacsOne Server which are designed specifically for the web user interface, i.e., all users can only access the PacsOne Server User Interface pages via a web browser. So those privileges do not necessarily translate into the privilege settings for the database (Mysql or Oracle) users since they are internal/database back-end settings. In other words, the PacsOne Server User Privilege settings control only the UI elements, e.g., which button, URL link, data fields, etc that can be accessed, in the web user interface of PacsOne, but they have nothing to do with the internals of the database (e.g., which table can be accessed or modified, etc).

It's actually considered a security breach if a user can access the local database tools (e.g., MySQLAdmin, phpAdmin, or even direct SQL queries) on the server where PacsOne is running and manipulate the database directly, regardless of privilege settings of that database user. Because the access to the local database tools means they can also manipulate the database data directly (e.g., data table files, indexes, etc).

[diegog]

Hi,
I agree it is a security belch and a very serious issue.
It's looks that Pacsone once create a new user write phpmyadmin access in the MySQL database automatically (no matter what kind of user or permission have in the system).
I tested and it is right even with users that don't have any pacsone grant.

Exactly the point is that Pacsone is a web PACS and everyone that can login to Pacsone can changing the address reach the Phpmyadmin and using his own password go in.

Is there a way to modify Pacsone to not give access permission to Phpmyadmin to every user?

Can you send me a patch for this security bug?

If not how can I modify the access permissions to Phpmyadmin?

Thanks

Diego

[pacsone]

Phpmyadmin should only be allowed access from the Intranet or for better security, from the localhost, so why would you want to expose it to the Extranet or even the public Internet?

No matter what privilege settings you configure for a database user, e.g., even the very basic SELECT privilege, that user will be able to access at least some of the database tables. That's the reason why you should never expose the database internals, e.g., Phpmyadmin, remote MySQL connection, etc, because doing so is the equivalent of invitation for security attacks.