Gitlab servers are being exploited in DDoS attacks
41–50 of 177 posts
Re: Gitlab servers are being exploited in DDoS attacks
#42"..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?
Re: Gitlab servers are being exploited in DDoS attacks
#43> 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.
https://github.com/angea/pocorgtfo/blob/master/contents/arti...
Re: Gitlab servers are being exploited in DDoS attacks
#44From 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
Re: Gitlab servers are being exploited in DDoS attacks
#45For 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
#46How 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.
This is obviously "expensive" though. Doesn't scale very well.
Re: Gitlab servers are being exploited in DDoS attacks
#47How 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…
Re: Gitlab servers are being exploited in DDoS attacks
#48From 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).
Seems GitLab agreed on that one, they registered two CVEs:
Re: Gitlab servers are being exploited in DDoS attacks
#49This 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.
Re: Gitlab servers are being exploited in DDoS attacks
#50It'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.
Handles user input data??
Uses ‘eval’???