251–260 of 531 posts
Logback has an interesting commit[1]: "disassociate logback from log4j 2.x as much as possible". They also updated their landing page [2]: "Logback is intended as a successor to the popular log4j project, picking up where log4j 1.x leaves off. Fortunately, logback is unrelated to log4j 2.x and does not share its vulnerabilities." Can't say I blame them. [1] https://github.com/qos-ch/logback/commit/b810c115e363081afc7…
This is such a cheap move by Logback, which comes from the former lead developer of Log4j 1. I used to like it for its technical merits: it's really much better than Log4j 1. But its development has stagnated, and it doesn't offer anything over Log4j2 nowadays. Furthermore, it's not an Apache project, it doesn't even use the Apache License, but LGPL.
I would say that a logging framework also needs to be boring. I don't understand why string interpolation with access to the JNDI context needs to be in core Log4j2.
Less is more so to say.
Earlier quoted context omitted.
Best guess: Resolving some kind of entity name to a username for some weird auditing requirement few people have ever heard of. It's the kind of feature I've seen in some software in the past. That's just a guess though.
The question isn't about the purpose of the feature. The question is why it's implemented with string parsing. In C, it's unsafe to do printf(string_variable); because variable will get parsed as a format string. The way to solve the vulnerability is printf("%s", string_variable); Is that the same in Java logging libraries? Is it well-known that the logged value will be parsed? What's the safe way to log a value in J…
As a possible solution you can set MDC variables at the higher level, they are bound to the current thread, and reference them in the format string, and unset them after processing the entity. It's not a great solution due to temporal coupling, and you typically print it outside of an individual logging statements (e.g. add it to all logging statements), but it definitely beats drilling dozens of methods with the diagnostic identifiers.
always always always keep use of 3rd party java libraries to a minimum. While not necessarily useful in this case, I often see answers on stackoverflow saying "oh just use this apache commons or guava library" when there's a perfectly sound and easy way of just doing it in java. Makes me want to scream
When I started working with Scala, it really surprised me how the JVM world deals with dependencies (include an upstream jar directly in the project, as opposed to the Linux distro model where you use your distributor packages so you have security and bug fixes). I'm a big fan of Dependency Check[1]. There are hosted services that can give you security scans, but if you don't have access to that (some have a cost) or…
good luck getting all your versions to be compatible if you do that. Oh, now your java app can only run on Ubuntu 16.04? But our customers use CentOS 7? Guess they're out of luck.
> EDIT: this may help answering the question "do I use log4j?", because transitive dependencies can be complicated!
Just run `mvn dependency:tree` or the gradle equivalent.
Technically it's a format string vulnerability that causes a server-side request forgery that can be abused to execute code on the remote system. I wonder of any bug bounties would give you a chain bonus for this one lol
Interestingly, no, the tag doesn't have to be in the formatting string. See https://news.ycombinator.com/item?id=29507511 .
The fact that the specific interpolation causes a server-side request is what makes it a server-side request forgery. This isn’ta url input that’s getting an unexpected scheme, the interpolation is required.
Lastly the fact that the server-side request forgery causes unexpected code to be downloaded and executed creates the RCE.
This may seem like needless pedantry, but the reason it’s important is that there are likely other bugs hidden in here, and the RCE is just getting all the attention. For example, our network diallows egress except through a proxy. The initial JNDI request over LDAP isn’t getting anywhere. So we aren’t exposed per the POCs I’ve seen. BUT if JNDI supported HTTPS or data url schemes we would. Also if the interpolation allows any other deserialization attacks through inline payloads we would.
Does anyone in here know what url schemes are valid for JNDI and/or this bug in particular? The example is LDAP but is that the only one JNDI supports? Would HTTPS or even data urls work?
https://docs.oracle.com/javase/tutorial/jndi/overview/index.... says that LDAP, DNS, RMI Registry, and CORBA Name Service are included in Java, and others may be discovered at load time (but I bet they aren't because that's very niche).
DNS could be gnarly if serialized objects can be stored in txt records.
Earlier quoted context omitted.
So is this fixed in 1.18?
The vanilla launcher will automatically patch 1.12 to 1.18, and 1.18.1 includes a specific permanent fix for it by switching to a newer Log4j version. There is a workaround that fixes it for 1.13 to 1.18 only: Simply add `-Dlog4j2.formatMsgNoLookups=true` to your Java parameters What about Minecraft not use any Minecraft versions before 1.12 right now. [1]: https://twitter.com/slicedlime/status/1469150995842310144
Probably there isn't a broad agreement on ethical standards related to vulnerability disclosure but is it really still a net benefit when people disclose vulnerabilities without even them knowing the implications, that are clearly not patched, let alone giving users of the software time to do anything about it.
I feel we have gotten pretty far away from Tavis Ormandy working with Cloudflare to clean up the issue before anything is published.
Do I misunderstand something or this is clearly the type of issue that will be misused widely?
EDIT: was not clear to me that Lumio has done only the writeup and not the original researchers finding the vulneraility mea culpa Lunasec, you're doing god's work! Probably there isn't a broad agreement on ethical standards related to vulnerability disclosure but is it really still a net benefit when people disclose vulnerabilities without even them knowing the implications, that are clearly not patched, let alone g…