Skip to content

πŸ›‘οΈ Sentinel: [HIGH] Fix insecure temporary file creation#49

Closed
himattm wants to merge 1 commit intomainfrom
sentinel/insecure-temp-file-1521368908011730218
Closed

πŸ›‘οΈ Sentinel: [HIGH] Fix insecure temporary file creation#49
himattm wants to merge 1 commit intomainfrom
sentinel/insecure-temp-file-1521368908011730218

Conversation

@himattm
Copy link
Copy Markdown
Owner

@himattm himattm commented Apr 16, 2026

🚨 Severity: HIGH
πŸ’‘ Vulnerability: Predictable temporary file names were used with os.WriteFile in shared directories like /tmp.
🎯 Impact: This allowed symlink attacks where a malicious user could pre-create a predictable symlink. os.WriteFile would follow the symlink and overwrite arbitrary files with the privileges of the user running Prism.
πŸ”§ Fix: Replaced os.WriteFile with os.CreateTemp, which uses O_EXCL flag to ensure the temporary file does not exist, effectively mitigating symlink attacks. The temporary files are generated in the same target directory and closed before os.Rename. Also documented in .jules/sentinel.md.
βœ… Verification: Ran go test ./... and go build ./... which both completed successfully. Review approved the logic as "rock-solid and production-ready."


PR created automatically by Jules for task 1521368908011730218 started by @himattm

Vulnerability: Predictable temporary file names (`path + ".tmp"`) were
being used with `os.WriteFile` in `os.TempDir()` (a shared directory)
to perform atomic file writes.

Impact: A local attacker could launch a symlink attack by pre-creating
the predictable `.tmp` file as a symlink pointing to an arbitrary file.
When Prism runs and `os.WriteFile` executes, it follows the symlink,
potentially overwriting the arbitrary file with Prism's cache data using
the application user's privileges.

Fix: Replaced `os.WriteFile` with `os.CreateTemp`, which correctly passes
the `O_EXCL` flag when opening the file. This ensures the temporary
file does not already exist, mitigating the symlink attack. We also create
the file in the same directory as the target path to ensure `os.Rename`
won't fail due to moving across filesystems. The temporary file is properly
closed before calling `os.Rename` to avoid open-file locking errors.

Co-authored-by: himattm <6266621+himattm@users.noreply.github.com>
@google-labs-jules
Copy link
Copy Markdown
Contributor

πŸ‘‹ Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a πŸ‘€ emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request addresses a security vulnerability involving insecure temporary file creation by replacing predictable file names with os.CreateTemp in internal/burnrate/burnrate.go and internal/sparkline/sparkline.go. It also adds a sentinel document to track and prevent this vulnerability in the future. Feedback was provided to improve the robustness of the file-writing logic by using tmpFile.Sync() for data durability and defer os.Remove() to simplify cleanup and error handling.

Comment on lines +147 to +166
tmp := tmpFile.Name()

if _, err := tmpFile.Write(data); err != nil {
tmpFile.Close()
os.Remove(tmp)
return
}
if err := tmpFile.Close(); err != nil {
os.Remove(tmp)
return
}

if err := os.Chmod(tmp, 0644); err != nil {
os.Remove(tmp)
return
}
os.Rename(tmp, path)

if err := os.Rename(tmp, path); err != nil {
os.Remove(tmp)
}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Similar to the changes in burnrate.go, consider using tmpFile.Sync() for durability and defer os.Remove(tmp) to simplify the cleanup logic. This makes the atomic write process more robust.

	tmp := tmpFile.Name()
	defer os.Remove(tmp)

	if _, err := tmpFile.Write(data); err != nil {
		tmpFile.Close()
		return
	}
	if err := tmpFile.Sync(); err != nil {
		tmpFile.Close()
		return
	}
	if err := tmpFile.Close(); err != nil {
		return
	}

	if err := os.Chmod(tmp, 0644); err != nil {
		return
	}

	if err := os.Rename(tmp, path); err != nil {
		return
	}

@himattm
Copy link
Copy Markdown
Owner Author

himattm commented May 7, 2026

Closing as superseded by direct commit 42f3149 on main, which consolidated the burnrate/sparkline predictable-temp-file fixes and also preserved PR #82's updater temp-file hardening without the generated .jules note.

@himattm himattm closed this May 7, 2026
@himattm himattm deleted the sentinel/insecure-temp-file-1521368908011730218 branch May 7, 2026 15:36
@google-labs-jules
Copy link
Copy Markdown
Contributor

Closing as superseded by direct commit 42f3149 on main, which consolidated the burnrate/sparkline predictable-temp-file fixes and also preserved PR #82's updater temp-file hardening without the generated .jules note.

Understood. Acknowledging that this work is now superseded by the direct commit on main and stopping work on this task.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant