Skip to content

πŸ›‘οΈ Sentinel: [CRITICAL] Fix predictable temp file symlink attack in atomic file writes#69

Closed
himattm wants to merge 1 commit intomainfrom
sentinel/fix-symlink-attack-13382186907770207822
Closed

πŸ›‘οΈ Sentinel: [CRITICAL] Fix predictable temp file symlink attack in atomic file writes#69
himattm wants to merge 1 commit intomainfrom
sentinel/fix-symlink-attack-13382186907770207822

Conversation

@himattm
Copy link
Copy Markdown
Owner

@himattm himattm commented Apr 26, 2026

🚨 Severity: CRITICAL
πŸ’‘ Vulnerability: Predictable temporary files were created in a shared directory (os.TempDir()), allowing for a local symlink attack to overwrite arbitrary files.
🎯 Impact: An attacker could exploit this vulnerability to escalate privileges or corrupt sensitive system files running with the privileges of the executing user.
πŸ”§ Fix: Replaced uses of os.WriteFile to intermediate, predictably named files in internal/burnrate/burnrate.go and internal/sparkline/sparkline.go with os.CreateTemp which safely generates unique, unpredictable temporary files. Addressed file closure, renaming logic, and permission inheritance correctly. Added .jules/sentinel.md journal entry with findings.
βœ… Verification: Ran go test ./... successfully and verified correct functionality without symlink issues. All os.WriteFile calls used for this purpose were removed from the program.


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

…ties

Replaced uses of `os.WriteFile` with a predictable temporary filename `path + ".tmp"` in `os.TempDir()` with `os.CreateTemp` to generate unpredictable temporary files for atomic writes.

This mitigates a classic symlink attack where an attacker could overwrite arbitrary files with the privileges of the user running the program.

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 related to predictable temporary file names by implementing os.CreateTemp in internal/burnrate/burnrate.go and internal/sparkline/sparkline.go. The changes also include documentation of the vulnerability in a new sentinel file. Feedback was provided to improve the reliability of these atomic writes by suggesting the use of f.Sync() and proper error handling for f.Close() to ensure data is fully flushed to disk before the final rename operation.

Comment on lines +73 to +79
if _, err := f.Write(data); err != nil {
f.Close()
os.Remove(tmpPath)
return nil, false, err
}
f.Chmod(0644)
f.Close()
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

To ensure the atomic write is durable and complete, it is recommended to call f.Sync() before closing the file, and to check the error returned by f.Close(). If f.Close() fails, it may indicate that the data was not successfully flushed to disk, and the subsequent os.Rename could result in a corrupted or incomplete file.

	if _, err := f.Write(data); err != nil {
		f.Close()
		os.Remove(tmpPath)
		return nil, false, err
	}
	if err := f.Sync(); err != nil {
		f.Close()
		os.Remove(tmpPath)
		return nil, false, err
	}
	if err := f.Chmod(0644); err != nil {
		f.Close()
		os.Remove(tmpPath)
		return nil, false, err
	}
	if err := f.Close(); err != nil {
		os.Remove(tmpPath)
		return nil, false, err
	}

Comment on lines +146 to +152
if _, err := f.Write(data); err != nil {
f.Close()
os.Remove(tmp)
return
}
os.Rename(tmp, path)
f.Chmod(0644)
f.Close()
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

Consider adding f.Sync() and checking the error from f.Close() to ensure data durability and integrity before renaming the temporary file. This ensures that the file is fully written to disk before it replaces the target file.

	if _, err := f.Write(data); err != nil {
		f.Close()
		os.Remove(tmp)
		return
	}
	if err := f.Sync(); err != nil {
		f.Close()
		os.Remove(tmp)
		return
	}
	if err := f.Chmod(0644); err != nil {
		f.Close()
		os.Remove(tmp)
		return
	}
	if err := f.Close(); err != nil {
		os.Remove(tmp)
		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/fix-symlink-attack-13382186907770207822 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 work is now obsolete 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