highmed/highmed-dsf v0.9.2

0.9.2 - Security Release

on GitHub

General remarks:

• This is a drop-in replacement release for DSF version 0.9.1. With the 0.9.2 release, a security issue has been fixed. No configuration changes are required.
• To Update an existing 0.9.1 installation, please see the 0.9.1 -> 0.9.2 Upgrade Guide.
• For a fresh deployment please see the NUM‐CODEX DSF 0.9.2 Deployment and HiGHmed DSF 0.9.2 Deployment guides.

Fixes include:

• Do to a flaw in the Task authorization rule, users authenticated via a valid client certificate from trusted certificate authorities and a corresponding entry in the local DSF allow-list, were able to execute processes that should otherwise not be allowed via the ActivityDefinition authorization extension of the process.

Clients released in the binary assets:

• MPI client PDQ: dsf-mpi-client-pdq-0.9.2.zip
• openEHR client: dsf-openehr-client-impl-0.9.2.zip

Docker containers for this release can be access via the GitHub Docker registry - ghcr.io:

• bpe: ghcr.io/highmed/bpe:0.9.2
• fhir: ghcr.io/highmed/fhir:0.9.2
• fhir_proxy: ghcr.io/highmed/fhir_proxy:0.9.2

Issues closed:

• Unauthorized Process Execution for Authenticated Organizations #406

This release contains contributions from @schwzr, @wetret and @hhund.

How to check whether the vulnerability has been exploited at your site

The history of the task resources and the associated log files can be used to track whether the vulnerability has been exploited at your site and by whom. To do this, you can proceed as follows:

1. Query the history of all task resources: "/fhir/Task/_history?_count=1000&_page=1" (page=2, page=3, etc. until all pages have been viewed).
2. look for the word "draft" on each page
3. if the word "draft" is not found, you are not affected

Instead of steps 1-3, you can alternatively run the following command in the secrets folder of your DSF FHIR installation:

curl -v --cert client_certificate.pem --key client_certificate_private_key.pem --pass "$(< client_certificate_private_key.pem.password)" -H "Accept: application/fhir+json" https://DSF_FHIR_SERVER/fhir/Task/_history?_count=1000000 | grep -o draft

If you don't have a password set on the private key, you can omit --pass "$(< client_certificate_private_key.pem.password)".

If you get a "HTTP/1.1 200 OK" response and do not find any lines with the output "draft", then you are not affected.

1. if the word "draft" was found:
   4.1 Query the history of the task resource via "/fhir/Task//_history".
   4.2 Check if "Task.status=draft" changed to "Task.status=requested" and if "Task.requester.identifier", "Task.restriction.recipient.identifier", "Task.instantiatesUri" and the "Task.input" fields changed
   4.3 If you have found changes, you might be affected by the vulnerability

If you are affected by the gap, you can use the DSF FHIR audit log to trace which user made the update of the task resource from the status "draft" to the status "requested". To do this, follow these steps:

1. search for the ID and the update date in the task resource with status "requested" under "Task.id" or "Task.meta.lastUpdated".
2. in the folder "/opt/fhir/log" you should find the FHIR audit logs, open the file of the day with the update date
3. search for the ID of the task resource and take the organization name from the log entry
4. Contact us with the organization name so that we can take the next steps together.