6 ms·

More evidence that user provided data shouldn’t be logged at all.

by xigency 5y ago

staticassertion 5y ago
That sounds like it would make debugging very hard for 0 benefit to anyone not using log4j.
jacquesm 5y ago
Logging can easily be a legal requirement.
- pmarreck 5y ago
  I'm thinking anyone who has to comply with Sarbanes-Oxley, for starters, potentially
- AtNightWeCode 5y ago
  Welcome to GDPR and hello to trace log everything. :)
  - jacquesm 5y ago
    This has absolutely nothing to do with the GDPR. In fact, the GDPR and various data retention laws are at odds with each other which is why the GDPR has a very explicit exemption for this.
    - AtNightWeCode 5y ago
      Not sure what you are answering. If you for instance expose an endpoint by accident and then can't show logs for the access to it, you are going to have a problem in one of those GDPR hearings. The irony of GDPR is that you may end up with more logging of user data, not less.
      - jacquesm 5y ago
        Explain 'one of those GDPR hearings'. I'm pretty familiar with the GDPR and everything that comes with it, I've never even heard of the term 'GDPR hearing'.
        AtNightWeCode 5y ago
        Maybe it is not handled the same way depending on where you operate from but where I live you are supposed to report any potential data leak of GDPR sensitive data to the local authorities. I do not know what the criteria is that makes you end up being questioned about it though. I been at such meetings over silly things.
        jacquesm 5y ago
        The reporting requirements are the same all over Europe, it's a 'better safe than sorry' mechanism put in place after companies routinely wiped their data breaches under the rug in the hope that nobody would notice. Once you get to that stage there can be a follow up to gather more information, and that follow up then usually results in some advice or no further action. In rare cases - typically the ones where gross negligence or willful transgression of the rules was established - there will be a fine and if it is a repeat occurrence that fine can be quite substantial. Also you don't have to report 'potential leaks', only actual leaks. So I think that in the case of your hypothetical end-point the logging isn't a GDPR requirement, but if your endpoint ends up leaking data then the log can help you to establish if and if so how much data was exfiltrated. But that does not mean that the GDPR requires you to have logs, though, having access logs for your endpoints is a fairly standard thing and not having them is going to raise a few eyebrows, especially if you are also reporting a breach. Where there are logging requirements: data retention laws, SOX, fintech, tax regulation, AML.
        AtNightWeCode 5y ago
        At companies I worked with repute is key. Companies with employee count in the range of 10 to 50k. The legal departments will report any potential breach. As a developer you can decide what is logged but not much about anything else in the business. You as a developer or tech lead will most likely be held accountable.
samhw 5y ago
There are countless ways that this vulnerability could be an issue irrespective of whether user-provided data are being logged. Attackers achieving RCE on a machine in your infrastructure is likely extremely bad for most realistic architectures.
- jacquesm 5y ago
  I think the main takeaway for all of these is that tricky and possibly unexpected behavior should always be explicitly enabled. And it's not the first time that we are learning that particular lesson so there really are no excuses.
