Hacker News Reader

Comment by deng | Hacker News Reader

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.

View on HN

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.

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.

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.

Why the heck would anyone create an externally accessible Jenkins?

Public facing AND without any sensible auth.

Reply on news.ycombinator.com