251–260 of 335 posts
Why are people still using JDNI? It is frail enough to have logs depend on a dns lookup, I can't imagine depending on a LDAP lookup. This is not such a fundamental issue as the above but it is pretty dangerous.
Oh yes and of course one of the worse and least pythonic package in the Python standard library was "inspired" by the log4j monstrosity
Earlier quoted context omitted.
> We have Sun's forward-thinking and the enterprise-friendliness of the Java ecosystem to thank for that. I find it quite ironic to praise the forward-thinking of the company that has been instrumental to bring us into this mess via their vision of loading dependencies at runtime from an online repository. Sun imagined that the code and its configuration does not have to worry about how to fulfill its dependencies, b…
I'm writing this from memory, with checking any sources. IIRC: Designs like JNDI were widespread in the IT software industry at the time. The academic prototype for all this was CORBA, the Common Object Request Broker Architecture. An object-oriented was to transmit data between systems running on separate processes, CPUs, remote servers. CORBA was a next-gen RPC (Remote Procedure Call) framework, the data format on…
In these Java attacks the code is downloaded and run locally, with all secrets and data access of the attacked program.
Here's what I don't get: What is so complicated about logging that you can't implement the necessary functionality in your own codebase, and instead have to adopt a third-party library? The latter option represents a liability, which in this case (as with others) has shown can be a tremendous risk. Is the time saving really worth it, at the cost of risking disasters like this? I get that the tradeoff it is worth it f…
It is not complicated. Structured or semi-structured logging is the only way to log things and still be compliant with all the demands. A lot of these libs separate logging into layouts and parameters. If you log input parameters as layouts. You might break the logging. I have seen this at every company I worked with. The only really surprising thing about log4j is the remote code execution.
If information security people would spend the same amount of time they are spending complaining about this vulnerability trying to educate their organisations on the importance of supporting open source solutions they depend on we wouldn’t be in this situation. I am sick of reading of very senior people complaining about the impact this vulnerability has had on their week when their companies don’t even contribute a…
I read a post recently that said part of the open source funding issue comes down to a financial "structure" mismatch. Open source folks are often individuals or loose collections of individuals. Sometimes they have things like Patreons, ask to receive crypto currencies, etc. Companies don't/can't provide funding via these types of structures, so the writer of the post ended up incorporating a company, setting up a m…
So, again, why is log4j "evaluating" stuff in log strings? This is the root cause that people should be addressing Why are people still using JDNI? It is frail enough to have logs depend on a dns lookup, I can't imagine depending on a LDAP lookup. This is not such a fundamental issue as the above but it is pretty dangerous. Oh yes and of course one of the worse and least pythonic package in the Python standard librar…
Earlier quoted context omitted.
Welcome to GDPR and hello to trace log everything. :)
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.
Earlier quoted context omitted.
The source code is not what is deployed . There is typically no link back from a deployed system to its source, even if you compiled the binary within your organisation. If it came from an external organisation, things are exponentially harder. Modern deployment systems are largely "one-way", with no way to trigger a full recompile from the deployment end of things. If you have a VM with "SomeRandomBinary.exe" runnin…
This sounds like an ops problem. It shouldn't be hard to tell what's running in your production environment and tie that back to a specific commit.
Moreover he is arguing that java, as opposed to fat binaries with potentially stripped symbols, made things solvable. He fears that many companies would be much worse off with a big vulnerability in e.g. a rust crate.
Earlier quoted context omitted.
My point is that patching third party binaries is generally not something companies take responsibility for. They wait for vendors to patch the binaries and ship them.
> generally not something companies take responsibility for I have some bad news for you: viruses and hackers don't care about your support contracts and the delays they cause. Actually, I tell a lie: the hackers love them.
a) It's very rare to patch things manually
b) It's very rare to develop patches yourself (for 3rd party software)
I'm sure some companies out there with many decades old deployments have to do stupid shit like that, but it's hardly the standard.
Earlier quoted context omitted.
This sounds like an ops problem. It shouldn't be hard to tell what's running in your production environment and tie that back to a specific commit.
It is! But a lot of ops departments have problems! OPs point is that a lot of deployments out there make it really hard to remediate this kind of vuln. Moreover he is arguing that java, as opposed to fat binaries with potentially stripped symbols, made things solvable. He fears that many companies would be much worse off with a big vulnerability in e.g. a rust crate.
I don't think we should optimize for garbage companies with garbage practices.
On behalf of all information security people everywhere, I want to thank Apache for all the wonderful Christmas presents this year. I hope you step on a Lego.
On behalf of open source software developers, go pay for commercial software yourself.
The point is to keep you secure, not be a slow news relay. In that regard, GP is just really bad at his job.