3 ms·

I feel like this article could have been far more useful with the following points being explicitly mentioned, or at least summarized: - the problem appeared

I feel like this article could have been far more useful with the following points being explicitly mentioned, or at least summarized: - the problem appeared in GitLab 11.9.0 - the problem seems to have been fixed in GitLab 13.8.8 - the vulnerability uses ExifTool, so to exploit it, a user needs to be able to upload images - if an update is not (yet) possible, DjVu format file uploads can be blocked to avert this vulnerability - this vulnerability isn't relevant for GitLab instances that just have 1 user, or are not publicly accessible on the Internet Now, i'm not saying that the above is entirely true, but after reading something like the above, one should be able to figure out how to best act: - if you have a public GitLab instance with open registrations, consider updating it immediately (with backups in place, of course) - if you have a private GitLab instance with many users in your own corporate network (that somehow isn't updated yet) - this is a good reason to put updating it into your agenda today, even if your users aren't necessarily hostile - if you have a private GitLab instance or one with registrations closed (e.g. you're the only user or people that you trust use it), mark this down and update whenever possible, however it's probably not necessary right this moment Of course, i can't say the above with 100% confidence, because the article itself lacks this actionable information to aid in decisionmaking and so i'm left to piece things together on my own, because of which i could be wrong. On an unrelated note, DjVu is a pretty interesting file format, though sadly i've only seen it be used very sparsely, on some Russian forums for tractor manuals or something: https://en.wikipedia.org/wiki/DjVu https://en.wikipedia.org/wiki/DjVu

morelisp 5y ago
> the vulnerability uses ExifTool, so to exploit it, a user needs to be able to upload images... this vulnerability isn't relevant for GitLab instances that just have 1 user, or are not publicly accessible on the Internet A lot of private GitLabs contain mirrors of public repositories or vendored copies of public libraries. Our GitLab is private but practically speaking there's probably several hundred people, most of whom we couldn't identify, that could "upload an image" to it.
mjochim 5y ago
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.
deepsun 5y ago
In Eastern Europe professors share scanned books/papers mostly in .djvu format.
- aasasd 5y ago
  Which afaik amounts in that case to a bunch of grayscale JPEGs. Dunno about other cases, but I've never seen a djvu with extra capabilities besides raster images of the pages.
  - deepsun 5y ago
    Just checked my backups. Wildly popular Skanavi books [1] have copy-pasteable text, so they OCRed it. https://www.amazon.com/Problems-Mathematics-education-institution-matematike/dp/5488024662 https://www.amazon.com/Problems-Mathematics-education-instit...
magicalhippo 5y ago
> if an update is not (yet) possible, DjVu format file uploads can be blocked to avert this vulnerability Note that the issue was enabled by GitLab not verify the file format, ie that a .jpg is a JPEG and not a DjVu file for example, before handing it over to ExifTool. So a simple extension/mime check won't cut it.
- morelisp 5y ago
  Nor should they rely on their verification of the file format for anything other than a temporary mitigation of this specific bug! If the ExifToof / DjVu tooling itself isn't secured or sandboxed, this would be a future exploit waiting to happen.
  - magicalhippo 5y ago
    Absolutely. To be honest I was a bit shocked they used an ExifTool binary that had anything but JPEG/TIFF support compiled in.
thepill 5y ago
How do you check if you have been compromised? I did apply the patch a few days after it was released, but im unsure if the system has been compromised....
- john_cogs 5y ago
  GitLab team member here. Please see this post on the GitLab forum for details how you can determine if your instance has been compromised through the exploitation of CVE-2021-22205: https://forum.gitlab.com/t/cve-2021-22205-how-to-determine-if-a-self-managed-instance-has-been-impacted/60918/3 https://forum.gitlab.com/t/cve-2021-22205-how-to-determine-i...
w1nk 5y ago
Given the creators, I'd guess the format is also used in certain machine learning circles as well (or was meant to be at least :)).

morelisp 5y ago

> the vulnerability uses ExifTool, so to exploit it, a user needs to be able to upload images... this vulnerability isn't relevant for GitLab instances that just have 1 user, or are not publicly accessible on the Internet A lot of private GitLabs contain mirrors of public repositories or vendored copies of public libraries. Our GitLab is private but practically speaking there's probably several hundred people, most of whom we couldn't identify, that could "upload an image" to it.

mjochim 5y ago

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.

deepsun 5y ago

In Eastern Europe professors share scanned books/papers mostly in .djvu format.

aasasd 5y ago
Which afaik amounts in that case to a bunch of grayscale JPEGs. Dunno about other cases, but I've never seen a djvu with extra capabilities besides raster images of the pages.
- deepsun 5y ago
  Just checked my backups. Wildly popular Skanavi books [1] have copy-pasteable text, so they OCRed it. https://www.amazon.com/Problems-Mathematics-education-institution-matematike/dp/5488024662 https://www.amazon.com/Problems-Mathematics-education-instit...

magicalhippo 5y ago

> if an update is not (yet) possible, DjVu format file uploads can be blocked to avert this vulnerability Note that the issue was enabled by GitLab not verify the file format, ie that a .jpg is a JPEG and not a DjVu file for example, before handing it over to ExifTool. So a simple extension/mime check won't cut it.

morelisp 5y ago
Nor should they rely on their verification of the file format for anything other than a temporary mitigation of this specific bug! If the ExifToof / DjVu tooling itself isn't secured or sandboxed, this would be a future exploit waiting to happen.
- magicalhippo 5y ago
  Absolutely. To be honest I was a bit shocked they used an ExifTool binary that had anything but JPEG/TIFF support compiled in.

thepill 5y ago

How do you check if you have been compromised? I did apply the patch a few days after it was released, but im unsure if the system has been compromised....

john_cogs 5y ago
GitLab team member here. Please see this post on the GitLab forum for details how you can determine if your instance has been compromised through the exploitation of CVE-2021-22205: https://forum.gitlab.com/t/cve-2021-22205-how-to-determine-if-a-self-managed-instance-has-been-impacted/60918/3 https://forum.gitlab.com/t/cve-2021-22205-how-to-determine-i...

w1nk 5y ago

Given the creators, I'd guess the format is also used in certain machine learning circles as well (or was meant to be at least :)).