4 ms·
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 s
by 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 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]