Skip to content

🛡️ Sentinel: [HIGH] Fix predictable temporary filename symlink vulnerability#79

Closed
himattm wants to merge 1 commit intomainfrom
sentinel-predictable-tmp-files-fix-16030452542455674753
Closed

🛡️ Sentinel: [HIGH] Fix predictable temporary filename symlink vulnerability#79
himattm wants to merge 1 commit intomainfrom
sentinel-predictable-tmp-files-fix-16030452542455674753

Conversation

@himattm
Copy link
Copy Markdown
Owner

@himattm himattm commented May 1, 2026

🚨 Severity: HIGH
💡 Vulnerability: Predictable temporary files were being created using hardcoded extensions (e.g. path + ".tmp") when performing atomic file writes in internal/burnrate/burnrate.go and internal/sparkline/sparkline.go. If these files reside in a shared directory (like /tmp), an attacker could pre-create a symlink with the predictable filename pointing to an arbitrary file. When the application runs, it would overwrite the target of the symlink.
🎯 Impact: Potential arbitrary file overwrite.
🔧 Fix: Replaced the predictable path + ".tmp" logic with os.CreateTemp generated filenames inside the target directory, followed by explicit permission settings using f.Chmod() before completing the os.Rename().
Verification: Ran go test ./... and go fmt ./.... Confirmed the implementation matches best practices for secure atomic writes in Go. Added a critical learning entry to .jules/sentinel.md.


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

Replaced predictable temporary file creation in internal/burnrate and internal/sparkline using `os.WriteFile` with unpredictable temporary filenames using `os.CreateTemp` to prevent symlink attacks. Set temporary files to original permission modes. Included documentation in `.jules/sentinel.md` for learning tracking.

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 predictable temporary filename symlink vulnerability by replacing insecure file creation with os.CreateTemp and explicit file operations in internal/burnrate/burnrate.go and internal/sparkline/sparkline.go. It also adds a sentinel document explaining the vulnerability and its prevention. Feedback was provided regarding the lack of error handling for os.Rename in internal/sparkline/sparkline.go, which could result in leaked temporary files if the operation fails.

return
}

os.Rename(tmp, path)
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

The error from os.Rename is ignored, which can lead to temporary files being leaked in the filesystem if the rename operation fails (e.g., due to permission issues on the target file). Additionally, the function will silently fail to update the persistent storage while the in-memory cache has already been updated. It is recommended to handle the error and ensure the temporary file is removed on failure.

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

@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-predictable-tmp-files-fix-16030452542455674753 branch May 7, 2026 15:35
@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 PR has been superseded and the work is consolidated on main. 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