201–210 of 335 posts
More evidence that user provided data shouldn’t be logged at all.
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…
Maybe we should tell them to engage with open source, not "support it". Companies should look for a way to spend work hours on open source, not finding someone to send money.
Earlier quoted context omitted.
Symbol table patching doesn't do anything if the functionality is internal... Do you know how programs are linked?
Do you? Have you, e.g., written a linker? Educating is an entirely different process than you are engaged in.
Earlier quoted context omitted.
Do we? Or does "positivity" enable insecure software because there isn't enough social pressure against making dangerous engineering decisions?
Are you saying there would be more security issues if we thanked maintainers more?
The most reliable place to find new bugs and security holes is next to others you just found out about. Bugs come in bunches. If you have fixed just one or two, more lurk right there . And, anyplace else that coder worked. The more you have found, the more remain to be found. Look at other places that coder worked that week. Or year.
Earlier quoted context omitted.
I think you could take this further. There's another "log4j" vulnerability out there right now, I guarantee it. It might be exploited, it might not be. But there's no patch. What are you doing about it? With log4j you have a brutal combination of: 1. RCE 2. Exposure RCE happens frequently but often attackers don't have an easy time getting to the exploitable code. With log4j it's trivial - every app can be owned. But…
Regarding your questions, they make sense in the context of modern software built in the last 5 years. However, most large enterprises have a long tail of legacy applications built years ago. These may be inherited from a combination of acquisitions, from vendors that have since gone under, some from. The common factor is that the original developers are long gone, and they may be supported using a skeleton crew or n…
> What these applications are supposed to connect to are likely unknown. This is a major problem at enterprises
Only if they fail to consolidate vendor integrations and/or have already insufficient staff. (Which is often indeed a problem.)
Simple, if brutal solution; Infosec audits logs and works with application teams to confirm existing traffic and pre-document new traffic out. With properly staffed teams you should run out of surprises within a year.
Earlier quoted context omitted.
I'm baffled by these claims that we should compensate the authors and maintainers of what has been conclusively shown to be software too dangerous to exist. It has the same problem as calls to pay the maintainers of openssl. No amount of money is going to impart good taste and best practices onto these projects. The uncomfortable truth is these libraries need scratch rewrites with better authors.
The unfortunate thing about scratch rewrites is that they are not a good business. Open Source has conditioned people to think that libraries should be free. It's not clear to me that the alternative where libraries are obscenely expensive (like in the hardware world, where a hash table is a $100k investment) is any better. Nobody has ever built a successful company charging between $0 and $10,000 for a library. That…
[0] https://www.dimastr.com/redemption/home.htm
The most reliable place to find new bugs and security holes is next to others you just found out about. Bugs come in bunches. If you have fixed just one or two, more lurk right there . And, anyplace else that coder worked. The more you have found, the more remain to be found. Look at other places that coder worked that week. Or year.
Your implication that specific bad coders are responsible for bugs is dangerous. Anyone can write a bug, and thinking that you're too good to do it is cocky.
But looking in your own code is probably next best. Ask yourself: if there is a bug somewhere in my code, where would it be? You may be surprised at how immediately the answer comes to mind. Look there.
Thanks to all Log4j developers. As users of your free software since ~20 years, we're sure that, if this vuln disclosure had been better and there were no sign of widespread in-the-wild exploitation, you would have done a better job at patching it, and a single release would have been enough. We won't hold a grudge against you; open source means collaboration, and you don't blame hard-working people that give away th…
I lay any blame squarely at the feet of IT security of large organisations that were entirely unprepared to update a widely used dependency that wasn't an operating system or a runtime. Windows, Linux, Java, and .NET are all commonly updated, but "modules" aren't. This wasn't just a predictable scenario, it was predicted. Or more accurately, it has occurred already repeatedly in the NPM ecosystem, but for some myster…
Earlier quoted context omitted.
If you still have the source code for your rust code, it contains the lock file. Look in there and you'll see all dependencies and their version. Why do you want to look at the binary instead?
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…