T09 · Insecure Skill Coding Practices
- Location
utils.js:58- Finding
Unbounded PNG Chunk Parsing Enables Denial of Service
- Content
View full analysis
Vulnerability Details
File Location:
utils.js, lines 58–70
Vulnerability Type: Improper validation of attacker-controlled PNG chunk length
Risk Level: MediumVulnerable Code
javascript // Read chunk length (4 bytes, big-endian) if (offset + 8 > buffer.length) break; const length = buffer.readUInt32BE(offset); offset += 4; // Read chunk type (4 bytes) const type = buffer.toString('ascii', offset, offset + 4); offset += 4; // Check whether this is a text chunk if (type === 'tEXt' || type === 'iTXt') { // Read the null-terminated keyword let keywordEnd = offset; while (keywordEnd < offset + length && buffer[keywordEnd] !== 0) { keywordEnd++; }Technical Analysis
The PNG chunk length is read directly from an untrusted file. The parser does not verify that the declared
lengthfits within the bytes remaining in the buffer, nor does it impose a reasonable maximum text-chunk size.For a
tEXtoriTXtchunk, the keyword loop is bounded byoffset + lengthbut not bybuffer.length. OncekeywordEndexceeds the physical buffer,buffer[keywordEnd]evaluates toundefined, which remains unequal to zero. The loop can therefore continue until it reaches the attacker-controlled declared chunk boundary.A crafted chunk length approaching
0xffffffffmay cause billions of synchronous loop iterations. Because character-card files are loaded using synchronous file access and parsed on the main Node.js thread, exploitation can block the process and deny service to other operations.The parser also advances with
offset += length + 4without first establishing that the complete chunk data and CRC are present. The primary demonstrated security consequence is CPU exhaustion during keyword scanning.Attack Path
- The attacker constructs a file with a valid eight-byte PNG signature.
- The file contains a chunk whose type is
tEXtoriTXt. - The chunk length field is set to a very large value, such as one near ...[truncated 968 chars]
- Remediation
View remediation
Remediation Suggestions
Validate every chunk before inspecting its content:
- Calculate the chunk-data start and end with arithmetic that cannot silently exceed the buffer boundary.
- Require the complete chunk data and four-byte CRC to be present.
- Reject chunks whose declared size exceeds the remaining bytes.
- Enforce a conservative maximum size for textual character-card chunks.
- Bound keyword scanning by both the validated chunk end and
buffer.length. - Require a null terminator before decoding the keyword.
- Consider validating chunk CRC values and PNG chunk ordering.
- Apply an overall input-file size limit before reading or parsing the file.
- Avoid long synchronous parsing on a shared event-loop thread; use asynchronous processing or an isolated worker where practical.
Example hardening pattern:
javascript const MAX_TEXT_CHUNK_SIZE = 10 * 1024 * 1024; if (offset + 8 > buffer.length) { throw new Error('Truncated PNG chunk header'); } const length = buffer.readUInt32BE(offset); offset += 4; const type = buffer.toString('ascii', offset, offset + 4); offset += 4; if (length > MAX_TEXT_CHUNK_SIZE && (type === 'tEXt' || type === 'iTXt')) { throw new Error('PNG text chunk exceeds the permitted size'); } const chunkEnd = offset + length; const crcEnd = chunkEnd + 4; if (!Number.isSafeInteger(chunkEnd) || crcEnd > buffer.length) { throw new Error('PNG chunk length exceeds the available input'); } if (type === 'tEXt' || type === 'iTXt') { let keywordEnd = offset; while (keywordEnd < chunkEnd && buffer[keywordEnd] !== 0) { keywordEnd++; } if (keywordEnd === chunkEnd) { throw new Error('PNG text chunk has no keyword terminator'); } // Continue parsing only within [offset, chunkEnd). }