Hacker News Reader

Comment by dmbche | Hacker News Reader

"however, they made one of the most comedic mistakes you can still make while setting up jenkins (im actually not sure which misconfiguration leads to this): the build information for each past build contains a link to the git repository, including the bitbucket credentials in the url. genius."

View on HN

No, the most comedic mistake is to have a public-facing Jenkins running. I mean in general you wouldn't make your CI accessible from the outside, but especially not Jenkins. That software has probably more CVEs every year than all of our other tooling combined.

Given the frequency with which I seem to update nokogiri on a rails instance, i assumed libxml2 would hold that award: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libxml2

But sure enough, jenkins FAR outweighs it: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=jenkins

And that's just the ones that get reported. Since core Jenkins is pretty bare-bones, most instances also have many plugins installed, and most of those aren't properly reviewed at all.

The vast majority of those Jenkins CVEs seem to be for a wide variety of plugins, so it seems someone is putting in quite a bit of work to review them.

Yes, to give credit, they do monitor the most important ones which almost everybody uses and which are usually also maintained by developers from Cloudbees. But there are over 1800 plugins for Jenkins, so at least quantitatively, most of them are not monitored.

The most comedic mistake is to have a running jenking in 2023

The vast majority of gigs/jobs I've had which involved touching Jenkins were for the purpose of migrating elsewhere - Gitlab, GitHub Actions, Drone, Harness...

Highly customizable CI tool.

..written in Java.

In case anyone needs reminding, Java developers, on purpose, put a line in a logging library that can fetch and execute code when given a url string for a log statement.

Nobody should be touching anything Java in 2023.

Yes, we all sat down and unanimously agreed that we should perform JNDI lookups to execute arbitrary code stored in an LDAP directory.

No regrets.

I remember that meeting. It was the one where we all wore togas and drank the java kool aid from goblets before we voted on that. All 5,000,000 of us.

You joke, but that code made it through rounds of reviews, and nobody saw anything wrong with having a logging library able to make network requests in the first place.

I honestly don't even blame the developers of Log4J that much, because after all its open source, and nobody is paying them to use it despite the idiocy surrounding shit like that.

I do however blame the developers that use Java, see things like this happen, and then continue to use it with Log4j after the patch like nothing ever happened.

Since developers can just decide to rewrite a code base because Java is not a shiny new language.

JNDI is an obscure feature from the Java Enterprise Edition days that nobody really uses nowadays.

Java, Not Even Once.

What's the most comparable alternative to use for self-hosted CI in 2023? Curious.

Public facing AND without any sensible auth.

An externally accessible Jenkins instance is just asking to get pwned.

I worked for a company a couple years ago that had Jenkins running on a Windows EC2 with a bare public IP, no TLS, and a single set of admin credentials shared by everyone. Also, the host did double duty as some sort of DBA jump box and had every possible credential.

It was like in-defense in depth. I tried to explain how crazy it was. They weren’t interested in fixing it. I moved on.

Some companies just don’t care… soc 2 btw.

Why the heck would anyone create an externally accessible Jenkins?

The most horrible thing Jenkins does to devs is it encourages bad practice. Good practice is so cumbersome to do properly (create a secret, load secret in env through Groovy code, setup git configuration in a shell script) that, unless someone is actively monitoring them, devs are always in a temptation to just put the credentials in the git URL, we'll remove them after testing. Then one out of N times they forget and you get a security hole.

Uh, no, you just pick credentials from list in the repo config.

If you wanted to download additional repo in the jenkins script sure, but Jenkins Git plugin just accepts credential (whether its password or pub/priv key pair), just paste URL and select one from the list

It's 2023, it's far past the time that open-source projects should be made without security being the #1 concern, even above the basic functionality of the app. But Jenkins has been around since 2011, so it's understandable that the security posture is obtuse and tacked-on. It's time for some other CI project to surpass Jenkins. I won't be sorry to see it go. Security should be front and center, the first thing the user sees. The defaults should be secure out of the box, and if the user does something stupid, it should be painfully clear to everyone, even the least technical user who looks at it, that something is wrong.

That said, I doubt that what happened here was a Jenkins configuration problem, and instead something to do with the build scripts they're running on Jenkins. You can't solve every class of stupid, sadly.

“one out of N times” where N is < 2

Reply on news.ycombinator.com