In Log4J WTF news today…
-
status a week late but hey ... we did send out that e-mail to all customers to tell them there is no issue (because it is either not java or using an older version of log4j)
-
If anyone is still wondering what the problem is:
-
@Bulb said in In Log4J WTF news today…:
@DogsB said in In Log4J WTF news today…:
I've always thought we should just go back to C with Garbage Collection. It's what most developers write anyway.
Funny, because that's basically what the designers of Go had in mind – a C with garbage collection, some minimal polymorphism and type inference to keep it concise. Also, one of the co-authors is Ken Thompson, who previously created B and co-created C.
As someone once put it, Go is basically a bunch of C programmers listing their issues with C. While Rust is Haskell programmers listing their issues with C++.
-
@PleegWat how is it at all possible that this shit went unnoticed for so long?
I mean, even ignoring the absolute garbage of whatever this JNDI thing is and the truck-sized security hole it creates, just the basic problem of "the logger (recursively) evaluates data" is such a huge, glaring design flaw. Everyone knows about code injection vulnerabilities, little bobby tables, and even the PHP people have
mysql_real_escape_string_i_mean_it_this_time
because they've been burned by it. How can you look at the features of a logger and not realize that evaluating the untrusted data you give it instead of logging is not a huge problem? Just the variable interpolation without code injection, as they mentioned, means that any time you log untrusted data then the log itself cannot be trusted to be correct. How would that ever be what you want? This is such an obvious issue, that's not a back door it's a front door.Supposedly everyone is using this, that's why everyone is vulnerable, but nobody noticed. Sure, there's probably comparably few developers working on the log4j code itself, but you don't need to do that. Also, maybe most people just bring it in as a depencency and don't read more than 3 lines of the docs, just enough to log single lines. But there's still got to be a large number of people who actually know the basic features it has (not the JNDI shit, just that it does any evaluation at all). And for each of them, at least 50% of competent developers should realize this is an issue. Even accounting for Sturgeon's law that makes a lot of people.
I bet this has been out in the wild and used for years by now, either by intelligence or hacker groups. Only now that the minecraft kiddies figured this out it's actually got noticed.
-
@topspin said in In Log4J WTF news today…:
even the PHP people have
mysql_real_escape_string_i_mean_it_this_time
To be fair…
Those names are come from the official MySQL C API, which PHP just lifts wholesale because it’s too lazy to offer a consistent naming scheme of its own.
Any practical difference between “PHP” and “MySQL API” is a different matter…
-
-
@kazitor said in In Log4J WTF news today…:
Any practical difference between “PHP” and “MySQL API” is a different matter…
Which one? PHP has the legacy API which has that nonsense in it (which was deprecated in 5.x and removed in 7.0), the MySQLi API since 2004 which is mostly class based but also has the real_escape deal because the official API does (with classic escape_string being an alias so you literally can't get it wrong in MySQLI) and of course PDO. The latter two of which also have native functionality for parameter binding and I believe both can do unbuffered queries, something the legacy API cannot.
And this one really was and is a bonehead problem on MySQL's end - escaping a string for a database needs to be aware of the current encoding, something escape_string wasn't but real_escape_string was.
-
@topspin Yeah, it's probably been used. If not by ciminals, then by governments for targeted attacks.
Not everyone use it though, despite it being a popular java logging framework, the projects I can remember the logging framework used did not use it. The ones I remember were using inhouse logging framework, JUL, Logback and JCL. There are so many logging frameworks for java it's silly.
-
@Carnage said in In Log4J WTF news today…:
There are so many logging frameworks for java it's silly.
… now how many of them do something similarly stupid like interpreting the data to be logged.
-
@Bulb said in In Log4J WTF news today…:
@Carnage said in In Log4J WTF news today…:
There are so many logging frameworks for java it's silly.
… now how many of them do something similarly stupid like interpreting the data to be logged.
I don't think many of them try to call out to other things to get executable code, but several of them have some unnecessarily "smart" stuff going on.
-
@Luhmann said in In Log4J WTF news today…:
status a week late but hey ... we did send out that e-mail to all customers to tell them there is no issue (because it is either not java or using an older version of log4j)
This you?
It's always Belgium.
-
@DogsB
You have no proof!
-
-
@topspin said in In Log4J WTF news today…:
how is it at all possible that this shit went unnoticed for so long?
Part of it is that it is a consequence of the complex substitution model they use (itself not something I was really all that aware of), part of it is that the substitutions were post-applied to the full log message — I would perhaps have expected them for the logging message template, but not for the actual message — and part of it is that the JNDI stuff did security using the goatse model. It's not helped by classic frameworkitis: with everything being super-configurable at runtime, it's hard to figure out where anything actually happens, or what the consequences of a capability actually are. (Access to JNDI was apparently put in there for the configuration code to use. I've no idea why post-processing of the log message was added, but it seems to have been functionality added a long time ago. That JNDI would do code loading from untrusted sources was a nasty shock; I'm really happy that I don't touch that shit directly in my own code.)
Because the root cause is in many ways the difficulty of audit caused by frameworkitis, I suspect that the general problem will occur in many other places too. Using a safe language won't save you if you then reconstruct the unsafety on top of it.
-
@Carnage said in In Log4J WTF news today…:
Not everyone use it though, despite it being a popular java logging framework, the projects I can remember the logging framework used did not use it.
It also relies on the systems being able to call out to the internet. We have some (3rd party) stuff that uses vulnerable log4j versions but they're behind firewalls and other network shenanigans that don't let them talk to arbitrary servers over the internet so they weren't actually vulnerable to be exploited.
-
@boomzilla Yeah, all the vulnerability exposures of late show how important it is to put systems in proper DMZ and limit egress from it. Because most production systems don't need to connect to outside internet.
-
@Bulb said in In Log4J WTF news today…:
@boomzilla Yeah, all the vulnerability exposures of late show how important it is to put systems in proper DMZ and limit egress from it. Because most production systems don't need to connect to outside internet.
It's kind of scary how many production system that actually can make outgoing calls
-
@Carnage And most of those who can't still can make outgoing DNS requests, which is almost as bad.
-
@Carnage said in In Log4J WTF news today…:
It's kind of scary how many production system that actually can make outgoing calls
For example, if you need to obtain additional claims (either OpenID or SAML) about the user who's just logged in that aren't directly in the token you've been given, that's a call out into the wild. And many of those services are hard to characterise for the purposes of firewalling. (Fortunately, you can set up a proxy server and track what's going on there.)
-
If you want to see an example of an exploit, some one posted it on CodeProject:
-
There's another one...
-
@loopback0 said in In Log4J WTF news today…:
There's another one...
It's getting a pretty thorough examination.
I wonder if the other big ones are having an equally close examination.
-
-
@loopback0 said in In Log4J WTF news today…:
There's another one...
From the CVE:
an attacker with permission to modify the logging configuration file
That's usually a fairly well locked down file (frequently co-deployed with the application's own executable code); if the attacker has permission to write to the filesystem, they're already deep into mischief-enabled territory. This is nearly nothing on the scale of CVE-2021-44228 at all.
Fix for most people is to upgrade the log4j version on the usual security update schedule, along with any other packages that need such.
-
@dkf said in In Log4J WTF news today…:
Fix for most people is to upgrade the log4j version on the usual security update schedule, along with any other packages that need such.
Yeah, but after the panic of the last couple of weeks that's not going to fly.
-
@dkf said in In Log4J WTF news today…:
@Carnage said in In Log4J WTF news today…:
It's kind of scary how many production system that actually can make outgoing calls
For example, if you need to obtain additional claims (either OpenID or SAML) about the user who's just logged in that aren't directly in the token you've been given, that's a call out into the wild. And many of those services are hard to characterise for the purposes of firewalling. (Fortunately, you can set up a proxy server and track what's going on there.)
As far as I can tell, OpenID does not provide any additional claims and with OpenID Connect or SAML you have defined list of supported identity providers, so you can easily white-list them on a proxy and block everything else. The cases that can't be defined with a whitelist on a proxy are much rarer.
Of course you need a proxy to be able to block DNS for the services in any case.
-
@El_Heffe said in In Log4J WTF news today…:
@Carnage said in In Log4J WTF news today…:
I'd love if Java wasn't as retarded about logging as it is.
I'd love if Java wasn't as retarded about anything as it is
For some cases, it would help for it to be a little more retarded. Git has gotten good mileage.
-
@dkf said in In Log4J WTF news today…:
if you need to obtain additional claims (either OpenID or SAML) about the user who's just logged in that aren't directly in the token you've been given, that's a call out into the wild because you have left the defined safety of the protocol in response to misadministration.
-
@Gribnit You most usually need to make external calls because you are supporting bearer tokens, which is very useful when you've got moderately complex usage patterns (such as when you're a resource service provider but not the provider of the GUI front end). The bearer token is not necessarily going to directly carry all the claims that you're interested in, so you need to check back with the issuer to get the actual claim set that you're authorized to receive.
(The bearer token will carry with it an audience; if you're not part of the audience for the token, you'll be unable to verify the token with the service provider, and will be restricted to whatever info is directly in the token. Which usually doesn't include even the basic
openid
claim set.)
-
Make sure you stay up to date on your boosters!
-
NetRise bills itself as an "extended IoT" (xIoT) security firm.
Extended Io — is that when the won't stop?
-
@HardwareGeek it’s when the IoS device doesn’t just bring your whole house down, but everybody else’s too.
-
@dkf said in In Log4J WTF news today…:
the usual security update schedule, along with any other packages that need such.
My work's security update schedule seems to be "whenever someone updates a library to use a new feature, and then suddenly has to update a bunch of related libraries." Libraries not touched by the new feature don't get updated.
-
@PotatoEngineer The goat.se approach to security risk management.
-
@dkf said in In Log4J WTF news today…:
@PotatoEngineer The goat.se approach to security risk management.
We're still on JQuery 2.0, because upgrading to 3.x (which doesn't have known security issues) changes the API on a frequently-used function, and it would take a while to update all of those calls.
(Okay, there was a major refactor a while ago that means the function is called much less frequently, but updating code takes effort better spent on not updating that code...)
-
@PotatoEngineer is that not solvable with JQMigrate?
-
@dkf said in In Log4J WTF news today…:
goat.se
That doman is still available. Do you want to purchase it?
-
@boomzilla said in In Log4J WTF news today…:
Make sure you stay up to date on your boosters!
Lies! Propaganda! The new logging packages don't prevent downgrading back to Log4J 1.x!
-
@Gribnit said in In Log4J WTF news today…:
@boomzilla said in In Log4J WTF news today…:
Make sure you stay up to date on your boosters!
Lies! Propaganda! The new logging packages don't prevent downgrading back to Log4J 1.x!
Don't have to downgrade if you never upgraded.
-