201–210 of 531 posts
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
Earlier quoted context omitted.
Note that the formatMsgNoLookups workaround only applies to recent versions of the log4j library, while it's still unclear how far back this bug may stretch. Other options for patching are detailed in the thread: https://github.com/apache/logging-log4j2/pull/608#issuecomme... mentions that just removing the class providing the vulnerable behavior works well, and https://github.com/Glavo/log4j-patch is a JAR that you…
The 'formatMsgNoLookups' property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the 'formatMsgNoLookups=true' mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0, because it then becomes the default behavior [2][3]. If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are: - Modi…
https://www.lunasec.io/docs/blog/log4j-zero-day/#temporary-m...
For instance, when starting with systemd, add `Environment=JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true` to your service file.
You should find `Command line argument: -Dlog4j2.formatMsgNoLookups=true` in catalina.out
so the question is, is it safe to log unsanitized inputs? i've argued no given the complexity of today's logging pipelines and caught a lot of flak for it in the past... now i feel vindicated.
In a properly designed system, it should be perfectly safe. The problems come from how the log input is processed. If all you're doing is appending it to a file or adding a row to a database table, that should be no problem. In the database case it's no different to adding any other record supplied by the user. In the case of a file, consideration has to be given about what assumptions other tools that process that f…
AND escaping any control/unicode* characters. encodeURIComponent() if that's the best you have, but log files need to be safe against unsuspecting sysadmins viewing/grepping/catting these. and even NT4 had a blue screen bug you could trigger by TYPE-ing the wrong file in a console..
(*) well if you need to, whitelist some safe ranges, but there's scary stuff in unicode eg with the bi-directional escapes or zero width spaces to make viewing/grepping hard.
Earlier quoted context omitted.
> just a wrapper around printf which adds a timestamp and a log-level That's a pretty naive view of what's needed in an enterprise logging solution. logging to files, separate logging, remote logging, log rotation, logging 3rd party code... Of course if you're simply sending lines to the terminal in a simple program you don't need log4j. But once you scale, you'd be spending 3 weeks implementing what you get for free…
IMO enterprise logging solution should write logs to file and rotate files. The rest should be done by a separate services like Loki or Logstash.
For example, Hibernate has full query logging built in, but even if you filter locally with some logging demon, pushing 100 - 1k queries / second to stdout or a file is going to cripple performance.
With a logging framework like Log4J or SLF4J you can have this query logging, and you can enable it within 1 monitor run (usually 60s) at runtine and disable it 4-5 minutes later. This is very, very powerful in production.
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 you are maintaining an open source project, Dependency Check is mostly great (there are some issues every now and then with false positives, but the maintainers are great and responsive and they deal with reports very quickly).
There are also plugins for several building tools (e.g. sbt for Scala projects).
1: https://owasp.org/www-project-dependency-check/
EDIT: this may help answering the question "do I use log4j?", because transitive dependencies can be complicated!
Earlier quoted context omitted.
While that's an interesting vector for attack, is it realistically an issue? Terminals are run as root all the time. I would guess any mainstream ones are well reviewed to not have such exploits work. Are you aware of any actual attacks exploiting terminal parsing in the wild?
> Terminals are run as root all the time Is it really common to run terminals as root? I can't remember the last time I did. Sure, I open a terminal as my user, and then run 'sudo bash' to get a shell as root, but the terminal is still running as my user. Were you meaning something else?
Also one common way to install "DevOps" stuff piping scripts from curl (and them being asked for root)
Earlier quoted context omitted.
These "special" strings that Log4j parse must be in the formatting string though, right? External Strings should normally be logged as parameters, not included in the format String. For example: // this is ok log.debug("user-agent={}", userAgent); // this is bad log.debug("user-agent=" + userAgent); Does this vulnerability still work on the first case? EDIT: the answer is yes, just tried it myself.
wow it's like SQL injection but even when using user input as parameter it does not get sanitised. Really curious what was motivation for such behaviour.
To folks wondering what the issue is about, I'll give a short summary that I myself needed. Typically a logging library has one job to do: swallow the string as if it's some black box and spit it elsewhere as per provided configurations. Log4j though, doesn't treat strings as black boxes. It inspects its contents and checks if it contains any "variables" that need to be resolved before spitting out. Now there's a bun…