Cybersecurity issues reported for DCMTK

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
Markus Sabin
Posts: 99
Joined: Tue, 2005-07-12, 13:50
Location: Erlangen, Germany

Cybersecurity issues reported for DCMTK

#1 Post by Markus Sabin »

Dear DCMTK team,

I have become aware of a cybersecurity weakness report by the US government: https://www.cisa.gov/uscert/ics/advisor ... -22-174-01

I see that the first issue "path name injection through SOP Instance UID" has already been addressed and solved (https://support.dcmtk.org/redmine/issues/1021).

But the NULL pointer dereferencing issue ready very generic. I was not able to identify a related bug in the issue tracker. Does that affect the library at all? Or is it just related to the executable tools? Are there any plans to address this issue? Is there test data available to reproduce it? Can the DCMTK-community help in solving this?

Sorry for the many questions ;-)

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: Cybersecurity issues reported for DCMTK

#2 Post by J. Riesmeier »

Dear Markus, I guess the NULL pointer dereference refers to commit 3e996a274.

PS: We could not reference the CVE number in the commit message because it was not available at the time when we committed the changes.

Markus Sabin
Posts: 99
Joined: Tue, 2005-07-12, 13:50
Location: Erlangen, Germany

Re: Cybersecurity issues reported for DCMTK

#3 Post by Markus Sabin »

Wow, thanks a lot for the swift response Jörg. Great that it is already solved and the impact is so limited.

Markus Sabin
Posts: 99
Joined: Tue, 2005-07-12, 13:50
Location: Erlangen, Germany

Re: Cybersecurity issues reported for DCMTK

#4 Post by Markus Sabin »

Me again.

I am currently writing an impact analysis for the mentioned items. And partially, I question the conclusions made by the CISA.

CVE-2022-2119 - "this could allow code execution"
How that?
I mean, the scenario is probably that an SOP Instance UID reading e.g. "../../../windows/system32/ws2_32.dll". Usually (and for the storescp executable by default) the received data set is written to a DICOM Part 10 file. That is, the malicious code sent with the C-STORE RQ would be preceded by a preamble. Such a file cannot be executed.
I do see that it is possible to configure the Storage SCP to just write the dataset, but this comes with unbearable downsides in practical scenarios (i.e. the Transfer Syntax is unknown). But I would rather see the impact in damaging files in the system of the receiver than in "executing code".

CVE-2022-2120 - "this could allow code execution"
This is a bit of a mystery to me. First, because a Storage SCU only reads and transfers the files, I do not understand what "execution" could refer to. Does this refer to the receiver (SCP) side when the SCU unintentionally transfers files outside the specified folder? However, this would be a really great fake DICOM file because the SCU will be unable to transfer it if particular DICOM attributes (SOP Class/Instance UID) are not present, which in turn requires a DICOM encoding of the malicious file at least up to the tag (0008,0018).
Second, I do not see any option to have the Storage SCU to obtain paths from anything but the command line. So if it was not explicitly instructed to recurse, it won't do so. And even if recusion is enabled and a softlink points to a directory which is not a sub-directory of the one to send the files from - why is this seen as an issue of the Storage SCU? If this was the user's intention -> fine. If not, then the system was attacked prior to sending files with the storescu.

Just want to make sure that I am not missing a relevant scenario here.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: Cybersecurity issues reported for DCMTK

#5 Post by J. Riesmeier »

Most reports that we get from security researchers describe somewhat unusual cases, i.e. not those that a typical user will ever get in touch with. Quite often these reports are about invalid DICOM datasets, illegal DICOM network communication or missing input validation. Quite often, the reporters have used a technique called "fuzzing" (fuzzy testing).

If I remember correctly, the "attack vector" was that the storescp typically creates filenames based on the value of the SOP Instance UID without validating this value.
Second, I do not see any option to have the Storage SCU to obtain paths from anything but the command line. So if it was not explicitly instructed to recurse, it won't do so. And even if recusion is enabled and a softlink points to a directory which is not a sub-directory of the one to send the files from - why is this seen as an issue of the Storage SCU? If this was the user's intention -> fine. If not, then the system was attacked prior to sending files with the storescu.
The "user's intention" is usually also my point when missing input validation is reported, such as in commit dbe6898efe. But, of course, we always try to find a solution when a "security issue" is reported; even if it is quite unlikely that some of these issues will ever cause any harm.

PS: Maybe, Marco can also comment on this, since he often considers the reported problems as more critical than I do, e.g. when the content of a readable file (such as "/etc/passwd") is copied by dump2dcm or xml2dcm to a DICOM file/dataset, which in my opinion is not a problem of the DCMTK tool, but of the user who started the tool.

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1437
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

Re: Cybersecurity issues reported for DCMTK

#6 Post by Marco Eichelberg »

Sorry for the late reply. The attack vector was indeed that a malicious attacker could send a DICOM image with an invalid SOP Instance UID, which would be used as part of a filename.
Under certain conditions (including something like "../../../../" in the UID) storescp can be manipulated to store the DICOM file in the wrong directory.

Now, if the attacker knows the directory structure of the server, and that server also contains a webserver, and the process running storescp has write access to a directory containing PHP scripts for that webserver and the attacker knows which URL causes which PHP script to be executed, then the attacker might be able to cause storescp to overwrite one of the PHP scripts with a DICOM file, and then connect to the webserver and request a certain page, triggering execution of the DICOM file by the PHP interpreter.

Furthermore, it is possible to write a valid DICOM file that contains PHP script code in some attribute (e.g. in a private tag), and make the PHP interpreter execute that file. PHP will then discard all bytes preceding the "magic word" for PHP code, and then happily start executing code inside a DICOM file...

As you see, there are many preconditions (including inappropriate access right configuration) and one could argue that PHP is at least half of the problem, but this is the "potential code execution" scenario.

Markus Sabin
Posts: 99
Joined: Tue, 2005-07-12, 13:50
Location: Erlangen, Germany

Re: Cybersecurity issues reported for DCMTK

#7 Post by Markus Sabin »

Hi Marco,

sorry for the late thanks - so here it comes: Thanks a lot for these details. With all the "ifs" and "ands", it is not surprising that not exploit yet exists.

Great that you fiexed it quickly anyway.

Best Regards,

Markus

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 1 guest