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

121–130 of 177 posts

Re: Gitlab servers are being exploited in DDoS attacks

#121

Post by Gigachad »

1vuio0pswjnm7 wrote: post #34

Seems like one solution would be to require users uploading images to remove metadata themselves before uploading. The website could reject images that contain matadata. Was Gitlab was extracting the metadata and using it for some purpose. If not, what is the reason to accept images with metadata. Perhaps they assume their customers prefer less "security" and more "convenience", instead of vice versa (less "convenien…

How do you reject an image that has metadata without doing basically exactly the same process as removing the data?

Re: Gitlab servers are being exploited in DDoS attacks

#122

Post by superjan »

xxpor wrote: post #68
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.

With dlopen() and libclang/libgccjit, you could argue C (on an OS that supports dynamic loading) has eval too ;)

Only in programs that invoke it on hacker controlled data.

Re: Gitlab servers are being exploited in DDoS attacks

#123

Post by popcube »

justin_oaks wrote: post #90
djbusby wrote: post #64

Earlier quoted context omitted.

It's clearly not complete shit, else it wouldn't be used by literally millions of people/systems. ExifTool is so far away from shit that in fact it was chosen by a highly respected company with a very good team. A hackjob usually has less deploys than my own stuff (which, outside of Windows 2000 components, is less than a few millions)

Just because something is useful doesn't mean it's not a hackjob. Just looks at how PHP got so popular. Clearly it was useful and thus became popular. I think it's hard to argue that it wasn't a hackjob when it first started.

JavaScript is a perfect instance

Re: Gitlab servers are being exploited in DDoS attacks

#124

Post by cookiengineer »

danudey wrote: post #93
jacquesm wrote: post #42

Earlier quoted context omitted.

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.

Ideally you would sandbox this with: 1. No filesystem access 2. No network access 3. Input passed on stdin (or a pre-opened fd) 4. Output passed to stdout (or a pre-opened fd) 5. A hard timeout specified before the process is killed Suddenly bam, dramatically safer. If you're looking for a tool that can do all of this for you, check out firejail: https://firejail.wordpress.com/ It has a ton of options, but you can do…

Note that firejail had a serious RCE in the way it parses URLs for at least emails. Personally, having read the codebase, I wouldn't put too much faith in its security, given how long it took that the meta character parsing problems were discovered.

A user input facing software should always use fuzzing to uncover such bugs.

Re: Gitlab servers are being exploited in DDoS attacks

#125

Post by beefield »

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 snippet and that would be evaluated/executed server side? Is that even possible?

Re: Gitlab servers are being exploited in DDoS attacks

#126

Post by 2ion »

Gigachad wrote: post #65
Someone1234 wrote: post #38

Earlier quoted context omitted.

> But there is much noise to filter through in the many tools we juggle these days, especially if an organization prefers to self-host. If an organization is too overloaded to patch for six months, maybe they should re-evaluate if self-hosting is the best course of action. Seems like this is a foot-gun of your own creation.

There is very little reason to even self host Gitlab unless you are insanely paranoid or for philosophy reasons like debian/gnome.

In EU, some sectors that are doing business with public institutions are effectively barred from using US clouds, esp. in education, as contracts tend to demand a degree of control and assurement that no US hyperscaler or SaaS is going to give you.

Also let's not forget that self-hosted still offers features SaaS does not, such as server hooks, which are absolutely not uncommon in grown environments based on gitolite etc looking to migrate.

Re: Gitlab servers are being exploited in DDoS attacks

#127

Post by lemoncucumber »

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…

Sure, that's basically what services like AWS Lambda do. As a starting point, you'd want to run the code in a short-lived VM with little to no network access which is dedicated to just running untrusted code.

Re: Gitlab servers are being exploited in DDoS attacks

#128

Post by bsdooby »

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…

Tcl's possibility to use a restricted child interpreter and the active file pattern come to mind.

Re: Gitlab servers are being exploited in DDoS attacks

#129

Post by nl »

lemoncucumber wrote: post #127
beefield wrote: post #125

Earlier quoted context omitted.

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…

Sure, that's basically what services like AWS Lambda do. As a starting point, you'd want to run the code in a short-lived VM with little to no network access which is dedicated to just running untrusted code.

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.

Re: Gitlab servers are being exploited in DDoS attacks

#130

Post by KronisLV »

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

Post reply on HN