4 ms·
Struggling with what to call it, but something like "enabled by default obscure macro substitution that very few people actually use" was the biggest problem to
by tyingq 4y ago
Struggling with what to call it, but something like "enabled by default obscure macro substitution that very few people actually use" was the biggest problem to me. A lot of the log4j fixes was to turn parts of that off.
- gz5 4y agoit is a good description. the issue is our code has lots of these types of patterns. look at sql injections alone. certainly it is our job to tighten up our software - but we are very vulnerable with the current model of the 'authenticate after connect' networking model (L3 access mainly by firewalls...with stronger auth only later at L7). said the other way...imagine if the log4j attackers couldn't even get to my firewall unless they were already authorized to have access to the specific service they are trying to access.
- tyingq 4y agoI do see that, but there were exploit paths that didn't require doing anything you would block with a firewall or need specific access rights for. Like if I set my user-agent to contain such a macro and connect to your public webserver. If you had webserver logging and log4j configured a certain way, then I'm running arbitrary code. Maybe I can't see the output right away, but it's running.
- deleted 4y ago[deleted]