jrochkind1 5y ago
It is pretty valuable to my debugging and general observability to log the URLs requested (including query component), which is user-provided data. I'm not saying I couldn't maintain my app operations without logging URI's including query strings... but it would definitely be more challenging. Then there's the user-agent header, which also can be pretty valuable to debugging and other operations. Although this one is easier not to log. In my current logs, I'm seeing attempts to compromise log4j vulnerability in both URL query string and user-agent. (Which of course I would not know about if I weren't logging them). This particular application has no Java involved, so is not vulnerable.
hn_throwaway_99 5y ago
It's not difficult to take user-entered data and just dump it to a log file. I'm pretty positive none of these vulnerabilities exist with System.out.println. The fundamental problem is that, pretty surprisingly, log4j was running the same parsing and logic on user-entered strings as they did format strings. That's essentially the root cause of all this - log4j shouldn't be attempting to parse this data at all. So many severe vulnerabilities are due to the complexities of parsing potentially malicious user input - just look at all the severe iMessage bugs. While many other apps do have a fundamental requirement to parse this input, there is no reason a logging library needs to do it.
- a-dub 5y ago
  > It's not difficult to take user-entered data and just dump it to a log file. I'm pretty positive none of these vulnerabilities exist with System.out.println. yes, but there can be (and have been) vulnerabilities in terminal emulators, terminal multiplexers, text editors, databases, web renderers and all manner of tools that can be used to store the contents of or view that file. your argument makes sense that the logging library should not be attempting to parse the log strings, but think about all the other millions of lines of code that could potentially try to parse that data as well. patch log4j one day and the next you find a bug in some colorizer javascript library or in the sixel support for the terminal emulator. people add parsing everywhere. i think ideally that all user supplied data should be sanitized in the strictest possible manner before anything is done with it, including logging.
  - hn_throwaway_99 5y ago
    So you never browse the web?
    - a-dub 5y ago
      sure. i don't think i'm articulating my real point well enough. web browsers and all of their components get audited. because they process potentially malicious data as their core function, they see A LOT of attention in terms of hardening. the point that i'm trying to make is: the amount of software that doesn't immediately and apparently touch potentially malicious data is absolutely enormous and the number of paths that data can take to touch that software is even more enormous. yes, one can put forth good principles for "building codes" for software and yes, one should... but there's an awful lot of software out there that is not up to code (where the craft is so young that the idea of a code isn't even close to being finalized) and it won't be for a very long time. that being the actual on the ground situation, what is one simple thing that individual developers can do to help prevent catastrophes? always sanitize inputs. moreover, it's much easier to find and audit every place where data is accepted from untrusted sources than it is to find every place where data may be parsed.
dreamcompiler 5y ago
Ther's nothing wrong with logging user-provided data. What's wrong is creating a mechanism where user-provided data can be interpreted as a program.
skwirl 5y ago
User data shouldn't be processed at all. You never know where there will be a vulnerability. So you turn off logging so you have no idea what pages your customers are now requesting (phew!) but you can still be vulnerable to SQL injection attacks, buffer overflow attacks, etc. when you are processing the user data. Best to just reject it all.
- tekknik 5y ago
  The server is happier this way as well, finally people have gotten off its lawn!

More evidence that user provided data shouldn’t be logged at all.

staticassertion 5y ago

That sounds like it would make debugging very hard for 0 benefit to anyone not using log4j.

jacquesm 5y ago

Logging can easily be a legal requirement.

pmarreck 5y ago
I'm thinking anyone who has to comply with Sarbanes-Oxley, for starters, potentially
AtNightWeCode 5y ago
Welcome to GDPR and hello to trace log everything. :)
- jacquesm 5y ago
  This has absolutely nothing to do with the GDPR. In fact, the GDPR and various data retention laws are at odds with each other which is why the GDPR has a very explicit exemption for this.
  - AtNightWeCode 5y ago
    Not sure what you are answering. If you for instance expose an endpoint by accident and then can't show logs for the access to it, you are going to have a problem in one of those GDPR hearings. The irony of GDPR is that you may end up with more logging of user data, not less.
    - jacquesm 5y ago
      Explain 'one of those GDPR hearings'. I'm pretty familiar with the GDPR and everything that comes with it, I've never even heard of the term 'GDPR hearing'.
      - AtNightWeCode 5y ago
        Maybe it is not handled the same way depending on where you operate from but where I live you are supposed to report any potential data leak of GDPR sensitive data to the local authorities. I do not know what the criteria is that makes you end up being questioned about it though. I been at such meetings over silly things.
        jacquesm 5y ago
        The reporting requirements are the same all over Europe, it's a 'better safe than sorry' mechanism put in place after companies routinely wiped their data breaches under the rug in the hope that nobody would notice. Once you get to that stage there can be a follow up to gather more information, and that follow up then usually results in some advice or no further action. In rare cases - typically the ones where gross negligence or willful transgression of the rules was established - there will be a fine and if it is a repeat occurrence that fine can be quite substantial. Also you don't have to report 'potential leaks', only actual leaks. So I think that in the case of your hypothetical end-point the logging isn't a GDPR requirement, but if your endpoint ends up leaking data then the log can help you to establish if and if so how much data was exfiltrated. But that does not mean that the GDPR requires you to have logs, though, having access logs for your endpoints is a fairly standard thing and not having them is going to raise a few eyebrows, especially if you are also reporting a breach. Where there are logging requirements: data retention laws, SOX, fintech, tax regulation, AML.
        AtNightWeCode 5y ago
        At companies I worked with repute is key. Companies with employee count in the range of 10 to 50k. The legal departments will report any potential breach. As a developer you can decide what is logged but not much about anything else in the business. You as a developer or tech lead will most likely be held accountable.

