image-size Security Analysis Report

	Type	Severity	Description	File	Confidence
▶	Infinite Loop / DoS	Error	Infinite loop risk due to unvalidated entry length in ICNS parsing.	lib/types/icns.ts	9
Code Context 94 while (imageOffset < fileLength && imageOffset < inputLength) { 95 const imageHeader = readImageHeader(input, imageOffset) 96 const imageSize = getImageSize(imageHeader[0]) 97 images.push(imageSize) 98 imageOffset += imageHeader[1] 99 } Additional Details Description: Infinite loop risk due to unvalidated entry length in ICNS parsing. Exploitable: True Explanation: STEP 1 (Vulnerable function): ICNS.calculate(input) in lib/types/icns.ts lines 94-99 loops over ICNS entries and advances imageOffset by imageHeader[1] (the entry length) without validating it is positive and >= the ICNS entry header size. STEP 2 (Vulnerable parameter/variable): imageHeader[1], derived from the attacker-provided input buffer at offset imageOffset + 4 via readUInt32BE, controls loop progress. STEP 3-4 (Callers and parameter passing): The function accepts a Uint8Array input. Callers provide that buffer directly to ICNS.calculate after format validation. STEP 5 (External input sources): In typical usage, this buffer originates from untrusted file contents (e.g., uploaded ICNS files, files read from disk provided via CLI paths, or bytes received over HTTP). STEP 6 (Validation/sanitization): No validation ensures imageHeader[1] > 0 or minimally 8 bytes before incrementing imageOffset. STEP 7 (Reachability/controllability): An attacker can craft an ICNS file with an entry length of 0 (or a very small value) so imageOffset never advances while the loop condition remains true, causing an infinite loop and CPU exhaustion. Impact Assessment: Availability impact: A crafted ICNS file or byte buffer can cause an infinite loop, pegging a CPU core and potentially exhausting worker threads in services that parse untrusted images (e.g., web servers processing uploads, thumbnail generators, background jobs). No direct confidentiality or integrity impact identified, but DoS against the application/service is feasible. Attack Complexity: Low Attack Vectors: • Supply a crafted ICNS file with an entry length of 0 to any code path that calls the ICNS size calculation on untrusted input • Upload a malicious ICNS image to a web service that inspects image metadata • Provide a malicious ICNS file path to a CLI or background job that parses image sizes • Trigger automated thumbnailing or content processing pipelines that parse ICNS data from untrusted sources Remediation: Enforce forward progress and bounds checks when parsing ICNS entries: (1) After readImageHeader, validate that the entry length (imageHeader[1]) is >= 8 (minimum ICNS entry header size) and that imageOffset + imageHeader[1] <= fileLength and <= input.length. (2) Reject zero or too-small lengths by throwing an error or breaking the loop. (3) Validate fileLength: ensure fileLength >= SIZE_HEADER and fileLength <= input.length to avoid trusting a forged header. (4) Optionally cap the number of iterations or enforce a maximum file size to prevent pathological cases. Example: `const len = imageHeader[1]; if (len < 8 \|\| imageOffset + len > Math.min(fileLength, inputLength)) throw new TypeError('Invalid ICNS entry length'); imageOffset += len;` Risk Type: Insecure Design Risk Severity: high
▶	Insecure Design	Warning	Unbounded loop controlled by untrusted input (image count) enables uncontrolled resource consumption.	lib/types/ico.ts	9
Additional Details Description: Unbounded loop controlled by untrusted input (image count) enables uncontrolled resource consumption. Line Range: 57-72 Exploitable: True Explanation: STEP 1: Vulnerable function is ICO.calculate(input) in lib/types/ico.ts. It reads nbImages = readUInt16LE(input, 4) from the input buffer and uses it directly as the loop bound: for (let imageIndex = 0; imageIndex < nbImages; imageIndex += 1) { ... } without any upper limit. STEP 2: Parameters/variables that could be attacker-controlled: input (Uint8Array) and nbImages derived from it. STEP 3: Callers: Not shown in provided code; ICO is exported and intended to be called by the surrounding image type detection pipeline or directly by consumers. Within this file, calculate is the function that performs the unbounded loop. STEP 4: External input sources: Any caller that passes a Uint8Array from untrusted sources (e.g., files uploaded by users, HTTP request bodies, or other network-derived buffers) will flow into ICO.calculate. No bounds are enforced here. STEP 5: Validation/sanitization: ICO.validate() only checks reserved==0, imageCount!=0, and imageType==TYPE_ICON. It does not constrain imageCount (nbImages) nor verify that the directory size fits within input.length. Thus, an attacker can supply a large image count value that passes validate(). Conclusion: The code is reachable with attacker-controlled input in typical usage and the unbounded loop is directly controlled by nbImages, making the issue exploitable for CPU and memory exhaustion. Impact Assessment: Primary impact is denial of service. A crafted buffer with a large image count triggers excessive looping and growth of the images array, causing high CPU usage and potential memory exhaustion. Secondary risk: potential out-of-bounds reads in getImageSize if computed offsets exceed input.length, leading to exceptions and additional DoS. Attack Complexity: Low Attack Vectors: • Providing a crafted ICO/CUR buffer to any API that routes to ICO.calculate(input) • Supplying a malicious file (processed into a Uint8Array) from user uploads or other untrusted sources • Passing untrusted network data as the input buffer to image size parsing routines Remediation: Add strict bounds before iteration: (1) Enforce a sane maximum for nbImages (e.g., cap to 64 or 256) and reject larger values. (2) Verify structure size fits the buffer: SIZE_HEADER + nbImages * SIZE_IMAGE_ENTRY <= input.length. (3) In validate(), reject when imageCount exceeds the cap or directory size overflows the buffer. (4) In calculate(), iterate only after successful structural validation; optionally avoid constructing a potentially large images array or make listing images optional/limited. (5) Add bounds checks in getImageSize to prevent out-of-bounds reads. Risk Type: Insecure Design Risk Severity: high
▶	Insecure Design	Warning	Out-of-bounds read in ICO parser due to missing bounds checks on directory offsets.	lib/types/ico.ts	8
Code Context 34 function getSizeFromOffset(input: Uint8Array, offset: number): number { 35 const value = input[offset] 36 return value === 0 ? 256 : value 37 } Additional Details Description: Out-of-bounds read in ICO parser due to missing bounds checks on directory offsets. Exploitable: True Explanation: The vulnerable function getSizeFromOffset() reads input[offset] without verifying that offset is within the bounds of the provided buffer. The caller getImageSize() derives the offset using imageIndex, and ICO.calculate() supplies imageIndex values from a loop controlled by nbImages = readUInt16LE(input, 4), which is read directly from the untrusted ICO header. There is no validation that the directory table (SIZE_HEADER + nbImages * SIZE_IMAGE_ENTRY) fits within the buffer before dereferencing, permitting out-of-bounds reads and propagation of invalid sizes. Impact Assessment: Primary risks are integrity and availability: crafted ICO inputs can cause out-of-bounds reads on the Uint8Array, leading to undefined values for width/height and potential crashes or incorrect behavior in consumers (e.g., NaN propagation, exceptions). Attackers can also set nbImages to a large value, causing excessive looping and CPU usage (DoS). No direct memory disclosure beyond typed array bounds is expected in JS, but the parser can be driven into erroneous states and failures. Attack Complexity: Low Attack Vectors: • Supplying a crafted ICO buffer to the library's image size calculation API • Uploading or providing a path to a malformed ICO file that the application parses • Embedding malformed ICO data in an HTTP request body processed by the service Remediation: Enforce strict bounds checks before indexing into input: (1) In validate(), ensure input.length >= SIZE_HEADER and that the directory table fits: input.length >= SIZE_HEADER + nbImages * SIZE_IMAGE_ENTRY; (2) In calculate(), after reading nbImages, clamp iteration to the number of entries that actually fit in the buffer; (3) In getImageSize(), compute base = SIZE_HEADER + imageIndex * SIZE_IMAGE_ENTRY and verify base + 1 < input.length before calling getSizeFromOffset; (4) In getSizeFromOffset(), explicitly check 0 <= offset < input.length and throw on violations; (5) Consider capping nbImages to a reasonable maximum to prevent performance DoS. Risk Type: Insecure Design Risk Severity: high
▶	Insecure Design	Warning	GIF.validate reads 6 bytes for the GIF signature without checking input length.	lib/types/gif.ts	9
Code Context 6 validate: (input) => gifRegexp.test(toUTF8String(input, 0, 6)), Additional Details Description: GIF.validate reads 6 bytes for the GIF signature without checking input length. Explanation: STEP 1 (Vulnerable function): lib/types/gif.ts::GIF.validate calls toUTF8String(input, 0, 6) to test the GIF header without first ensuring input.length >= 6. STEP 2/3 (Callers): GIF.validate is used by the library's image-type detection path that iterates format validators before parsing. This validator is reached when consumers pass arbitrary byte arrays into the library’s public APIs for image type/size detection. STEP 4/5 (External sources): Those byte arrays typically originate from attacker-controlled inputs (e.g., HTTP file uploads handled by applications using this library, CLI processing of files, or binary data received over network/file I/O). STEP 6/7 (Sanitization/behavior): Despite the missing explicit length check, typical implementations of toUTF8String in this codebase decode a slice/subarray of the Uint8Array; decoding fewer than 6 available bytes is safe and does not read out of bounds or throw (TextDecoder.decode and Buffer.toString clamp to available data). As a result, gifRegexp.test on a shorter-decoded string simply returns false, and the validator exits. Therefore, the specific claim that this causes an out-of-bounds read/exception is not borne out in practice for this validate path. STEP 8 (Reachability): Attackers can supply short/truncated inputs that reach this code, but cannot trigger a crash via validate as implemented; the effect is a benign false negative (not identified as GIF). Impact Assessment: Availability: Low risk. The validate path is unlikely to throw on short inputs; it will return false. Confidentiality/Integrity: No impact. The worst case is misclassification or early rejection of non-GIF inputs. Attack Complexity: Low Attack Vectors: • HTTP file uploads processed by applications using the library • CLI usage or scripts passing attacker-controlled files/buffers • APIs that feed user-provided Uint8Array/Buffer data into image detection Remediation: Defensively guard fixed-length reads to make the intent explicit and future-proof: change validate to `input.length >= 6 && gifRegexp.test(toUTF8String(input, 0, 6))`. Also add similar bounds checks before width/height reads in calculate (e.g., ensure input.length >= 10 before readUInt16LE at offsets 6 and 8). Consider centralizing safe helpers that return undefined or false on short buffers. Risk Type: Insecure Design Risk Severity: low
▶	Insecure Design	Warning	GIF.calculate reads width/height at fixed offsets (6 and 8) without checking input length, enabling a denial-of-service via truncated GIF headers.	lib/types/gif.ts	9
Code Context 9 height: readUInt16LE(input, 8), 10 width: readUInt16LE(input, 6), Additional Details Description: GIF.calculate reads width/height at fixed offsets (6 and 8) without checking input length, enabling a denial-of-service via truncated GIF headers. Exploitable: True Explanation: Vulnerable function: GIF.calculate (lib/types/gif.ts). It reads two UInt16 values at offsets 6 and 8 via readUInt16LE without verifying that input has at least 10 bytes. Caller chain: lib/lookup.imageSize(input) -> detector(input) -> typeHandlers.get('gif').calculate(input). GIF.validate only checks the 6-byte signature (toUTF8String(input, 0, 6) against /^GIF8[79]a/), so a buffer containing exactly that 6-byte header will pass validate. calculate then attempts DataView reads at offsets 6 and 8, which throw RangeError on insufficient length. This is reachable with attacker-provided truncated inputs and can be used for denial-of-service. Impact Assessment: Availability impact: predictable exceptions during image parsing can crash the process or fail requests if not caught. No direct confidentiality or integrity impact identified. Attack Complexity: Low Attack Vectors: • Truncated GIF file containing only the 6-byte header provided to the CLI (bin/image-size.js) via process.argv and read from disk. • Untrusted Uint8Array passed to imageSize() from application code (e.g., reading user-controlled file bytes). • Any code path that accepts bytes from external sources and forwards them to lib/lookup.imageSize, which selects GIF and calls GIF.calculate. Remediation: Add explicit length checks before multi-byte reads in the GIF handler. Options: (1) Strengthen validate to require input.length >= 10 in addition to matching the GIF signature; or (2) Guard in calculate and return a controlled error if input.length < 10. Example: validate: (input) => input.length >= 10 && gifRegexp.test(toUTF8String(input, 0, 6)). Also consider using safe read helpers that verify bounds before DataView access and add tests for truncated inputs. Risk Type: Application Code Risk Severity: medium