4 ms·

I would expect that a large portion of cybersecurity workers are far too busy trying to properly address Log4shell issues at their organizations to be posting o

by ufmace 5y ago

I would expect that a large portion of cybersecurity workers are far too busy trying to properly address Log4shell issues at their organizations to be posting on HN

datavirtue 5y ago
Most of them wasting time remediating applications that can't be exploited. If only we had sanitized our inputs. We sanitized all the form parameters! Did you sanitize the user agent string? What. This is one of the reasons why I avoid log4j and log4net like a real weirdo. People use a logging framework because they are supposed to--so we can send logs to something sensible instead of paying a billion dollars to suck files from an ec2 instance into Splunk. We use log4j and still spend a GDP on splunk sucking in files. 99% of these people running around with their hair on fire could have just wrote to a log file with three lines of code. Instead they mvn a whole fucking library for no reason. Well, they were supposed to. It's the right thing to do, according to some blog posts.
- ygjb 5y ago
  > 99% of these people running around with their hair on fire could have just wrote to a log file with three lines of code. Instead they mvn a whole fucking library for no reason The fact that you think there is "no reason" to address the issue of logging through a method other than writing three additional lines of code shows that you really have no comprehension of how or why logging frameworks provide benefits (even if some of the inclusions like JNDI are ludicrous and should been defaulted off, or even behind a build flag, with big red warning labels).
  - datavirtue 5y ago
    Of course I do. Just that 99% of the people wasting their life and money remediating this issue did not need any of that, certainly didn't use most of it, and definitely didn't need the features causing this mess. I have yet to stumble on an app that uses any logging features other than writing to a file. And yet the default is to mvn log4j to do that because they don't want to look foolish doing it the simple way or "they might need it."
    - ygjb 5y ago
      Congratulations! log4j is to feature rich to satisfy the requirements of your limited experience! The JNDI string expansion and lookups was a pants on head stupid feature, but having highly configurable logging is super helpful when building and debugging systems at scale, both when you building and testing, and when you are scaling up so that you can granularly tune what is logging and where. This is true whether it's written in python, golang, rust, c, or any other language. If you don't know that, then perhaps you should try branching out in your experience.
- ufmace 5y ago
  Sanitizing inputs requires you to know what you're sanitizing against. Nobody knew about all these expressions that log4j would accept anywhere until a few weeks ago, so nobody could have sanitized them out of inputs. Logging to a text file is nice for a toy app. For large-scale Production apps, you're gonna need log rotation to not overwhelm your disk space, transport to a centralized service for aggregation and bulk querying, and a good mechanism to append some tags about the request, service, instance etc to the log data to make it easy to query. That's not so easy without a nice logging framework.

by ufmace 5y ago

I would expect that a large portion of cybersecurity workers are far too busy trying to properly address Log4shell issues at their organizations to be posting on HN

datavirtue 5y ago

Most of them wasting time remediating applications that can't be exploited. If only we had sanitized our inputs. We sanitized all the form parameters! Did you sanitize the user agent string? What. This is one of the reasons why I avoid log4j and log4net like a real weirdo. People use a logging framework because they are supposed to--so we can send logs to something sensible instead of paying a billion dollars to suck files from an ec2 instance into Splunk. We use log4j and still spend a GDP on splunk sucking in files. 99% of these people running around with their hair on fire could have just wrote to a log file with three lines of code. Instead they mvn a whole fucking library for no reason. Well, they were supposed to. It's the right thing to do, according to some blog posts.

ygjb 5y ago
> 99% of these people running around with their hair on fire could have just wrote to a log file with three lines of code. Instead they mvn a whole fucking library for no reason The fact that you think there is "no reason" to address the issue of logging through a method other than writing three additional lines of code shows that you really have no comprehension of how or why logging frameworks provide benefits (even if some of the inclusions like JNDI are ludicrous and should been defaulted off, or even behind a build flag, with big red warning labels).
- datavirtue 5y ago
  Of course I do. Just that 99% of the people wasting their life and money remediating this issue did not need any of that, certainly didn't use most of it, and definitely didn't need the features causing this mess. I have yet to stumble on an app that uses any logging features other than writing to a file. And yet the default is to mvn log4j to do that because they don't want to look foolish doing it the simple way or "they might need it."
  - ygjb 5y ago
    Congratulations! log4j is to feature rich to satisfy the requirements of your limited experience! The JNDI string expansion and lookups was a pants on head stupid feature, but having highly configurable logging is super helpful when building and debugging systems at scale, both when you building and testing, and when you are scaling up so that you can granularly tune what is logging and where. This is true whether it's written in python, golang, rust, c, or any other language. If you don't know that, then perhaps you should try branching out in your experience.
ufmace 5y ago
Sanitizing inputs requires you to know what you're sanitizing against. Nobody knew about all these expressions that log4j would accept anywhere until a few weeks ago, so nobody could have sanitized them out of inputs. Logging to a text file is nice for a toy app. For large-scale Production apps, you're gonna need log rotation to not overwhelm your disk space, transport to a centralized service for aggregation and bulk querying, and a good mechanism to append some tags about the request, service, instance etc to the log data to make it easy to query. That's not so easy without a nice logging framework.