5 ms·

As opposed to the “security” of closed source software? Where severe vulns are left in as long as they aren't publicized because it would take too much developm

by Nadya 2y ago

As opposed to the “security” of closed source software? Where severe vulns are left in as long as they aren't publicized because it would take too much development time to justify fixing and the company doesn't make money fixing vulns - it makes money creating new features. And since it isn't a security-related product any lapses in security are an "Oopsy woopsy we screwed up" and everyone moves on with their lives? Even companies that are supposed to get security right have constant screw ups that are only fixed when someone goes poking around where they probably shouldn't and thankfully happens to not be malicious.

LittleShaman 2y ago
I think your comment works as a reply to claiming closed source is more secure than open source - you try to bring them both to the same level. I dont think it replies to what the user asks though. It seems reasonable expecting widely used open source software to be studied by many people. If thats true it would be good to question why this wasnt caught by anyone. Ignoring all ssl errors is not something you need to be an expert to know is bad...
- Nadya 2y ago
  Codebases outside of security-contexts are rarely audited, much less professionally so. The culture of code reviewing PR's from 14 years ago is a little different from today and is also why any "quick hacks to make things work" should always have some form of "//HACK: REVIEW OR REMOVE BY <DATE>" attached to it to make it easy to find. From a security perspective there are only two kinds of code bases: open & closed. By deduction one of those will have more eyeballs on the codebase than the other even if "nobody looks". Case in point: It may have taken 14 years but someone looked. Had the code base been closed source that may never have happened because it might not have been possible to ever happen. It's also very easy to point to the number of security issues that never made it into production because it was caught in an open source code review by passerbys and other contributors while the PR was waiting to be merged. The fact it was caught at all is a point for open source security - not against it. Even if it took 14 years.
  - TeMPOraL 2y ago
    > From a security perspective there are only two kinds of code bases: open & closed. By deduction one of those will have more eyeballs on the codebase than the other even if "nobody looks". Is that the classification that matters? I'd think that there are only following two kinds of code bases: those that come with no warranty or guarantee whatsoever, and those attached to a contract (actual or implied) that gives users legal recourse specific party in case of damages caused by issues with that code (security or otherwise). Guess which kind of code, proprietary or FLOSS, tends to come with legal guarantees attached? Hint: it's usually the one you pay for. I say that because it's how safety and security work everywhere else - they're created and guaranteed through legal liability.
    - Nadya 2y ago
      Can you cite an example where a company was sued over bad code? I want to agree with you and agree with your reasoning (which is why I upvoted you as I think it is a good argument) but cannot think of any example where this has been the case. Perhaps in medical/aviation/government niches but not in any niche I've worked in or can find an example of. The publicly known lawsuits seem to come from data breeches and the large majority of those data breeches are due to non-code lapses in security. Leaked credentials, phished employee, social engineering, setting something Public that should be Internal-only, etc. In fact, in many proprietary products they rely on FLOSS code which resulted in an exploit and the company owning the product may be sued for the resulting data breeches as a result. But that's an issue with their product contract and their use of FLOSS code without code review. As it turns out many proprietary products aren't code reviewing the FLOSS projects they rely on either despite their supposed potential legal liability to do so. > I say that because it's how safety and security work everywhere else - they're created and guaranteed through legal liability. I don't think the legal enforcement or guarantees are anywhere near as strong as other fields, such as say... actual engineering or the medical field. If a doctor fucks up badly enough they can no longer practice medicine. If a SWE fucks up bad enough they might get fired? But they can certainly keep producing new code and may find a job elsewhere if they are let go. Software isn't a licensed field and so is missing a lot of safety and security checks that licensed fields have. Reheating already cooked food to sell to the public requires a food handler's card which is already a higher bar than exists in the world of software development. Cybersecurity isn't taken all that serious by seemingly anyone. I wouldn't have nearly as many conversations with my coworkers or clients about potential HIPAA violations if it were.
perching_aix 2y ago
> As opposed to the “security” of closed source software? No, I don't think that's what they were saying.
lofaszvanitt 2y ago
Security by obscurity works, it works, no matter how hard people regurgitate the bs that it's not working.
- Nadya 2y ago
  The contexts of security by obscurity is usually in regards to data that would attract people who would specifically target you for being a mark that will make them a lot of money rather than opportunistically target you because you are an easy mark that will make them a quick & easy profit of unknown value. If someone wants to rob you - a door lock isn't going to stop them. Likewise if someone wants to pwn you - a little obfuscation isn't going to stop them. Security by obscurity only works in the case that you aren't known to be worth the effort to target specifically and so nobody bothers. Much like very few people bother to beat my CTF. I'm sure if I offered a $1,000 reward for beating it the number would increase tenfold because it is suddenly worth the effort to spend a bit of time attacking. But as it stands with no monetary incentive the vast majority (>99%) give up after a few days.
  - lofaszvanitt 2y ago
    Yeah, but how will an attacker know to target you if they don't even know you have anything valuable, and you are flying under the radar, hm?

by Nadya 2y ago

LittleShaman 2y ago

I think your comment works as a reply to claiming closed source is more secure than open source - you try to bring them both to the same level. I dont think it replies to what the user asks though. It seems reasonable expecting widely used open source software to be studied by many people. If thats true it would be good to question why this wasnt caught by anyone. Ignoring all ssl errors is not something you need to be an expert to know is bad...

Nadya 2y ago
Codebases outside of security-contexts are rarely audited, much less professionally so. The culture of code reviewing PR's from 14 years ago is a little different from today and is also why any "quick hacks to make things work" should always have some form of "//HACK: REVIEW OR REMOVE BY <DATE>" attached to it to make it easy to find. From a security perspective there are only two kinds of code bases: open & closed. By deduction one of those will have more eyeballs on the codebase than the other even if "nobody looks". Case in point: It may have taken 14 years but someone looked. Had the code base been closed source that may never have happened because it might not have been possible to ever happen. It's also very easy to point to the number of security issues that never made it into production because it was caught in an open source code review by passerbys and other contributors while the PR was waiting to be merged. The fact it was caught at all is a point for open source security - not against it. Even if it took 14 years.
- TeMPOraL 2y ago
  > From a security perspective there are only two kinds of code bases: open & closed. By deduction one of those will have more eyeballs on the codebase than the other even if "nobody looks". Is that the classification that matters? I'd think that there are only following two kinds of code bases: those that come with no warranty or guarantee whatsoever, and those attached to a contract (actual or implied) that gives users legal recourse specific party in case of damages caused by issues with that code (security or otherwise). Guess which kind of code, proprietary or FLOSS, tends to come with legal guarantees attached? Hint: it's usually the one you pay for. I say that because it's how safety and security work everywhere else - they're created and guaranteed through legal liability.
  - Nadya 2y ago
    Can you cite an example where a company was sued over bad code? I want to agree with you and agree with your reasoning (which is why I upvoted you as I think it is a good argument) but cannot think of any example where this has been the case. Perhaps in medical/aviation/government niches but not in any niche I've worked in or can find an example of. The publicly known lawsuits seem to come from data breeches and the large majority of those data breeches are due to non-code lapses in security. Leaked credentials, phished employee, social engineering, setting something Public that should be Internal-only, etc. In fact, in many proprietary products they rely on FLOSS code which resulted in an exploit and the company owning the product may be sued for the resulting data breeches as a result. But that's an issue with their product contract and their use of FLOSS code without code review. As it turns out many proprietary products aren't code reviewing the FLOSS projects they rely on either despite their supposed potential legal liability to do so. > I say that because it's how safety and security work everywhere else - they're created and guaranteed through legal liability. I don't think the legal enforcement or guarantees are anywhere near as strong as other fields, such as say... actual engineering or the medical field. If a doctor fucks up badly enough they can no longer practice medicine. If a SWE fucks up bad enough they might get fired? But they can certainly keep producing new code and may find a job elsewhere if they are let go. Software isn't a licensed field and so is missing a lot of safety and security checks that licensed fields have. Reheating already cooked food to sell to the public requires a food handler's card which is already a higher bar than exists in the world of software development. Cybersecurity isn't taken all that serious by seemingly anyone. I wouldn't have nearly as many conversations with my coworkers or clients about potential HIPAA violations if it were.

perching_aix 2y ago

> As opposed to the “security” of closed source software? No, I don't think that's what they were saying.

lofaszvanitt 2y ago

Security by obscurity works, it works, no matter how hard people regurgitate the bs that it's not working.

Nadya 2y ago
The contexts of security by obscurity is usually in regards to data that would attract people who would specifically target you for being a mark that will make them a lot of money rather than opportunistically target you because you are an easy mark that will make them a quick & easy profit of unknown value. If someone wants to rob you - a door lock isn't going to stop them. Likewise if someone wants to pwn you - a little obfuscation isn't going to stop them. Security by obscurity only works in the case that you aren't known to be worth the effort to target specifically and so nobody bothers. Much like very few people bother to beat my CTF. I'm sure if I offered a $1,000 reward for beating it the number would increase tenfold because it is suddenly worth the effort to spend a bit of time attacking. But as it stands with no monetary incentive the vast majority (>99%) give up after a few days.
- lofaszvanitt 2y ago
  Yeah, but how will an attacker know to target you if they don't even know you have anything valuable, and you are flying under the radar, hm?