samhw 5y ago

There are countless ways that this vulnerability could be an issue irrespective of whether user-provided data are being logged. Attackers achieving RCE on a machine in your infrastructure is likely extremely bad for most realistic architectures.

jacquesm 5y ago
I think the main takeaway for all of these is that tricky and possibly unexpected behavior should always be explicitly enabled. And it's not the first time that we are learning that particular lesson so there really are no excuses.

jrochkind1 5y ago

It is pretty valuable to my debugging and general observability to log the URLs requested (including query component), which is user-provided data. I'm not saying I couldn't maintain my app operations without logging URI's including query strings... but it would definitely be more challenging. Then there's the user-agent header, which also can be pretty valuable to debugging and other operations. Although this one is easier not to log. In my current logs, I'm seeing attempts to compromise log4j vulnerability in both URL query string and user-agent. (Which of course I would not know about if I weren't logging them). This particular application has no Java involved, so is not vulnerable.

hn_throwaway_99 5y ago

It's not difficult to take user-entered data and just dump it to a log file. I'm pretty positive none of these vulnerabilities exist with System.out.println. The fundamental problem is that, pretty surprisingly, log4j was running the same parsing and logic on user-entered strings as they did format strings. That's essentially the root cause of all this - log4j shouldn't be attempting to parse this data at all. So many severe vulnerabilities are due to the complexities of parsing potentially malicious user input - just look at all the severe iMessage bugs. While many other apps do have a fundamental requirement to parse this input, there is no reason a logging library needs to do it.

a-dub 5y ago
> It's not difficult to take user-entered data and just dump it to a log file. I'm pretty positive none of these vulnerabilities exist with System.out.println. yes, but there can be (and have been) vulnerabilities in terminal emulators, terminal multiplexers, text editors, databases, web renderers and all manner of tools that can be used to store the contents of or view that file. your argument makes sense that the logging library should not be attempting to parse the log strings, but think about all the other millions of lines of code that could potentially try to parse that data as well. patch log4j one day and the next you find a bug in some colorizer javascript library or in the sixel support for the terminal emulator. people add parsing everywhere. i think ideally that all user supplied data should be sanitized in the strictest possible manner before anything is done with it, including logging.
- hn_throwaway_99 5y ago
  So you never browse the web?
  - a-dub 5y ago
    sure. i don't think i'm articulating my real point well enough. web browsers and all of their components get audited. because they process potentially malicious data as their core function, they see A LOT of attention in terms of hardening. the point that i'm trying to make is: the amount of software that doesn't immediately and apparently touch potentially malicious data is absolutely enormous and the number of paths that data can take to touch that software is even more enormous. yes, one can put forth good principles for "building codes" for software and yes, one should... but there's an awful lot of software out there that is not up to code (where the craft is so young that the idea of a code isn't even close to being finalized) and it won't be for a very long time. that being the actual on the ground situation, what is one simple thing that individual developers can do to help prevent catastrophes? always sanitize inputs. moreover, it's much easier to find and audit every place where data is accepted from untrusted sources than it is to find every place where data may be parsed.

dreamcompiler 5y ago

Ther's nothing wrong with logging user-provided data. What's wrong is creating a mechanism where user-provided data can be interpreted as a program.

skwirl 5y ago

User data shouldn't be processed at all. You never know where there will be a vulnerability. So you turn off logging so you have no idea what pages your customers are now requesting (phew!) but you can still be vulnerable to SQL injection attacks, buffer overflow attacks, etc. when you are processing the user data. Best to just reject it all.

tekknik 5y ago
The server is happier this way as well, finally people have gotten off its lawn!