security questions

I continue to enjoy using Orthanc in a research setting, and appreciate the support of Sebastian, Alain, Osimis, and the community.

I recently read the OWASP 2021 top 10 security concerns, and have a couple questions:

  1. Is there a way to query Orthanc somehow to get the version of openssl that is being used by a given instance (regardless of whether it was statically compiled or linked to an OS-provided versoin)?

  2. What protection exists against database injection, eg, via malicious image headers when Orthanc is being used as a SCP? I’m especially interested in the case of the default db (SQLite).

Thanks,

–Jeremy

Dear Jeremy,

Thanks for your positive feedback on our work. Regarding your questions:

1- If you start Orthanc in “–verbose” mode, you’ll see this information in the logs, for instance:

$ docker run --rm -t -i jodogne/orthanc:1.9.7 /etc/orthanc --verbose

W0217 17:20:38.517863 main.cpp:1956] Orthanc version: 1.9.7
[…]
I0217 17:20:38.670701 Toolbox.cpp:1759] OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021

2- I don’t understand your question. Please could you give an actual scenario together with a sample DICOM file?
https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example

Regards,
Sébastien-

Hi Jeremy,

Regarding your second question about SQL injection, we do trust the binding methods provided by sqlite (and postgresql and mysql). E.g , here’s how an ‘INSERT INTO MainDicomTags …’ is being executed in SQLite:https://hg.orthanc-server.com/orthanc/file/tip/OrthancServer/Sources/Database/SQLiteDatabaseWrapper.cpp#l1037

https://hg.orthanc-server.com/orthanc/file/tip/OrthancFramework/Sources/SQLite/Statement.cpp#l223

HTH,

Alain.

And, BTW, if you happen to have some test DICOM files which include some ‘risky’ data, please share with us. I’m also interested by those files in the scope of the Orthanc Explorer 2 development. You know, the famous patients named ‘"; DROP table *;’ for SQL injection and ‘alert(0)’ for UI testing … (and all his broters and sisters).

Best regards,

Alain.

Thanks both!

–verbose sounds perfect for the first question

yes, Alain that’s exactly what I am asking about. I agree it would be useful to have a few bad images around. I have not tried but I assume it would be easy to cook up a few using dcmodify to edit field values, like changing patient name to “John; drop table *; Smith” and friends, and maybe also inserting strings into fields that expect numeric, bad series numbers such as negative or very large, and so on. There could be other kinds of badness that dcmodify cannot perform. I don’t know how to do it but inserting null values, negative field sizes, or 4G of binary gibberish might violate some assumptions if the db does not check.

Looking at the code and researching a little: I trust the binding method as used in SetMainDicomTag and elsewhere, because its parameterized. Nice. Testing always has its place, of course. I was able to use dcmodify to mess with header values, but don’t want to post such a file to a public forum.

I found a report that denial-of-service can result from certain mal-formed DICOM images as found through fuzz testing https://link.springer.com/chapter/10.1007/978-3-030-41114-5_38