In Log4J WTF news today…
-
@dkf aaah, I get what you're saying now
-
Log4Shell Update: Second log4j Vulnerability Published (CVE-2021-44228 + CVE-2021-45046) | LunaTrace
A quick update on the situation now that a new log4j CVE has been created and patched in 2.16.0. We've done research and these are our findings.
-
Ah, today the company I'm at suddenly realized that a RCE with level 10 might be bad. And i was volunteered to look at servers I have not seen before and fix the problem. 😆
-
-
@LaoC said in In Log4J WTF news today…:
Yeah, when you start wanting very complex requirements for logging, you're probably doing something wrong.
I'd love if Java wasn't as retarded about logging as it is.
-
@Carnage I have, on occasion, ways to simplify message prefixes. Particularly with trace logging prefixing the object we're currently working with would make sense. Mind you, this is C. However I've never found any solution I particularly liked.
A previous colleague would start every file with ~200 lines of 'debug wrappers' just to add prefixes that made sense in context. I don't like that solution (mostly because of the 200 lines). But I've not been able to come up with anything better so far.
Hm, maybe something along the lines of
#define dbg_foo(type, foo, msg, args...) dbg(type, "Foo %d: " msg, foo->id, args)
-
@LaoC said in In Log4J WTF news today…:
ry alert: I find it pretty annoying that everyone seems to just copy this butt-plug curve from google image search:
I guess someone who knows just enough to be dangerous made this info-graphic using an svg editor, but the shape isn't what a bell curve looks like.
Stolen from somewhere else hopefully more correct instead of making my own:
And overlayed (without caring to clean it up)
-
-
-
-
don't need SSL certificates when the website is served over HTTP
-
@Bulb The basic problem with
java.net.URLis that some “smart” guy decided that hostnames in URLs should compare as equal when they resolve to the same server. That's both potentially really expensive to determine and wrong for HTTP. And for some reason (
) nobody's had the gumption to just delete that comparison and instead just do the equality on the hostname string. Instead, there's java.net.URIwhich does it right, but can't be used to interact with the resource.I have literally no idea why that comparison can't be changed. It equates things that shouldn't be equal, and simultaneously can't figure out when two URLs resolve to the same resource (because of proxying and the sheer complexity inside services). Given that these are both fundamental, giving up on trying to produce absolute canonicality would seem to be sensible.
-
@dkf said in In Log4J WTF news today…:
And for some reason
Backward compatidebility, obviously.
java.net.URIwhich does it right, but can't be used to interact with the resource.This is the real issue. Everything taking
URLshould have gotten an overload takingURIand the original one should have been marked deprecated. ThenURLitself could have been deprecated and left behind for the poor sods who
to update their code.Also
potentially really expensive
On a correctly configured server it should actually be impossible, because the server itself shouldn't be allowed to make DNS queries, only the HTTP(S) proxy it uses for egress should. Otherwise an attacker equipped with iodine will just use that to call home next time they break in.
-
@Bulb said in In Log4J WTF news today…:
because the server itself shouldn't be allowed to make DNS queries
It's really quite difficult to make that work. An irritating number of things require DNS in order to function at all.
-
Okay, this is translated from this article:
Working as intended
There've been many jokes about the Java slogan "Write once, run anywhere". Many treat the Log4j-exploit like a bug - but it isn't.
A critical gap in the Java library Log4j is rampant in the news. The IT-world is calling for Condition Red because the Log4j-code can do a JNDI variable expansion.
But what is that actually? Jindi al Dap is the name of an old Arabic philosopher and mathematician who worked for Sun/Oracle to develop a system for directory lookups in Java. This system loads code from the internet. But even when looking at the system diagram for a long time you may not discover at which point the Java CLASSPATH is widened so much that it encompasses the whole Internet:
Nothing is ever simple
That's because nothing in Java is ever simple. Java code is unstructured dry dust of code fragments in class files which interact in no way when inert. Only with factories, delegates, generators and classloaders will they be instantiated and assembled. The resulting heap of cross references will eventually run actual working code by random chance.
You could arrive at the idea to use an IDE with integrated syntactic code search to form this code pile into a structure you can actually understand. But that's futile: Even with the whole codebase and a search index you can't predict what a given Java Codebase will do upon starting it. You need configuration files. Those are another heap, property files, written in an antediluvian precursor of YAML: XML.
At least that's what we're supposed to think: With properties and the code base we can finally understand what Java is doing. And that would be almost the case but JNDI is here to solve that problem: Directory Lookups!
Instead of packaging the application and its configuration and then installing those packages in production, we now can read the configuration from the net using JNDI. This means that the actual configurations files which tell us what the application will be doing are ... not there anymore. Progress!
This ensures that nobody can hack us because no one has a clue anymore what the code is doing: Important information enabling understanding of the codebase are hidden away in a directory service and we don't even know which. But we can go even a step further: The code doing the directory lookup also isn't there anymore, only a bootstrap instead: Event and Service Provider Packages.
Thanks to JDNI SPI we can deliver Java Classfiles from an LDAP server which purport to generate a printer object when asking for a printer - but instead install Doom. Or a crypto miner or an encryption trojan. That's Enterprise Security.
The Java slogan is "Write once, run anywhere". We did a lot of jokes about it because Java crashed so often - most Java applications deliver the whole application environment including the JRE so that at least something is running. And now everything is working for once - and people are unhappy for some reason.
But seriously: Many treat the log4j-epxloit as a bug, a coding error, as going against the specifications. But that's not the case: It's working - literally - as intended, documented and specified: All the modularity and dynamic extensibility of Java working in tandem as planned. That's what we worked for over decades! "NOTABUG, WONTFIX"
And that's the actual problem. Many cry for "More control!", "More review!", "More funding!", "More eyes on the code!". What would really help would be less code, less indirection and boilerplate and just more ... simplicity.
Why do I need a LogAppenderFactorySingleton which reads XML to get a name of the class which it has to instantiate so that I can throw my log message into it so it can be added asynchronously to a LogStream? That's not easy. What's easy? Printing JSON to stderr. That's easy. But companies hire people for a decade now who don't know what stdout and stderr is and that's okay because everything is a webservice now anyway.
Software development has become much more modern: We have merge requests with code review, CI/CD pipelines, Infrastructure As Code and Immutable Infrastructure. That's all for nothing, though, when my Java Logging Library residing on Mars is loading code from directory servers on Earth and is thus defining the "Remote" in RCE in a completely new way. The analysis of dependencies is only sensible when the list of dependencies is finally and exactly as immutable as the infractructure itself.
Java did indeed have the control knobs to enforce just such an immutable and finite list of dependencies. If that's your kink there's something called SM: Oracle SM.
SM delivers the needed contracts and discipline a codebase needs. But most users don't like SM and turn down this idea. As a result, this functionality will be marked as deprecated in Java 17 and later removed.
Like a toddler
JNDI turned SM down as well and has a promiscuous interface which loads code from somewhere and runs it. You can picture a toddler which puts every class in its mouth to see what it tastes like and if it's executable.
That's the specification exactly: Here's an object, deserialize it. In Java this means that the code for the class of this object has to come from somewhere by which it's methods are run. No one would think of this as a good idea. On the other hand, the person who implemented it eight years ago did not see it and the plethora of people who imported log4j into their codebase did not stumble over it either.
What does that tell us about the dependency management process of organizations which develop software? About the comprehension of the codebase, the dependencies and the processes which plan data flows and releases? Yes, exactly. "We use a modular architecture and agile methodes to increase development speed."
E = 1/2 m*v²
A greater development speed results in bigger craters.
Code. Is. Not. Your. Friend.
Especially dynamically loaded code from the Internet.
Code. Is. Not. Your. Friend.
Yes, it sounds weird when you're a developer and it's your way of supporting your lifestyle by believing that code is your friend.
But that's the way it is. Less code is better code. Best would be so few code that it's possible to completely understand it with all its interactions. Including the code which is necessary to run your own code.
-
@Rhywden don't forget to translate the author's bio.
Kristian Köhntopp started programming in 1983 and has been online since 1988. Since then he's done many different things with computers of all kinds, but in the face of the current state of affairs is contemplating a career in landscaping.
-
Btw, if you want to know how that thingy works, just take a look at the fornt page:
Don't Lookup: The Log4j Debacle
All the headlines for the past week have touched upon the "Log4Shell" bug, CVE-2021-44228. This is a "big deal" bug that's coupled with some surprising features of how Java works. Before we get into the news roundup portion of this, we need to discuss a little history. Today, the buzzword is...
-
The operations team at this place apparently isn't completely useless! They have set up keeping tabs on where requests that try to use this exploit here. A very big majority of the messages originate in China
and germany 
-
-
@Rhywden said in In Log4J WTF news today…:
At least that's what we're supposed to think: With properties and the code base we can finally understand what Java is doing. And that would be almost the case but JNDI is here to solve that problem: Directory Lookups!
That thing (most of Java, really) was clearly invented by some architecture astronaut that hated maintenance programmers to the marrow of his bones. Because this is maintenance programmer's worst nightmare.
-
Damn...
GitHub - YfryTchsGD/Log4jAttackSurface
Contribute to YfryTchsGD/Log4jAttackSurface development by creating an account on GitHub.
Log4j impact on manufacturers and components summary from the Internet community
-
@Bulb said in In Log4J WTF news today…:
@Rhywden said in In Log4J WTF news today…:
At least that's what we're supposed to think: With properties and the code base we can finally understand what Java is doing. And that would be almost the case but JNDI is here to solve that problem: Directory Lookups!
That thing (most of Java, really) was clearly invented by some architecture astronaut that hated maintenance programmers to the marrow of his bones. Because this is maintenance programmer's worst nightmare.
It was actually designed by IBM.
I distinctly remember that when I tried to read something about J2EE in 1998-2000, it made absolutely no sense. Lots of very, very, very complicated solutions for... what exactly? It wasn't until 2006 when I first came into contact with IBM world, and then the epiphany came.
In short: the basic design principle behind J2EE is to force develops to solve all the problems they never had and never will have. But someone, somewhere, at some point in the multiverse, might have.
-
So of course, there's Logout4Shell, which uses the exploit to close the hole on target servers.
the wonderous state of modern software keeps on giving
-
@Kamil-Podlesak said in In Log4J WTF news today…:
It was actually designed by IBM.
:there_is_your_problem:
-
@Kamil-Podlesak said in In Log4J WTF news today…:
@Bulb said in In Log4J WTF news today…:
@Rhywden said in In Log4J WTF news today…:
At least that's what we're supposed to think: With properties and the code base we can finally understand what Java is doing. And that would be almost the case but JNDI is here to solve that problem: Directory Lookups!
That thing (most of Java, really) was clearly invented by some architecture astronaut that hated maintenance programmers to the marrow of his bones. Because this is maintenance programmer's worst nightmare.
It was actually designed by IBM.
It was designed by architecture astronauts. They worked in IBM. But IBM does not have a mind of it's own. It must have been someone at IBM, and that someone (or somemany) was an architecture astronaut.
I distinctly remember that when I tried to read something about J2EE in 1998-2000, it made absolutely no sense. Lots of very, very, very complicated solutions for... what exactly? It wasn't until 2006 when I first came into contact with IBM world, and then the epiphany came.
In short: the basic design principle behind J2EE is to force develops to solve all the problems they never had and never will have.
Solving problems you didn't know you never had is … recurring theme in Java. We already had Singletons: Solving Problems You Didn't Know You Never Had Since 1995.
But someone, somewhere, at some point in the multiverse, might have.
Only if they caused the problems for themselves in the first place.
-
@Bulb don’t forget IBM invented JSONx, a thing no one else needed or wanted.
Example: https://www.ibm.com/docs/en/datapower-gateways/10.0.1?topic=jsonx-conversion-example
-
@Arantor said in In Log4J WTF news today…:
@Bulb don’t forget IBM invented JSONx, a thing no one else needed or wanted.
Example: https://www.ibm.com/docs/en/datapower-gateways/10.0.1?topic=jsonx-conversion-example
<json:object xsi:schemaLocation="http://www.datapower.com/schemas/json jsonx.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx">… why by the Flying Spaghetti Monster do some people assign the namespace that applies to each and every element in the XML file to a non-empty prefix and then repeat the prefix literally everywhere?
… or is it because they defined the attributes with no namespace and now couldn't use them if they set the default namespace (
xmlns="http://www.ibm.com/xmlns/prod/2009/jsonx"instead ofxmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx")? I mean, the application I currently work on wastes space exactly the same way.
-
@Bulb said in In Log4J WTF news today…:
why by the Flying Spaghetti Monster do some people assign the namespace that applies to each and every element in the XML file to a non-empty prefix and then repeat the prefix literally everywhere?
Tool-generated stuff. Also, specs are often written that way just to be clearer.
-
@dkf It is almost always machine generated, because who in their right mind would write XML by hand. But it still wastes space by repeating the prefix all over.
-
@Bulb everything I have seen about IBM in the last 20 years suggests that the answer is “cargo cult whatever is the most objectively verbose without being offensively repetitive”. As in there are people who like this level of repetition, and that while it’s annoying AF, it’s “not offensively repetitive” unlike some others I’ve seen that do this.
I also assume no actual human will either create or consume this, thus minimising the inflicted pain.
Then again I remember dealing with one genius who spent time implementing a “strip the leading white space” filter to minimise the data sent from the web server (because gotta go fast) and discovered that after gzip compression, dropping the leading space made everything less compressed than before. So maybe it’s that somehow.
-
@dkf said in In Log4J WTF news today…:
Tool-generated stuff
-
@Bulb said in In Log4J WTF news today…:
@Kamil-Podlesak said in In Log4J WTF news today…:
@Bulb said in In Log4J WTF news today…:
@Rhywden said in In Log4J WTF news today…:
At least that's what we're supposed to think: With properties and the code base we can finally understand what Java is doing. And that would be almost the case but JNDI is here to solve that problem: Directory Lookups!
That thing (most of Java, really) was clearly invented by some architecture astronaut that hated maintenance programmers to the marrow of his bones. Because this is maintenance programmer's worst nightmare.
It was actually designed by IBM.
It was designed by architecture astronauts. They worked in IBM. But IBM does not have a mind of it's own. It must have been someone at IBM, and that someone (or somemany) was an architecture astronaut.
Ok, let me add the part I've omitted (I thought that hint might be enough): everything IBM creates is done by architecture astronauts. Looks like everyone at IBM is either manager, architecture astronaut or a minion with no say in anything.
I distinctly remember that when I tried to read something about J2EE in 1998-2000, it made absolutely no sense. Lots of very, very, very complicated solutions for... what exactly? It wasn't until 2006 when I first came into contact with IBM world, and then the epiphany came.
In short: the basic design principle behind J2EE is to force develops to solve all the problems they never had and never will have.
Solving problems you didn't know you never had is … recurring theme in Java. We already had Singletons: Solving Problems You Didn't Know You Never Had Since 1995.
Uhm... you know that the Design Pattern book (GOF, published in 1994) actually used C++ and Smalltalk, do you? The only connection to Java is that they became "hip" at the same time.
But someone, somewhere, at some point in the multiverse, might have.
Only if they caused the problems for themselves in the first place.There are, actually, some situations where you might need to handle custom transaction control over several distributed systems (including few database engines) with configuration defined well after development by completely different people in a completely different company.
So... yes, you're right.
-
@Arantor said in In Log4J WTF news today…:
I also assume no actual human will either create or consume this, thus minimising the inflicted pain.
Your youthful faith in humanity is adorable.
-
@Rhywden said in In Log4J WTF news today…:
Okay, this is translated from this article:
This reads like something Mark Twain would have written about Java.
-
@Kamil-Podlesak said in In Log4J WTF news today…:
@Bulb said in In Log4J WTF news today…:
@Kamil-Podlesak said in In Log4J WTF news today…:
@Bulb said in In Log4J WTF news today…:
@Rhywden said in In Log4J WTF news today…:
At least that's what we're supposed to think: With properties and the code base we can finally understand what Java is doing. And that would be almost the case but JNDI is here to solve that problem: Directory Lookups!
That thing (most of Java, really) was clearly invented by some architecture astronaut that hated maintenance programmers to the marrow of his bones. Because this is maintenance programmer's worst nightmare.
It was actually designed by IBM.
It was designed by architecture astronauts. They worked in IBM. But IBM does not have a mind of it's own. It must have been someone at IBM, and that someone (or somemany) was an architecture astronaut.
Ok, let me add the part I've omitted (I thought that hint might be enough): everything IBM creates is done by architecture astronauts. Looks like everyone at IBM is either manager, architecture astronaut or a minion with no say in anything.
Looks like it indeed.
… they should assume a motto “Solving your problems by creating new ones since 1911”.
I distinctly remember that when I tried to read something about J2EE in 1998-2000, it made absolutely no sense. Lots of very, very, very complicated solutions for... what exactly? It wasn't until 2006 when I first came into contact with IBM world, and then the epiphany came.
In short: the basic design principle behind J2EE is to force develops to solve all the problems they never had and never will have.
Solving problems you didn't know you never had is … recurring theme in Java. We already had Singletons: Solving Problems You Didn't Know You Never Had Since 1995.
Uhm... you know that the Design Pattern book (GOF, published in 1994) actually used C++ and Smalltalk, do you? The only connection to Java is that they became "hip" at the same time.
I always viewed Design Patterns with a huge dose of skepticism, so I didn't realize, actually.
It makes it even much worse, because C++ has better ways of doing most of the things. In Java the patterns can at least be viewed as working around limitations of the language, but C++ is more flexible than that.
But someone, somewhere, at some point in the multiverse, might have.
Only if they caused the problems for themselves in the first place.There are, actually, some situations where you might need to handle custom transaction control over several distributed systems (including few database engines) with configuration defined well after development by completely different people in a completely different company.
So... yes, you're right.
A maintenance programmer's worst nightmare indeed. I can imagine such things are usually almost got to work before they crash and burn and a long ping-pong of messages trying to find out who shall change what where and who shall pay for it ensues.
And it's still stupid to just have it built into the system. If the customer needs to inject custom handling between the app and their storage, create them a plugin API – at least then everybody will know it's there and what it's supposed to do. But just monkey-patching the system is a recipe for disaster.
-
@Bulb said in In Log4J WTF news today…:
I always viewed Design Patterns with a huge dose of skepticism, so I didn't realize, actually.
Abstractly, they're just named ways of doing things and aren't tied to OOP at all. You get different patterns in different languages; functional programming language design patterns are very different indeed (and for all that we make fun of IO Monads, they are definitely design patterns for Haskell).
It makes it even much worse, because C++ has better ways of doing most of the things. In Java the patterns can at least be viewed as working around limitations of the language, but C++ is more flexible than that.
C++ has changed quite a bit since 1994. Unsurprisingly, the valid set of patterns for it have also changed. (I believe the valid set of patterns for Java has also changed, especially with Java 8's lambdas.)
-
@dkf said in In Log4J WTF news today…:
@Bulb said in In Log4J WTF news today…:
I always viewed Design Patterns with a huge dose of skepticism, so I didn't realize, actually.
Abstractly, they're just named ways of doing things and aren't tied to OOP at all. You get different patterns in different languages; functional programming language design patterns are very different indeed (and for all that we make fun of IO Monads, they are definitely design patterns for Haskell).
Design patterns in general are not tied to OOP indeed, but the GOF Design Patterns is mostly about the OOP ones.
It makes it even much worse, because C++ has better ways of doing most of the things. In Java the patterns can at least be viewed as working around limitations of the language, but C++ is more flexible than that.
C++ has changed quite a bit since 1994.
Indeed, it was still C-with-classes, though it might have already been called C++ by the time. But with advent of templates, C++ quickly became mostly about generics and about some implicit abstractions using RAII and user-defined conversions and the object-oriented stuff never really took of there.
It was Java that fell for it, hook, line and sinker.
Unsurprisingly, the valid set of patterns for it have also changed. (I believe the valid set of patterns for Java has also changed, especially with Java 8's lambdas.)
Java 8 also introduced a lot of functional stuff, which would be nice if it wasn't so brutally unwieldy.
-
@Bulb said in In Log4J WTF news today…:
I always viewed Design Patterns with a huge dose of skepticism, so I didn't realize, actually.
I think the problem is that some people learn the design patterns first, and subsequently, every problem looks like a FacadeBridgeFactorySingletonFactory. They become more or less unable to think outside the few standard patterns that they've been thought.
Instead formalizing some of the common patterns that one has been using anyway and giving them names isn't as problematic. If you've been a developer for a while before learning about the standard patterns, you already know that they're not all that exists (nor are they intended to be).
-
@MrL I was careful to qualify with “actual human”. I feel like anyone who manually reads or writes this (outside of glancing, rolling eyes and feeding it into a converter) has gone drastically wrong somewhere in their life and should re-evaluate whether they still justify the title of “human, apex species of Earth” or something like that.
Or that they’re not secretly a weird AI in disguise.
-
@Arantor said in In Log4J WTF news today…:
@MrL I was careful to qualify with “actual human”. I feel like anyone who manually reads or writes this (outside of glancing, rolling eyes and feeding it into a converter) has gone drastically wrong somewhere in their life and should re-evaluate whether they still justify the title of “human, apex species of Earth” or something like that.
Or that they’re not secretly a weird AI in disguise.
I'd agree about morons that write stuff like this by hand. But guess who reads it? Me, when I have to fix their broken shit "system".
-
@MrL You don't feed it into a converter to make it readable? Good heavens.
-
@Arantor said in In Log4J WTF news today…:
@MrL You don't feed it into a converter to make it readable? Good heavens.
That would break it even more, of course.
If you string concatenate this somewhere, there must be at least one receiver somewhere that's parsing it by hand.Sanity is the wide tempting path to failure.
-
@MrL I mean for your own personal consumption reasons - not introducing it into the chain (or ripping the whole thing out and replacing with native JSON)
In any case, I recant my somewhat officious statement and you have my deepest sympathies.
-
@Arantor said in In Log4J WTF news today…:
@MrL I mean for your own personal consumption reasons - not introducing it into the chain (or ripping the whole thing out and replacing with native JSON)
Ah, sure. Provided that it's not malformed enough to choke the converter.
In any case, I recant my somewhat officious statement and you have my deepest sympathies.
No worries, I get money in exchange.
-
@Arantor said in In Log4J WTF news today…:
@Bulb don’t forget IBM invented JSONx, a thing no one else needed or wanted.
Example: https://www.ibm.com/docs/en/datapower-gateways/10.0.1?topic=jsonx-conversion-example
-
@topspin said in In Log4J WTF news today…:
@Arantor said in In Log4J WTF news today…:
@Bulb don’t forget IBM invented JSONx, a thing no one else needed or wanted.
Example: https://www.ibm.com/docs/en/datapower-gateways/10.0.1?topic=jsonx-conversion-example
https://what.thedailywtf.com/topic/13371/ibm-s-jsonx-or-how-to-represent-json-in-xml
https://what.thedailywtf.com/topic/13991/jsonx-is-sexy-liesx
-
@Luhmann said in In Log4J WTF news today…:
So of course, there's Logout4Shell, which uses the exploit to close the hole on target servers.
the wonderous state of modern software keeps on giving
Nah. The age of viruses (for MS-DOS, no less) that someone wrote to infect vulnerable machines and prevent "real" viruses from using the same infection path is apparently on us again.
-
@Arantor said in In Log4J WTF news today…:
secretly a weird AI in disguise
Ssssh! Don't give the game away.
-
@Arantor said in In Log4J WTF news today…:
Or that they’re not secretly a weird AI in disguise.
I misread this as
Weird Alas if he's given up with parodies and now just writes JSON as XML.
-
@Steve_The_Cynic said in In Log4J WTF news today…:
@Luhmann said in In Log4J WTF news today…:
So of course, there's Logout4Shell, which uses the exploit to close the hole on target servers.
the wonderous state of modern software keeps on giving
Nah. The age of viruses (for MS-DOS, no less) that someone wrote to infect vulnerable machines and prevent "real" viruses from using the same infection path is apparently on us again.
The idea of writing a second virus/worm to exploit a security hole to delete a first virus/worm definitely goes back to before MS-DOS. There's at least Creeper and Reaper from 1971.
