5 ms·

>The underlying problem of Log4Shell is input sanitization While we can point to Log4j’s “message substitution” feature, there are infinite similar "features"

by gz5 4y ago

>The underlying problem of Log4Shell is input sanitization While we can point to Log4j’s “message substitution” feature, there are infinite similar "features" in (whatever software) which can be exploited IF there is public network access in and out of (whatever software). So I would argue the most significant underlying problem for exploits at this scale is public network access. Yes, even if access in and out was limited to strongly authenticated and authorized users with least privileged access, we could still have insider attacks. But we would drastically reduce the attack surface and blast radius.

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 ago
  it 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 ago
    I 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]
jacques_chester 4y ago
Network accessibility is not within the control of Log4j.

by gz5 4y ago

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 ago
it 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 ago
  I 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]

jacques_chester 4y ago

Network accessibility is not within the control of Log4j.