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

111–120 of 177 posts

Re: Gitlab servers are being exploited in DDoS attacks

#111

Post by FpUser »

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.

>"avoid eval"

We are already avoiding / trying to avoid way too much interesting and useful things. All for the sake of security and only to encounter new ways to be attacked. Instead of "avoid" how about actually organizing worldwide intolerance and hunt for those attackers.

Re: Gitlab servers are being exploited in DDoS attacks

#112

Post by sedatk »

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.

> avoid eval as much as possible

"eval is evil", if you will.

Re: Gitlab servers are being exploited in DDoS attacks

#113

Post by [deleted] »

dylan604 wrote: post #78
jdc wrote: post #73

Earlier quoted context omitted.

How much longer did said dev continue working there?

Fire the dev, or educate the dev. Sure, eval is just a sure sign of a lot of lack of understanding, but I'd hope for something less vile as eval would be a little more understanding that everyone learns something sometime

[deleted]

Re: Gitlab servers are being exploited in DDoS attacks

#114

Post by tingletech »

smashed wrote: post #106
Gigachad wrote: post #63

Earlier quoted context omitted.

The line existed in the 2014 commit which migrated the repo to git. It wasn't designed in the current era of mass automated abuse and internet connected everything.

That line is in a Perl metadata cleaning library. Not in Gitlab itself. Gitlab, who prides themselves and sell the gospel of improving security, willfully chose to use that library which was obviously never designed for their use case. I looked at the front-page of that library. It says it cleans metadata from a huge number of file format. Frankly it looks more like something you would use on your own, known safe, fi…

I think they are like a very old version of jpeg 2000s that support pan and zoom / tiling of large image files. It needed a license to create and one to display iirc

Re: Gitlab servers are being exploited in DDoS attacks

#115

Post by cjbprime »

mattbee wrote: post #16
nielsole wrote: post #8

Earlier quoted context omitted.

Anyone who can open issues in a repo I think

I am confused by this right now. I built a self-hosted gitlab install years ago for my own use, turned off sign-up, no public project listings - and still it was compromised. The HackerOne PoC URL throws a sign-in redirect for me, so I'm still trying to work it out.

It was originally incorrectly thought to require authentication, but actually doesn't.

Re: Gitlab servers are being exploited in DDoS attacks

#116

Post by menscher »

BuffaloBagel wrote: post #40

My VOIP vendor, voip.ms, has been under attack for weeks. Wonder if this is the source?

Totally different.

The attacks on VOIP vendors mostly used UDP amplification, which relies on having a server that can fake its source IP due to an incompetent (or complicit!) network provider, while this is a botnet (that is only about a week old).

Re: Gitlab servers are being exploited in DDoS attacks

#117

Post by baggy_trough »

surfer7837 wrote: post #15

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…

I do it inside a systemd nspawn container with a volatile file system, no network, minimal caps.

Re: Gitlab servers are being exploited in DDoS attacks

#119

Post by throw3455aerr »

Gigachad wrote: post #102
mdoms wrote: post #91

Earlier quoted context omitted.

Sorry but this comment strikes me as incredibly ignorant. There are lots of good reasons to self host, chief among them reasons which can't be worked around - compliance and data sovereignty.

Already covered those under paranoid. There is nothing wrong with self hosting and being paranoid. But that comes with the responsibility to have someone dedicated to keeping up with the latest news on the software they run. Leaving gitlab unpatched for 6 months shows that the company is not capable of running it themselves and should not be self hosting.

It is false to tell people that self-hosting has to be that hard. If you know what you are doing and put the services in a jail / VM only not being exposed to the internet, you can leave things unpatched very long, and only update them when bug fixes or new features of recent versions are needed.

If you are a 50,000 people company where your own employees could be the adversaries maybe not. But in this case you also have the budget to have a proper security team. Apart from this case, with proper virtualization and no direct internet exposure, you'll find out that 99.99% of CVEs are not a risk to you.

If you are under-budgeted, it's fine to neglect such internal services and check vulnerabilities once a year or less. However always stay on top of the CVEs of internet facing services. My point is your message is basically the propaganda of cloud services "doing it yourself is HARD", "email is HARD", "this and that is HARD" lol.

Self-hosting in jails not being directly exposed to the internet is a productivity booster as it allows you to not fix what works FOR YOU. Just keep using this 4 years old version if it works well for you. But make informed choices as much as possible, try to stay on top of CVEs even if you decide not to patch these internal services 99% of the time. But even if you can't stay on top of your non-internet facing jails, it won't be a real risk 99% of the time.

Post reply on HN