Live data from Hacker News

Gitlab servers are being exploited in DDoS attacks

therecord.media

161–170 of 177 posts

Re: Gitlab servers are being exploited in DDoS attacks

#161
post #153

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…

When people actually want just a subset of `eval` to permit some custom computation, the proper thing to do is to define that subset as a language and make an interpreter that will read only that language. As for mostly-full-featured `eval`: iirc Perl itself has a facility to create restricted sub-interpreters and run scripts that can't do certain things. (Though I might be confusing Perl with PHP here.)

Almost all modern programming languages have parsers for that language either as a standard library feature or as a package available in the ecosystem. That means it's very easy to run a production quality parser over an input string and then validate and the interpret the resultant AST as you see fit.

Besides that approach, simply rolling your own parser using a parser combinator library is super simple. The word combinator makes it seem complicated, but it's actually the opposite, using parser combinators is a lot simpler than writing a parser the traditional way you might have learned in formal education.

Implementing a simple DSL like for example an event-filtering language should cost a competent but fully inexperienced programmer maybe 1 or 2 weeks for a proof of concept, and then 3-6 more weeks to get it production ready depending on the feature set of course.

Of course, that's more time than simply running the V8 interpreter over your input string, and maybe running the V8 interpreter over your input string is an awesome way to empower your (trusted) customers.

Re: Gitlab servers are being exploited in DDoS attacks

#162

Earlier quoted context omitted.

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

Nor should they rely on their verification of the file format for anything other than a temporary mitigation of this specific bug! If the ExifToof / DjVu tooling itself isn't secured or sandboxed, this would be a future exploit waiting to happen.

Absolutely. To be honest I was a bit shocked they used an ExifTool binary that had anything but JPEG/TIFF support compiled in.

Re: Gitlab servers are being exploited in DDoS attacks

#163

Earlier quoted context omitted.

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.

Depending on how you have it installed you could have your package management system automatically install the updates. They aren't always perfect though, I've had at least one Gitlab update that required manually running migrations commands since the ones in the update script failed for some reason. I wouldn't trust doing it automatically. And I'm not sure about gitlab, but their are often mailing lists for security…

Thanks for the productive response. I was using Watchtower in Docker Compose on all instances, but I had it misconfigured. My fault for assuming auto updates were working without verifying, lesson learned.

Re: Gitlab servers are being exploited in DDoS attacks

#165
post #154

Earlier quoted context omitted.

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

Perl does ship a sandbox module called Safe as a standard module, though I don't know how strong it is.

"The Safe module does not implement an effective sandbox for evaluating untrusted code with the perl interpreter."

https://perldoc.perl.org/Safe

Re: Gitlab servers are being exploited in DDoS attacks

#166

Are there good reasons for people to not turn on automatic updates for security issues, I wonder?

You need to hunt breaking updates all the time as a sysadmin with autoupdates.

It it much easier to pinpoint any problem if you are aware the update happes and choose the time to do so.

Re: Gitlab servers are being exploited in DDoS attacks

#167

Earlier quoted context omitted.

Caution, CVS-2021-22205 has later been found to be exploitable without authentication. No need to be "able to upload an image," unfortunately. Also no need to take the detour through a mirrored repo as sibling suggests; so long as the GitLab instance is accessible from the internet.

> exploitable without authentication Can you provide more info? I skimmed the upstream ticket but didn't see how. Getting access to anything other than the login page on an accessible-but-private instance seems like a security bug regardless of this CVE.

Full disclosure, I wrote both of these.

The following describes the entire unauthenticated attack:

https://attackerkb.com/topics/D41jRUXCiJ/cve-2021-22205/rapi...

And, if you like that sort of thing, there is a metasploit module you can use to reproduce the unauthenticated attack:

https://github.com/rapid7/metasploit-framework/commit/6f4aa5...

Re: Gitlab servers are being exploited in DDoS attacks

#168
post #154

Earlier quoted context omitted.

Perl does ship a sandbox module called Safe as a standard module, though I don't know how strong it is.

"The Safe module does not implement an effective sandbox for evaluating untrusted code with the perl interpreter." https://perldoc.perl.org/Safe

Yeah, though in this case, whitelisting opcodes probably would have at least avoided qx and ``(both exec()). Avoiding the eval() altogether would be the right path, of course.

Re: Gitlab servers are being exploited in DDoS attacks

#169

Earlier quoted context omitted.

> exploitable without authentication Can you provide more info? I skimmed the upstream ticket but didn't see how. Getting access to anything other than the login page on an accessible-but-private instance seems like a security bug regardless of this CVE.

Full disclosure, I wrote both of these. The following describes the entire unauthenticated attack: https://attackerkb.com/topics/D41jRUXCiJ/cve-2021-22205/rapi... And, if you like that sort of thing, there is a metasploit module you can use to reproduce the unauthenticated attack: https://github.com/rapid7/metasploit-framework/commit/6f4aa5...

> Specifically HandleFileUploads in uploads.go is called from a couple of PreAuthorizeHandler contexts allowing the HandleFileUploads logic, which calls down to rewrite.go and exif.go, to execute before authentication.

I'm no security guy, but this seems... incredibly dumb? Like even for perfectly secure code, the asymmetry in resource usage alone to submit an image vs. get them to dump a file, shell out to a scanner, and rewrite that file would probably be enough to seriously hurt smaller GitLab VMs.

Re: Gitlab servers are being exploited in DDoS attacks

#170
post #68

Earlier quoted context omitted.

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.

But if you only evoke eval() on non-hacker controlled data in a scripting language, it's probably fine too.
Post reply on HN