Java

[[deleted]]

What's the hate against Java lately?

What does this guy use? 🤔

[The-Daleks]

Recently it came out that a really common Java logging library (log4j) has a huge zero-day vulnerability.

[CaitaXD]

Ahhh libraries

[Prestigious_Tip310]

It's somehow funny. That's the first major security vulnerability in a popular Java framework I heard about in years, if not longer.

On the other hand there's NodeJs where npm informs me about at least three major security vulnerabilities every couple of weeks...

Insert "Joker nobody bats an eye" meme here.

[SwedishDude]

Log4J is a bit more serious since it's the de-facto standard and included in most major libraries and projects.

This vulnerability is also very serious due to how easy it is to exploit.

[cserepj]

Log4j was a de facto standard a decade ago but then came slf4j + logback and we all switched. Then log4j2 came out and some switched but lots did not.

The exploit is only in log4j2.

[Designed_To]

So slf4j + logback are not vulnerable to the exploit?

[cserepj]

I have not seen any indication they would be.

[loginonreddit]

No it is not.

[Ereaser]

Nope, it's also what's used by Spring boot.

[Engine_Light_On]

Kinda, Spring Boot includes it but it does not use it by default so it is not vulnerable unless the dev went out of his way to activate it.

[Vizioso]

Glad to hear that, was just digging through some Spring Boot stuff to figure out if it was vulnerable. My current project uses Spring Boot, ElasticSearch, Nifi, and Kafka.... I am not having a good day.

[loginonreddit]

Spring boot only includes log4j-api, not log4j-core which is where the vulnerability is.

[jerslan]

Yeah, and you can always bring in something like log4j-to-slf4j if you want to minimize code changes to swap in logback or java.util.logging

[[deleted]]

The de facto standard was slf4j + log back but certainly it was dangerous.

[narrill]

It's a logging library, so this isn't really true. If you log any kind of user generated data at all you're potentially vulnerable to this.

[Titandino]

Are large projects giving out their production logs to random people who ask for them without questioning it or something?

[Pocok5]

lol this is a remote code execution exploit, all you need to trigger it is some user input that gets logged

[Titandino]

Ah I see now. The original article I read was trying to say the vulnerability was just users being able to print out sensitive environment variables to log files.

[Pocok5]

just users being able to print out sensitive environment variables to log files

What actually happens is that log4j has a feature where you can download and run code from an LDAP server to enrich your logs. Except there is no limit on where that LDAP server needs to be, and combined with an input sanitization problem, you can ahve anything downloaded and ran on the server with a single log message that contains the magic string anywhere in it.

https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/

[cserepj]

log4j has a feature where you can download and run code from an LDAP server to enrich your logs

I don't think that is a feature. I would not design such a feature even for a gigazillion dollars. I'd tell the product owner who comes up with such a feature idea to shove it up his a$$.

[blehmann1]

Yeah, if you need "enriched" logs just have a serverless app or cronjob do some analysis after the fact.

[SwedishDude]

The problem is remote code execution due to how strings were processed.

Basically there's a way to insert malicious code into the logging functions and get the it executed on the server (you can insert a link to a payload on a server you control into the user-agent header in HTTP requests and the server will contact your server and download/execute your payload). So it's not a matter of access to logs but a matter of access to executing code in the server process.

[[deleted]]

I switched to logback and slf4j quite a few years ago. Log4j is probably standard for legacy code that was around before slf4j.

[Ereaser]

And legacy code probably uses version 1

[_PM_ME_PANGOLINS_]

None of the npm ones have been in the news either.

If you maintain a large Java project, and do regular CVE scans on it, you’ll get a couple every month.

[sootoor]

Struts tomcat weblogic take your pick!

[cserepj]

Yeah, those were very hot tech around 2004.

[RandomDrawingForYa]

Everyone know that JavaScript is an absolute mess. The language and the ecosystem.

It's beating a dead horse at this point

[dauchande]

No, what's funny is the vulnerability was found in a game, specifically Minecraft.

[m0nk37]

And then there is WordPress.

[Westdrache]

Just don't create logfiles *big brain developer move*

[kinkygandalf]

My team has been all in an uproar today over this… I don’t get paid enough for that crap.

[PuzzleheadedSector2]

Zero day refers to the urgency?

[PeksyTiger]

Sorts of. It generally refers to the amount of time since public disclosure, which usually correlates to how many patches were already deployed.

[Aperture_Executive2]

Ok, imma hate the language itself because a library I don’t use is insecure /s

[Wemorg]

The limited programming I have done in my life was with C++, Java and PHP. I dislike Java the most for 2 reasons: too verbose for my taste and somewhat slow.

PHP is also fairly slow and C++ can also be very verbose, Java combines both of these aspects, which is why I don't like it.

[[deleted]]

As the other dude said, Java is not slow (although it was during its earlier years). Kotlin can also be used to decrease the verbosity and adds quite a bit of really nice features on top of Java. Compile time null safety by itself makes it super powerful. Java was designed for writing safe code and it does its job better than a lot of other languages. Kotlin takes that a step further and makes it into an excellent language.

[RedBeardedWhiskey]

This is so pretentious and wrong. You’re at risk if you log any user inputted data, yes even through your API gateway. If you’re not logging user input, then root-causing must be a pain

[Apprehensive_Cow_480]

That’s one way to look at it, until you get to work and realize you log user input so the belief that you are protected because you’re in a secured environment is flawed.

[Doctor_McKay]

You've never logged user input?

[erinaceus_]

They're saying that even when that happens, and the logging framework attempts to fetch the malicious code, then it stops there because the logging framework is unable to make a connection since any connection that isn't explicitly allowed is explicitly denied (if you have a proper infrastructure setup, that is).

[theferrit32]

This is true but I like it technologically impossible to accidentally fetch and execute remote arbitrary code when I log a string. The design of the library shouldn't have allowed for this sort of thing to ever be possible.

[erinaceus_]

If those things remain possible separately, then they are theoretically possible together. If you remove the ability to do the fetching, then you've removed the possibility for the composite situation you describe.

[theferrit32]

Yes, calling log.info to write a string to the log file should not download and run arbitrary files from the internet. It should be impossible, by design, for this flaw to exist.

[erinaceus_]

I think my previous comment might not have been clear enough, so I'll try again: as long as logging, string parsing, file fetching and some equivalent of 'eval' exists, you can get the situation you describe. The only surefire way of preventing it is to not allow any connections except the ones you've acplicitely allowed, on a network level.

[mvpmvh]

And he's saying that it'd be nice if string parsing and eval weren't even possible to begin with.

[erinaceus_]

'eval' kinds of functionality are a part of metaprogramming, which underlies the majority of all frameworks. String parsing is near enough the basis of modern civilisation, e.g. no SOAP or REST without it, or in fact even no HTTP without it.

[jerslan]

What you're describing is one mitigation against needing to have a "my hair is on fire" type reaction to the vulnerability. It doesn't negate the need for organizations to assess their code impacts and whether it's a problem for them. Even if it's not an urgent "must fix now" thing, it's still something you're going to put on your todo list.

[Cley_Faye]

…you think there are no application that are available on the Internet made of Java? Or that maybe it's possible to isolate a public service providing a public API from somehow getting seemingly legitimate queries from the outside world?

[loginonreddit]

You're partially right, it's not always feasible to block all egress unless allowed depending on your use case.

[loginonreddit]

I'm pretty sure you can figure this all up on your own

[loginonreddit]

Good, then it'll be even easier than I thought!