5 ms·
It's probable that there are more log4j type of exploits thats just waiting to be discovered. It's also becoming hard to tell which are private enterprises vs s
by upupandup 4y ago
It's probable that there are more log4j type of exploits thats just waiting to be discovered. It's also becoming hard to tell which are private enterprises vs state sponsored cyber attack.
It just seems like there's no solution. If Java is this bad imagine how much more attack surface a npm heavy project. Not only that the seeming hardware knowledge of state sponsored attackers seem sophisticated enough to gain access at the vendor level, which forces us to question even the most trusted methodologies and dependency management.
- hedora 4y agoWe could learn to write auditably correct software. Reflections on Trusting Trust explains why writing correct software is inadequate: https://dl.acm.org/doi/10.1145/358198.358210 https://dl.acm.org/doi/10.1145/358198.358210
- commandlinefan 4y ago> seems like there's no solution There is - don't depend on anybody else's software. It just means that software development will take longer and cost more.
- Beltalowda 4y agoThis assumes that your own software is more secure.
- waynesonfire 4y agofor what it's worth, the log4j vulnerability was due to some obscure feature that nobody uses. unlikely you'd even write such code.
- upupandup 4y agobut the cost of rewriting everything that you are currently using through dozens of dependencies and third party libs you are going to go broke. Unless you have the budget like the DOD which has its own coding language I believe, you are ngmi Not to mention you would be introducing attack surfaces that wont have enough attention because its only being used by your team. At least with a widely used lib, vulnerabilities are caught, published (very important) and constantly raising vigilence. here you would have to perform your own threat mitigation and have bounty programs.
- robertlagrant 4y agoIt could be that npm libraries' obsession with only doing one thing will mean that they are less likely to get the sort of feature bloat that caused log4j's current misery.
- spatley 4y agoThe dependencies are knowable in and software that is under development. But mitigations may be herculean. My big question is, how can we exclude features we do not want? It seems foolish in retrospect to give your logger exe functionality on the server. Where is my safeLog4j?