If your security relies on hidden information then it’s at risk of being broken at any time by someone who will find the information in some way. Open source security is so much stronger because it works independently of system knowledge. See all the open source cryptography that secures the web for example.
Open source poc and fix increases awareness of issues and helps everyone to make progress. You will also get much more eyes to verify your analysis and fix, as well as people checking if there could other consequences in other systems. Some security specialists are probably going to create techniques to detect this kind of sophisticated attack in the future.
This doesn’t happen with closed source.
If some system company/administrator is too lazy to update, the fault is on them, not on the person who made all the information available for your to understand and fix the issue.
That’s a good point, but wasn’t the micro benchmarking possible, published and analyzed because it is open source? Also the vulnerability analysis, impact analysis and fix can be peer reviewed by more yes.
This is literally how I make my living and this is the only comment I’ve made so I’m not sure where you get the idea I think publishing vulnerabilities and PoC are bad … again I literally do this for a living.
Finding vulnerabilities and reporting them is literally what pays my mortgage. Open Source, Closed Source, they both have their merits but to say one is inherently more secure because of the reasons you’re specifying is tacitly false.
My comment is literally only about what you said which pushes a thought that slides to far in one direction. There is a reason no nation state will open source their military hardware.
I don’t need to repeat myself but that’s all I’d be doing.
You’re making the argument that open source software inherently does this better and I’m telling you that you’re wrong. I’m going to cite myself, a 20 year veteran in the field.
It can do it better and often times it does work out this way.
Closed source software also has value and use and for its own set of reasons could make the argument that it is more secure because of access controls and supply chain management and traditional security mechanisms.
I think you read what I wrote as a “no you’re entirely wrong” whereas what I said was “you’re asserting things that aren’t true which is weakening the argument”
Frankly though given the lack of response to what I actually said by anyone I’m just going to rest on knowing in the real world my input is considered valid, here where we’re being fanatics … idk for all you know I’m a bot spewing AI generated drivel.
Maybe the disconnect here is I’m talking about practical application because of experience vs theoretical application because of ideology.
No I don’t think you said I was entirely wrong, that part was clear enough.
My issue is more with your argument from authority and personal experience. It is very easy to be biased by personal experience, especially when it brings good money.
access controls and supply chain management and traditional security mechanisms.
So I’ll put my personal experience too (which is also a low value argument). From the outside it may seem this is well done in big companies. But the reality is that this is often a big mess and security often depends on some guy, if any, actually having some standards and enforcing them, until they leave because the company doesn’t value those tasks. But since it’s closed source, nobody knows about it. With open source, there’s more chance more people will look at this system and find issues.
I don’t doubt some ultra sensitive systems like nuclear weapons have a functional closed source security process because the government understands the risk well enough. But I think there are way more closed source systems, at lower danger level but which still impacts people’s security, that are managed with a much lower standard than if they were open-sourced.
It does, because many more eyes can find issues, as illustrated by this story.
This story illustrates that some eyes can find some issues. For proper discussion we need proper data and ratios, only then we could compare. How many issues there are in open and closed source software? How many of them are getting fixed? Unfortunately, we don’t have this data.
I think some of this data is actually available for open source projects by scanning public repositories, although it would be a lot of work to collect it.
In this case, downgrading to the not affected version. If there’s no possible downgrade, stopping the compromised system until it is fixed.
Keeping the vulnerable system up because you think nobody else should know is a bet, I don’t think it’s sound. State actors are investing a lot to find and exploit those vulnerabilities, in this case probably even funded the implementation of the vulnerability, so I think you should assume that any vulnerability you discover is already used.
Even in open source, responsible disclosure is generally possible.
See, e.g. Spectre/Meltdown, where they worked privately with high level Linux Kernel developers for months to have patches ready on all supported branches before they made the vulnerability public
this is why we invented responsible disclosure, which is a thing companies like apple do even. Although in this case, this was the very beginning of what seemed to be a rollout, so if it does effect systems, it’s not very many. And if they are affected. The solution is pretty obvious.
In this case it seems the backdoor is only usable with someone who has the correct key. Seeing and reverting something fishy is in some cases, like this easier than finding an exploit. It takes a lot of time in this case to figure out what goes on.
Fixing a bug never automatically give an easy to use exploit for script kiddies
The only real downside on the open source side is that the fix is also public, and thus the recipe how to exploit the backdoor.
If there’s a massive CVE on a closed source system, you get a super high-level description of the issue and that’s it.
If there’s one on an open source system, you get ready-made “proof of concepts” on github that any script kiddy can exploit.
And since not every software can be updated instantly, you are left with millions of vulnerable servers/PCs and a lot of happy script kiddies.
See, for example, Log4Shell.
If your security relies on hidden information then it’s at risk of being broken at any time by someone who will find the information in some way. Open source security is so much stronger because it works independently of system knowledge. See all the open source cryptography that secures the web for example.
Open source poc and fix increases awareness of issues and helps everyone to make progress. You will also get much more eyes to verify your analysis and fix, as well as people checking if there could other consequences in other systems. Some security specialists are probably going to create techniques to detect this kind of sophisticated attack in the future.
This doesn’t happen with closed source.
If some system company/administrator is too lazy to update, the fault is on them, not on the person who made all the information available for your to understand and fix the issue.
Crowd sourcing vulnerability analysis and detection doesn’t make open source software inherently more secure.
Closed source software has its place and it isn’t inherently evil or bad.
This event shows the good and bad of the open source software world but says NOTHING about closed source software.
It does, because many more eyes can find issues, as illustrated by this story.
Closed source isn’t inherently bad, but it’s worse than open source in many cases including security.
I think you’re the only one here thinking publishing PoC is bad.
But this issue wasn’t found because of code analysis per se, but because of microbenchmarking.
That’s a good point, but wasn’t the micro benchmarking possible, published and analyzed because it is open source? Also the vulnerability analysis, impact analysis and fix can be peer reviewed by more yes.
This is literally how I make my living and this is the only comment I’ve made so I’m not sure where you get the idea I think publishing vulnerabilities and PoC are bad … again I literally do this for a living.
Finding vulnerabilities and reporting them is literally what pays my mortgage. Open Source, Closed Source, they both have their merits but to say one is inherently more secure because of the reasons you’re specifying is tacitly false.
My comment is literally only about what you said which pushes a thought that slides to far in one direction. There is a reason no nation state will open source their military hardware.
Then please explain why the reasons specified here are false belong that argument from authority.
I don’t need to repeat myself but that’s all I’d be doing.
You’re making the argument that open source software inherently does this better and I’m telling you that you’re wrong. I’m going to cite myself, a 20 year veteran in the field.
It can do it better and often times it does work out this way.
Closed source software also has value and use and for its own set of reasons could make the argument that it is more secure because of access controls and supply chain management and traditional security mechanisms.
I think you read what I wrote as a “no you’re entirely wrong” whereas what I said was “you’re asserting things that aren’t true which is weakening the argument”
Frankly though given the lack of response to what I actually said by anyone I’m just going to rest on knowing in the real world my input is considered valid, here where we’re being fanatics … idk for all you know I’m a bot spewing AI generated drivel.
Maybe the disconnect here is I’m talking about practical application because of experience vs theoretical application because of ideology.
No I don’t think you said I was entirely wrong, that part was clear enough.
My issue is more with your argument from authority and personal experience. It is very easy to be biased by personal experience, especially when it brings good money.
So I’ll put my personal experience too (which is also a low value argument). From the outside it may seem this is well done in big companies. But the reality is that this is often a big mess and security often depends on some guy, if any, actually having some standards and enforcing them, until they leave because the company doesn’t value those tasks. But since it’s closed source, nobody knows about it. With open source, there’s more chance more people will look at this system and find issues.
I don’t doubt some ultra sensitive systems like nuclear weapons have a functional closed source security process because the government understands the risk well enough. But I think there are way more closed source systems, at lower danger level but which still impacts people’s security, that are managed with a much lower standard than if they were open-sourced.
I do agree that your words are in fact a low value argument. We’ve found common ground.
Your heart is in the right place but there is nuance you’re clobbering by not being willing to be open minded.
This story illustrates that some eyes can find some issues. For proper discussion we need proper data and ratios, only then we could compare. How many issues there are in open and closed source software? How many of them are getting fixed? Unfortunately, we don’t have this data.
I think some of this data is actually available for open source projects by scanning public repositories, although it would be a lot of work to collect it.
If the vulnerability is in the wild, what other security mechanisms do you have until it’s patched?
In this case, downgrading to the not affected version. If there’s no possible downgrade, stopping the compromised system until it is fixed.
Keeping the vulnerable system up because you think nobody else should know is a bet, I don’t think it’s sound. State actors are investing a lot to find and exploit those vulnerabilities, in this case probably even funded the implementation of the vulnerability, so I think you should assume that any vulnerability you discover is already used.
Honestly, for closed source software the POCs are also immediately available. Lots of threat actors just use patch diffing.
These days vulnerabilities are at times also patched with other non-related commits to conceal what exactly has changed.
Even in open source, responsible disclosure is generally possible.
See, e.g. Spectre/Meltdown, where they worked privately with high level Linux Kernel developers for months to have patches ready on all supported branches before they made the vulnerability public
bUt gUyS WhAt aBoUt sEcUrItY ThRoUgH ObScUrItY??
hEy, yOu lEaRnEd A bUzZwOrD aNd rEcEnTlY dIsCoVeReD tHe sHiFt KeY!!! cOnGrAtS!?!
hEy, yOu lEaRnEd A bUzZwOrD aNd rEcEnTlY dIsCoVeReD tHe sHiFt KeY!!! cOnGrAtS!?!
hEy, yOu lEaRnEd A bUzZwOrD aNd rEcEnTlY dIsCoVeReD tHe sHiFt KeY!!! cOnGrAtS!?!
this is why we invented responsible disclosure, which is a thing companies like apple do even. Although in this case, this was the very beginning of what seemed to be a rollout, so if it does effect systems, it’s not very many. And if they are affected. The solution is pretty obvious.
Don’t be a dunce, report responsibly.
Was the transition into management easy for you, or was it a slow acceptance?
Oh, we play dumb ad-hominem without any basis in reality?
I can play this too: Was your last school homework hard?
I’m pretty sire there are plenty of ways to exploit proprietary systems. You can’t stop the power of the keyboard
In this case it seems the backdoor is only usable with someone who has the correct key. Seeing and reverting something fishy is in some cases, like this easier than finding an exploit. It takes a lot of time in this case to figure out what goes on.
Fixing a bug never automatically give an easy to use exploit for script kiddies
It is not, it requires a private key to be used.