Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitlab servers are being exploited in DDoS attacks

therecord.media

Post reply on HN
Print view View original

141–150 of 177 posts

Re: Gitlab servers are being exploited in DDoS attacks

#141

Post by sebcat »

leejo wrote: post #136
majou wrote: post #69

Earlier quoted context omitted.

2014 was very much that era, I'd accept this excuse maybe for 2007

The comment in the code slightly above says: this doesn't work in perl 5.6.2! grrrr So this code is at least 20 years old, and probably pre-2000.

https://exiftool.org/ancient_history.html

    Sept. 26, 2008 - Version 7.44
           - Added read support for DjVu images
There were probably enough systems running perl 5.6.2 around 2008 to cause bug reports, or the code was migrated from an older piece of code and added to ExifTool.

It was not uncommon to manually ./configure, make, make install tarballs locally in those days, especially not on systems like Slackware so I can see it being possible to have old packages installed that were not automagically updated.

Re: Gitlab servers are being exploited in DDoS attacks

#144

Post by deepsun »

KronisLV wrote: post #130

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 vul…

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

Re: Gitlab servers are being exploited in DDoS attacks

#145

Post by jrockway »

ignoramous wrote: post #24
codegeek wrote: 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.

> uploads for DjVu file format used for scanned documents to gain control over the entire underlying GitLab web server A usecase for WASM's nanoprocesses (capability-based security) perhaps? Of course, until such a time someone exploits the WASM runtime itself.

I really like the idea of using WASM for application "plugins". You can pick your implementation language, and with the right runtime, it can be speedy and secure. Seems like a win.

The blockers, to me, right now are:

1) I mostly write Go, and the Go runtimes didn't seem to be particularly maintained when I last looked. So it just hasn't been worth it to me to do plugins. (I have done "provide your own code to a Go application" before -- "gojq" and "expr" got the job done. Less features than a full WASM runtime, but still pretty powerful.)

2) It's unclear to me which programming language APIs should target. You add a plugin system and you want developers to use it -- what are the popular languages that target WASM? Go and Tinygo look great here, but I have a feeling that the average programmer wants something a little more dynamic for their small plugins. AssemblyScript obviously wants to be the standard, but it's probably too different from Typescript to make it a no-brainer for Javascript developers. Some sort of Perl/Python/Ruby that compiles to WASM would be great, but I haven't seen much progress on that front.

As for running untrusted code in general, I don't think WASM needs to block you. gVisor simulates the linux kernel for containers, providing stronger isolation between them, and is designed to protect you from things like this. (I think the original usecase was running ffmpeg to transcode user-provided video files?) And you can always go full VM on these things. Or take the nuclear option -- carefully audit the untrusted code and build up that trust ;)

Re: Gitlab servers are being exploited in DDoS attacks

#146

Post by magicalhippo »

KronisLV wrote: post #130

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 vul…

> 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.

Re: Gitlab servers are being exploited in DDoS attacks

#147

Post by niros_valtos »

beefield wrote: post #125
Jach wrote: 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.

Okay, I'll bite. I have known for a long time that eval is evil. Then, last year I actually needed to evaluate a string (from a file). As the case was safe enough (input 100% controlled by me), I did not worry too much and just used eval. But what would be a safe way to evaluate things if you needed to do that in unsafe environment? Say, you would like to make a safe website that allows user type a python code snippe…

If the user is trusted but the environment isn’t, the user can sign the string and you can validate it pre execution. If the user is not trusted, you need to contain the execution as much as possible, e.g. container without file or network access to your resources. If there is a need to access specific resource, white list it.

Re: Gitlab servers are being exploited in DDoS attacks

#148

Post by PLG88 »

lemoncucumber wrote: post #134
nl wrote: post #129

Earlier quoted context omitted.

This is a bad solution. Lambda allows arbitraty network access and may allow access to your AWS resources. If you have to do this, the best approach is to containerise it, use capabilities to enforce restrictions and run in a virtual machine as isolated as possible. It's still not great though. Some languages (eg Java) have additional features that help with this though.

Yes, I was simplifying — the important part is keeping the untrusted code off of a trusted network. If you want to do the legwork of carefully segregating things then of course network access can work. I didn’t mention containers since they don’t provide strong isolation and some people misuse them as though they do. There’s no harm in using them as another layer of defense, but hardware virtualization provides much…

Why not just not trust the network or host at all. Put private connectivity inside trusted code using an SDK. Then the trusted apps can only communicate to devices/apps defined and nothing else. Untrusted code cannot access the trusted network as the network is acutally inside the apps/system.

Re: Gitlab servers are being exploited in DDoS attacks

#149

Post by PLG88 »

tfigment wrote: post #110
relaunched wrote: post #96

Earlier quoted context omitted.

The number of software products, SaaS and on-prem, that don't support mutual tls is a disgrace.

I frequently do mTLS with a reverse proxy (httpd, nginx, caddy, ...). Not perfect but you can tighten the connection security a lot without touching the other service. But by outsourcing it you lose some control.

We put all our DevOps tools behind Open Ziti (ziti.dev) which ensures we do not need any public IPs (unlike a VPN or bastion) while giving granular access control for only trusted users.

Re: Gitlab servers are being exploited in DDoS attacks

#150

Post by thepill »

KronisLV wrote: post #130

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 vul…

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....
Post reply on HN