fix(windows): resolve absolute path for taskkill to prevent hijacking#617
Conversation
Using unqualified taskkill / taskkill.exe commands on Windows can allow binary hijacking under certain conditions. Update all process termination callers on Windows to resolve the absolute path to taskkill.exe under System32 (referencing SystemRoot/windir environment variables, falling back to C:\Windows).
|
Warning Review limit reached
Next review available in: 37 minutes Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
anandh8x
left a comment
There was a problem hiding this comment.
LGTM.
Bare taskkill on PATH is a real hijack surface for force-kill paths. Pinning System32\taskkill.exe via SystemRoot/windir/C:\Windows is the right hardening. All three Windows terminate sites covered. All CI green. Ship it.
Nit (non-blocking): taskkillPath is duplicated in three packages; a shared helper can come later.
gnanam1990
left a comment
There was a problem hiding this comment.
Review
Verdict: Approve with notes (independent pass; not previously reviewed by me; agree with @anandh8x).
Bare taskkill / taskkill.exe on PATH is a real Windows hijack surface on force-kill paths. Pinning System32\taskkill.exe via SystemRoot → windir → C:\Windows is the right hardening. All three call sites (background, config, tools) are covered; no other taskkill usages remain in tree. CI green including windows-latest; packages compile under GOOS=windows.
Notes (non-blocking)
- Residual: poisoned
SystemRoot/windircan still redirect the join; tighter option isGetSystemDirectoryand ignore env. taskkillPathis triplicated — share later.- Optional pure-function tests for env fallbacks.
- No linked issue /
issue-approved.
Ship it.
Summary
Fixes a medium-severity issue where invoking
taskkillortaskkill.exewithout an absolute path on Windows can allow binary hijacking under certain conditions.This PR ensures all process-termination paths on Windows resolve the absolute path to
taskkill.exeunderSystem32(referencingSystemRoot/windir, with a fallback toC:\Windows).Changes
internal/background/process_windows.gotaskkillPath()helper and use it to resolve absolute path oftaskkillinterminateProcess.internal/config/process_windows.gotaskkillPath()helper and use it to resolve absolute path oftaskkillinterminateCommandProcess.internal/tools/bash_proc_windows.gotaskkillPath()helper and use it to resolve absolute path oftaskkillinhardenProcessLifetimeCancel callback.Test plan
go test ./internal/background/... ./internal/config/... ./internal/tools/...— ok