Notes on Fuzz Testing¶

(First version by Marco Eichelberg)

The two main sources of "untrusted data" that DCMTK processes are:

• DICOM messages received over the networks
• DICOM files read and processed

DICOM messages¶

DICOM messages are probably the more important, but also more difficult part. The DICOM network protocol consists of several messages between client and server:

• A-ASSOCIATE-REQUEST (always the first message)
• A-ASSOCIATE-RESPONSE
• DIMSE Request 1
• DIMSE Response 1
• ...
  There are about a dozen different DIMSE messages, all in "request" and "response" versions.

Most people who have applied fuzz testing to DCMTK so far have limited themselves to the A-ASSOCIATE-REQUEST message, simply because that is the most easy part. That part should be fairly solid now. For DIMSE messages there might still be some things to find. There are various "server" applications in DCMTK that process different messages:

• storescp, dcmrecv, dcmpsrcv: receive DICOM images/documents, processes C-ECHO-RQ and C-STORE-RQ messages
  • client counterparts are storescu and dcmsend
• dcmqrscp: an image archive. Processes C-STORE-RQ, C-FIND-RQ, C-GET-RQ, C-MOVE-RQ.
  • client counterparts are findscu, movescu and getscu
• wlmscpfs: a worklist server. Processes C-FIND-RQ.
  • client counterpart is findscu
• dcmprscp: receives N-CREATE-RQ, N-SET-RQ, N-GET-RQ, N-ACTION-RQ, N-DELETE-RQ (as part of the DICOM print protocol).
  • client counterpart is dcmprscu

Essentially one would try to capture message exchanges between these tools and use that as a starting point for a fuzz testing tool. This should be relatively simple for most
DICOM services except DICOM print, because in DICOM print the UIDs are randomly generated by default, which would prevent a successful replay by a fuzz testing tool. But then the DICOM print server is probably the least important tool of the ones listed here.

Changing a few bits here and there in unexpected places in the messages might indeed trigger bugs where return codes are not properly checked or the developer did not think about a specific error situation.

DICOM Files¶

The ability to read DICOM files and to detect defective DICOM files has in my impression also already been covered quite well with fuzz testing, because it is so simple:
modify a file, run "dcmdump" on the file and see if one can produce a crash.

An area that has not been tested in depth so far is how tools that actually do something useful with an image file react to defective files:

• dcm2pnm converts DICOM images to other formats like BMP. DICOM has a rather complex image processing pipeline that is applied here.
• dcmcjpeg, dcmcrle, dcmcjpls apply image compression to an image.
• dcm2json converts a DICOM file to JSON
• dsrdump prints a DICOM structured report (SR file) after processing its structure

Probably it would be possible to trigger bugs by feeding defective files to these tools. Note that as long as one feeds uncompressed images to these tools, modifying the pixel data (which usually makes up about 99,5% of the file size) does not matter, so it is sufficient if one randomly modifies bits in the first ca. 1000 bytes of the file.

Furthermore, a very interesting case are the decompression routines in DCMTK:
One can generate compressed images using dcmcjpeg, dcmcrle, dcmcjpls and "dcmconv +td". If one then randomly modifies bits in the pixel data (i.e. the latter part of the file),
that might trigger bugs in the decompression routines, most of which were not developed by the DCMTK team, but incorporated into DCMTK. Most likely one would also find something there.