Discussion
The simplest mitigation is a setting that says don't accept.
Updating to the latest version isn't difficult either. ( though obviously regression test to see what else your script kiddies have done that they shouldn't)
What most people miss is that the zero day is because someone has been bother to work out the exploit ( or stumbled across it ) - this vulnerability has been known about since 2017.
Updating to the latest version isn't difficult either. ( though obviously regression test to see what else your script kiddies have done that they shouldn't)
What most people miss is that the zero day is because someone has been bother to work out the exploit ( or stumbled across it ) - this vulnerability has been known about since 2017.
Chozza said:
The simplest mitigation is a setting that says don't accept.
Updating to the latest version isn't difficult either. ( though obviously regression test to see what else your script kiddies have done that they shouldn't)
What most people miss is that the zero day is because someone has been bother to work out the exploit ( or stumbled across it ) - this vulnerability has been known about since 2017.
After I retired. Phew.Updating to the latest version isn't difficult either. ( though obviously regression test to see what else your script kiddies have done that they shouldn't)
What most people miss is that the zero day is because someone has been bother to work out the exploit ( or stumbled across it ) - this vulnerability has been known about since 2017.
Theraveda said:
How many decades has "Injection" been on the OWASP Top 10?
Blaming people for security issues that seem obvious in hindsight without knowing the full context is not helpful to anyone.Edited by Theraveda on Sunday 12th December 17:03
Number 9 on the list was security logging and monitoring failures, so in this trying to follow OWASP best practices by doing something like logging an unknown header could be exactly what got you into this situation.
Log4j is the most commonly used logging framework in all of Java and java is vast, used on billions of devices, the majority of them not web application servers, so a lot of people involved with Java won't be particularly familiar with OWASP and injection risk may not be high on the agenda, To fair to the people working on log4j they implemented a setting to be able to turn it off completely so I think there was an awareness of this risk it's just it's significance was slightly under estimated.
For people writing Java Web apps it probably should have been high on the agenda, but it's not unreasonable for them to expect passing something to a logging framework to be benign.
This was an unsafe setting that could easily be made safe with a single flag it didn't matter that reasonable numbers of developers spotted the potential issue because they would have just set the flag and made thier app safe, they had no reason to request an upstream code change, and no reason to examine the wider context of should this be considered an unsafe default impacting everyone else.
e-honda said:
Theraveda said:
How many decades has "Injection" been on the OWASP Top 10?
Blaming people for security issues that seem obvious in hindsight without knowing the full context is not helpful to anyone.I wrote the application security standards for one of the worlds largest banks. Log4j breaks half-a-dozen of the rules in that standard. And running it Internet facing breaks several more.
Edited by Zumbruk on Thursday 16th December 11:23
Zumbruk said:
I wrote the application security standards for one of the worlds largest banks. Log4j breaks half-a-dozen of the rules in that standard. And running it Internet facing breaks several more.
Can you give me an example?I deal with a lot of security standards and security procedures and in my experience standards, particularly organisation wide policies typically don't have rules they have requirements, and 1 particular piece of software that does not meet the requirements alone can be augmented be to meet them. So a statement that X software breaks many rules just doesn't make any sense to me.
If you have to sell Cloudflare to your CFO or similar, it's worth shouting about things like this.
https://blog.cloudflare.com/protection-against-cve...
Cloudflare had added three rules to their ruleset last Friday 10th which blocked the exploitation of this vulnerability. If you have a commercial site, it's well worth looking at Cloudflare to protect you. https://www.cloudflare.com/en-gb/what-is-cloudflar...
I don't work for them, just a very happy customer.
https://blog.cloudflare.com/protection-against-cve...
Cloudflare had added three rules to their ruleset last Friday 10th which blocked the exploitation of this vulnerability. If you have a commercial site, it's well worth looking at Cloudflare to protect you. https://www.cloudflare.com/en-gb/what-is-cloudflar...
I don't work for them, just a very happy customer.
e-honda said:
Zumbruk said:
I wrote the application security standards for one of the worlds largest banks. Log4j breaks half-a-dozen of the rules in that standard. And running it Internet facing breaks several more.
Can you give me an example?
Edited by Zumbruk on Thursday 16th December 14:38
Chozza said:
The simplest mitigation is a setting that says don't accept.
Updating to the latest version isn't difficult either. ( though obviously regression test to see what else your script kiddies have done that they shouldn't)
What most people miss is that the zero day is because someone has been bother to work out the exploit ( or stumbled across it ) - this vulnerability has been known about since 2017.
Upgrading is easy enough if you're aware you're running it.Updating to the latest version isn't difficult either. ( though obviously regression test to see what else your script kiddies have done that they shouldn't)
What most people miss is that the zero day is because someone has been bother to work out the exploit ( or stumbled across it ) - this vulnerability has been known about since 2017.
The problem comes when it's bundled in some other software - We've got some old ColdFusion instances, we don't actively use Log4J but it's bundled in ColdFusion and probably a load of other Java based frameworks.
Zumbruk said:
The Log4j exploit relies on accepting a string handed to the service by a (potentially) untrusted source, interpreting that string without sanitising it, establishing a connection to another untrusted source, downloading executable content from that source and running it. That's 6 no-no's just off the top of my head.
Yes I understand the exploit I've spent quite a lot of time work on issues around it this week.Edited by Zumbruk on Thursday 16th December 14:38
You have claimed "Log4j breaks half-a-dozen of the rules in that standard" but you actually are describing certain usages with certain configurations breaking the rules.
If your security requirements and auditing were enough to pick up this potential behaviour and ensure this never affected you great the system works for you.
If they didn't pick it up and a vulnerability crept in then to point the finger at log4j2 is exactly the kind of unhelpful behaviour I am talking about.
e-honda said:
Zumbruk said:
The Log4j exploit relies on accepting a string handed to the service by a (potentially) untrusted source, interpreting that string without sanitising it, establishing a connection to another untrusted source, downloading executable content from that source and running it. That's 6 no-no's just off the top of my head.
Yes I understand the exploit I've spent quite a lot of time work on issues around it this week.Edited by Zumbruk on Thursday 16th December 14:38
You have claimed "Log4j breaks half-a-dozen of the rules in that standard" but you actually are describing certain usages with certain configurations breaking the rules.
If your security requirements and auditing were enough to pick up this potential behaviour and ensure this never affected you great the system works for you.
If they didn't pick it up and a vulnerability crept in then to point the finger at log4j2 is exactly the kind of unhelpful behaviour I am talking about.
Edited by Zumbruk on Thursday 16th December 15:38
"Log4j breaks half-a-dozen of the rules in that standard"
At the most simple level - it default to allow rather than deny.
The recent update just changes that default - which is the same as the workaround are applying
Security rules are pretty simple
Don't connect things you don't need , Don't install packages/software you aren't using , Don't open port/API/interfaces that aren't needed.
and don't ignore stuff because you think you are behind a firewall, dmz, not internet facing
At the most simple level - it default to allow rather than deny.
The recent update just changes that default - which is the same as the workaround are applying
Security rules are pretty simple
Don't connect things you don't need , Don't install packages/software you aren't using , Don't open port/API/interfaces that aren't needed.
and don't ignore stuff because you think you are behind a firewall, dmz, not internet facing
Chozza said:
"Log4j breaks half-a-dozen of the rules in that standard"
At the most simple level - it default to allow rather than deny.
The recent update just changes that default - which is the same as the workaround are applying
Security rules are pretty simple
Don't connect things you don't need , Don't install packages/software you aren't using , Don't open port/API/interfaces that aren't needed.
and don't ignore stuff because you think you are behind a firewall, dmz, not internet facing
Precisely so.At the most simple level - it default to allow rather than deny.
The recent update just changes that default - which is the same as the workaround are applying
Security rules are pretty simple
Don't connect things you don't need , Don't install packages/software you aren't using , Don't open port/API/interfaces that aren't needed.
and don't ignore stuff because you think you are behind a firewall, dmz, not internet facing
Zumbruk said:
I wrote the application security standards for one of the worlds largest banks. Log4j breaks half-a-dozen of the rules in that standard. And running it Internet facing breaks several more.
Funny that, because I actually do advise a number of the world's largest banks on security, and every single one of them has been emergency patching everything in sight ever since this was announcedEdited by Zumbruk on Thursday 16th December 11:23
e-Honda is on the money, as usual. Anyone gloating that this is some kind of easily avoidable situation, or that a line in a security standard would have avoided it, has no idea how complex and inter-woven an environment exists in the world, or indeed how development and security operate in any large enterprise.
No amount of zero-trust buzzword b
ks prepares anyone for a core library turning out to be dangerous. What is important is how quickly you can identify your exposure, chuck it up your build pipeline, then safely deploy it, at the same time as not bringing your business down.Edited by nebpor on Thursday 16th December 16:22
Zumbruk said:
Since you're obviously determined to be argumentative and 'ad hominem' about this, then I'm afraid this conversation is at an end.
Why do you have make a post like that?Edited by Zumbruk on Thursday 16th December 15:38
You responded to me, you made a very bold claim, I asked for some clarification, 2 post later you abandon the discussion and accuse me of being 'ad hominem'
If you don't want to continue the discussion don't but to make a post like this is doing exactly what you accuse me of.
Chozza said:
"Log4j breaks half-a-dozen of the rules in that standard"
At the most simple level - it default to allow rather than deny.
The recent update just changes that default - which is the same as the workaround are applying
Security rules are pretty simple
Don't connect things you don't need , Don't install packages/software you aren't using , Don't open port/API/interfaces that aren't needed.
and don't ignore stuff because you think you are behind a firewall, dmz, not internet facing
Yes I fully understand that it is an unsafe default.At the most simple level - it default to allow rather than deny.
The recent update just changes that default - which is the same as the workaround are applying
Security rules are pretty simple
Don't connect things you don't need , Don't install packages/software you aren't using , Don't open port/API/interfaces that aren't needed.
and don't ignore stuff because you think you are behind a firewall, dmz, not internet facing
What I don't believe is that you would have a security standard that bluntly says you should not use a library because it has an unsafe default, rather than you need to ensure you don't do the unsafe thing.
e-honda said:
Yes I fully understand that it is an unsafe default.
What I don't believe is that you would have a security standard that bluntly says you should not use a library because it has an unsafe default, rather than you need to ensure you don't do the unsafe thing.
It wouldn't say not to use a library because of an unsafe default - but it would say shutdown anything that is unknown/open. And you'd hopefully check this with any deployment from dev to prod. Pretty standard on the network side - bit worrying that so many component application don't follow the same basics. What I don't believe is that you would have a security standard that bluntly says you should not use a library because it has an unsafe default, rather than you need to ensure you don't do the unsafe thing.
( reckon we have 90% that didn't from what my weeks has been like )
Pick any from NIST,ISA,ISO,CISCSC, COBIT and they all say don't BUT are pretty weak on the specifics - i'd expect this to be picked up in the aftermath and probably have a queue of vulnerability testers/pen testers, scanners and cyber experts, trying to sell me a service to do this in the new year
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff