3 ms·

Caution, CVS-2021-22205 has later been found to be exploitable without authentication. No need to be "able to upload an image," unfortunately. Also no need to t

Caution, CVS-2021-22205 has later been found to be exploitable without authentication. No need to be "able to upload an image," unfortunately. Also no need to take the detour through a mirrored repo as sibling suggests; so long as the GitLab instance is accessible from the internet.

morelisp 5y ago
> exploitable without authentication Can you provide more info? I skimmed the upstream ticket but didn't see how. Getting access to anything other than the login page on an accessible-but-private instance seems like a security bug regardless of this CVE.
- albinolobster 5y ago
  Full disclosure, I wrote both of these. The following describes the entire unauthenticated attack: https://attackerkb.com/topics/D41jRUXCiJ/cve-2021-22205/rapid7-analysis https://attackerkb.com/topics/D41jRUXCiJ/cve-2021-22205/rapi... And, if you like that sort of thing, there is a metasploit module you can use to reproduce the unauthenticated attack: https://github.com/rapid7/metasploit-framework/commit/6f4aa550225f796b7e6411e5d047a79318b95f25 https://github.com/rapid7/metasploit-framework/commit/6f4aa5...
  - morelisp 5y ago
    > Specifically HandleFileUploads in uploads.go is called from a couple of PreAuthorizeHandler contexts allowing the HandleFileUploads logic, which calls down to rewrite.go and exif.go, to execute before authentication. I'm no security guy, but this seems... incredibly dumb? Like even for perfectly secure code, the asymmetry in resource usage alone to submit an image vs. get them to dump a file, shell out to a scanner, and rewrite that file would probably be enough to seriously hurt smaller GitLab VMs.
    - albinolobster 5y ago
      Not only that, but it still works in exactly this way. I would have thought they would have fixed this "feature." But an unauthenticated user can still provide GitLab with tiff/jpeg images and have them reach ExifTool.

morelisp 5y ago

> exploitable without authentication Can you provide more info? I skimmed the upstream ticket but didn't see how. Getting access to anything other than the login page on an accessible-but-private instance seems like a security bug regardless of this CVE.

albinolobster 5y ago
Full disclosure, I wrote both of these. The following describes the entire unauthenticated attack: https://attackerkb.com/topics/D41jRUXCiJ/cve-2021-22205/rapid7-analysis https://attackerkb.com/topics/D41jRUXCiJ/cve-2021-22205/rapi... And, if you like that sort of thing, there is a metasploit module you can use to reproduce the unauthenticated attack: https://github.com/rapid7/metasploit-framework/commit/6f4aa550225f796b7e6411e5d047a79318b95f25 https://github.com/rapid7/metasploit-framework/commit/6f4aa5...
- morelisp 5y ago
  > Specifically HandleFileUploads in uploads.go is called from a couple of PreAuthorizeHandler contexts allowing the HandleFileUploads logic, which calls down to rewrite.go and exif.go, to execute before authentication. I'm no security guy, but this seems... incredibly dumb? Like even for perfectly secure code, the asymmetry in resource usage alone to submit an image vs. get them to dump a file, shell out to a scanner, and rewrite that file would probably be enough to seriously hurt smaller GitLab VMs.
  - albinolobster 5y ago
    Not only that, but it still works in exactly this way. I would have thought they would have fixed this "feature." But an unauthenticated user can still provide GitLab with tiff/jpeg images and have them reach ExifTool.