Fix panic when reconstructing Dockerfile from malformed image history#191
Conversation
…tory The HEALTHCHECK/ENTRYPOINT/CMD reverse-engineering code indexes the results of strings.SplitN without checking their length, so a malformed value in an image's layer history makes it panic. There is no recover() around it, so a single bad instruction aborts the whole xray/build/profile run. Bounds-check the slice accesses in deserialiseHealtheckInstruction and fixJSONArray, and return an error for malformed HEALTHCHECK values so the caller skips the instruction instead of crashing. Signed-off-by: 0xVijay <53905346+0xVijay@users.noreply.github.com>
|
auggie review |
🤖 Augment PR SummarySummary: Prevents crashes when reconstructing a Dockerfile from images with malformed history entries. Changes:
Technical Notes: Malformed inputs now return errors instead of panicking, allowing callers to continue processing other history layers. 🤖 Was this summary useful? React with 👍 or 👎 |
| //Splits the string into two parts - first part pointer to array of string and rest of the string with } in end. | ||
| instParts := strings.SplitN(cleanInst, "]", 2) | ||
| if len(instParts) < 2 { | ||
| return strTest, &config, fmt.Errorf("malformed HEALTHCHECK instruction: %q", data) |
There was a problem hiding this comment.
deserialiseHealtheckInstruction now returns an error here but still returns strTest (often empty) as the reconstructed instruction; upstream code currently assigns the returned string even when err != nil, which can silently drop the original HEALTHCHECK line and emit a blank/invalid Dockerfile line instead of “skipping”.
Severity: medium
Other Locations
pkg/docker/dockerfile/reverse/reverse.go:819
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
What
The code that rebuilds a Dockerfile from image history (
reverse.go) indexes the result ofstrings.SplitNforHEALTHCHECK,ENTRYPOINTandCMDwithout checking the length. A malformed value in a layer'sCreatedByhistory makes it panic, for example:There is no
recover()around this, so one bad instruction aborts the wholexray,buildorprofilerun.Why
mintis often pointed at images it did not build (xray/buildon pulled images, CI pipelines). A single image with malformed history metadata should not crash the tool.xraydoes not even run the target app, so the history alone is enough to trigger it.How Tested
Added
TestHealthCheckMalformedandTestDockerfileFromHistoryDataMalformedwhich feed the malformed values above and assert the parser returns an error instead of panicking. ExistingTestHealthCheckstill passes.