Live data from Hacker News

Gitlab servers are being exploited in DDoS attacks

therecord.media

41–50 of 177 posts

Re: Gitlab servers are being exploited in DDoS attacks

#42
post #3

"..Bowling said he discovered a way to abuse how ExifTool handles uploads for DjVu file format used for scanned documents to gain control over the entire underlying GitLab web server" Ah, the good old "File upload vulnerability". File uploads remain one of the hardest problems to solve when it comes to security.

> File uploads remain one of the hardest problems to solve when it comes to security. Why? It seems like they should have read/write but no execute. What goes wrong?

You essentially have a gateway into a very large chunk of code that was most likely not built with security in mind on the parsing side, on top of that you are guaranteed write access to some file system.

Re: Gitlab servers are being exploited in DDoS attacks

#43
post #36

> GitLab Workhorse could check if the file is a valid TIFF of JPEG before passing it to ExifTool This approach doesn't work in general. An attacker could craft a polyglot file - and in that case it's a matter of which format is tried first. Valid tiff's could potentially be processed as something entirely different.

Yup. PoC||GTFO article (one of many, IIRC) on crafting a polyglot PDF / JPEG file:

https://github.com/angea/pocorgtfo/blob/master/contents/arti...

Re: Gitlab servers are being exploited in DDoS attacks

#44

From the issue report[1] comments: > Thanks in no small part to your recent findings, [GitLab] are rolling back our policy about paying half-bounties for third party findings. These have great impact on GitLab and we want to continue to incentivize research for high+ severity issues in that area. At least they're taking these things a bit more seriously now. [1]: https://hackerone.com/reports/1154542

Anyone have background on what a "third party finding" is? Are they talking about dependencies? Because, to me, this specific bug is both a first AND third party issue (e.g. GitLab not pre-verifying before calling ExifTool).

Re: Gitlab servers are being exploited in DDoS attacks

#45
TLDR; A vulnerability in GitLab that was patched on April 14, 2021 is now being exploited to hack into self-managed servers that are accessible through the internet.

For more context see https://about.gitlab.com/blog/2021/11/04/action-needed-in-re... If you are using GitLab.com you are not affected.

Re: Gitlab servers are being exploited in DDoS attacks

#46

How can you protect yourself from file upload threats? It's basically the worst possible threat model -- executing complex user input that conforms to a spec that was written 20 years ago by some proprietary company with no security. Executing everything on an isolated container with no permissions? Audit trial etc/good logging? If someone comes up with an RCE you're basically done for, you can only mitigate it but n…

If you have to process it at all, do it in a WebAssembly sandbox on the server. Or, alternatively, in a seccomp-secured sandbox that isn't allowed to make any system calls whatsoever, just read data from one file descriptor and write processed data to another.

I've seen companies use Headless Chrome and then WebAssembly to process files. You then lock down the Headless Chrome process. You're then "triple covered"; WebAssembly's limited context, JavaScript engine's limited context, and the Chrome process boundary itself.

This is obviously "expensive" though. Doesn't scale very well.

Re: Gitlab servers are being exploited in DDoS attacks

#47

How can you protect yourself from file upload threats? It's basically the worst possible threat model -- executing complex user input that conforms to a spec that was written 20 years ago by some proprietary company with no security. Executing everything on an isolated container with no permissions? Audit trial etc/good logging? If someone comes up with an RCE you're basically done for, you can only mitigate it but n…

If you must Wrangle Untrusted File Formats you should do so Safely:

https://github.com/google/wuffs

Re: Gitlab servers are being exploited in DDoS attacks

#48

From the issue report[1] comments: > Thanks in no small part to your recent findings, [GitLab] are rolling back our policy about paying half-bounties for third party findings. These have great impact on GitLab and we want to continue to incentivize research for high+ severity issues in that area. At least they're taking these things a bit more seriously now. [1]: https://hackerone.com/reports/1154542

Anyone have background on what a "third party finding" is? Are they talking about dependencies? Because, to me, this specific bug is both a first AND third party issue (e.g. GitLab not pre-verifying before calling ExifTool).

> Because, to me, this specific bug is both a first AND third party issue

Seems GitLab agreed on that one, they registered two CVEs:

ExifTool https://nvd.nist.gov/vuln/detail/CVE-2021-22204

GitLab https://nvd.nist.gov/vuln/detail/CVE-2021-22205

Re: Gitlab servers are being exploited in DDoS attacks

#49

This happened to all Gitlab instances that I manage around 2 days ago. Good to see publicity, I’m still dealing with not-so-understanding abuse departments at my hosting providers. Sure, my fault for not keeping it up to date. But there is much noise to filter through in the many tools we juggle these days, especially if an organization prefers to self-host.

Article said GitLab patched back in April. Safe to say you didn’t deploy these patches? No judgment. I’m paid to make things, not apply patches. This is however why I don’t use self-hosted, pros and cons, etc.

Not him, but how are you supposed to know about the update? Do you need to check some page every day if there's an update? Why can't security updates just autoupdate like apps on phones or at least email the admin saying there is an important update.

Re: Gitlab servers are being exploited in DDoS attacks

#50
post #41

It's somewhat refreshing that the underlying bug isn't from some C or C++ utility, but instead a Perl program using eval: https://github.com/exiftool/exiftool/blob/11.70/lib/Image/Ex... Another instance of "avoid eval as much as possible" for languages that have it.

Public facing?

Handles user input data??

Uses ‘eval’???

Post reply on HN