5 ms·

OK so does this mean that OSS is severely vulnerable by default ?

thot_experiment 4y ago
I don't know, I guess if one known malicious actor having access to a piece of information is the same as everyone having access to it, then yes.
nickjj 4y ago
> OK so does this mean that OSS is vulnerable by default ? No, but I don't think that's a fair comparison. An open source tool or app is open source by choice so they have an advantage of knowing what they're getting into. In Slack's case maybe they have a bunch of undocumented APIs which are publicly accessible and now with access to the source code you know what they are, and when you hit them they result in customer data being returned. It runs in their production environment off the live site so it doesn't involve anything crazy like you needing VPN access to their DB to get production data. That's just 1 basic example of what could happen when a private code base becomes public due to a leak. I'd like to think an open source site wouldn't do that because at a fundamental level the app is built in the open. Also, there's likely many sets of eyes from different folks looking at it from different angles. Having undocumented publicly accessible API endpoints isn't an option in an open source world but a private code base could maybe get by with security through obscurity on a few things thinking "well, the code is private...".
- frant-hartm 4y ago
  No one with a little bit of sense of security would do such a thing. Private/proprietary code base != secret code base, there is a great number of ways how a code base might leak - past employees etc..
- saagarjha 4y ago
  > In Slack's case maybe they have a bunch of undocumented APIs which are publicly accessible and now with access to the source code you know what they are, and when you hit them they result in customer data being returned. It runs in their production environment off the live site so it doesn't involve anything crazy like you needing VPN access to their DB to get production data. Yeah, no, this is a security bug.
hnbad 4y ago
In a way. The difference is that if you develop something with public source code, you're vulnerable from day zero of development. That means severe vulnerabilities are more likely to surface before the product is mature enough for those vulnerabilities to represent massive risks. OSS applications benefit from survivorship bias: the code that's there probably contains fewer vulnerabilities because any vulnerabilities that were there have likely been exploited already, allowing them to be detected and fixed. Meanwhile if you allow a closed code base to grow and mature for years and then expose it to the prying eyes of the public, it might contain a few bangers that would have been caught much earlier if the code had been developed in public. Of course this assumes that vulnerabilities get fixed and dev teams learn to avoid them once they've found them. This somewhat breaks down in typical plugin-heavy open source stacks where any random plugin might be developed by a 13 year old in their bedroom and no longer maintained and your flagship product now depends on it because nobody noticed its glaring security flaws. Though this can be managed and avoided somewhat by being more deliberate when picking out plugins. EDIT: A really straightforward example is committing unencrypted secrets (API keys, passwords, whatever). In an OSS product this will likely be exploited almost instantly but this creates cultural awareness to not do that (either by learning from mistakes or by being told horror stories about those mistakes). In a closed source product this could easily go on for years with no consequences until someone exposes the code to the public.
- nickjj 4y ago
  Yep, this is very well put and tracking on the same page as what I was thinking too. I've done contract work for a bunch of small businesses (1-50 dev team sizes) and the amount of bangers I've seen are quite high. It's a whole different world when the expectation is your source code is private and the code has been been around for 2-10+ years. Committing secrets is pretty common (sometimes accidental, sometimes on purpose) but it goes way beyond that type of thing. There's a whole culture around the app being private. Survivorship bias is definitely real. Also "given enough eyeballs, all bugs are shallow": https://en.wiktionary.org/wiki/given_enough_eyeballs,_all_bugs_are_shallow https://en.wiktionary.org/wiki/given_enough_eyeballs,_all_bu...

I don't know, I guess if one known malicious actor having access to a piece of information is the same as everyone having access to it, then yes.

nickjj 4y ago

> OK so does this mean that OSS is vulnerable by default ? No, but I don't think that's a fair comparison. An open source tool or app is open source by choice so they have an advantage of knowing what they're getting into. In Slack's case maybe they have a bunch of undocumented APIs which are publicly accessible and now with access to the source code you know what they are, and when you hit them they result in customer data being returned. It runs in their production environment off the live site so it doesn't involve anything crazy like you needing VPN access to their DB to get production data. That's just 1 basic example of what could happen when a private code base becomes public due to a leak. I'd like to think an open source site wouldn't do that because at a fundamental level the app is built in the open. Also, there's likely many sets of eyes from different folks looking at it from different angles. Having undocumented publicly accessible API endpoints isn't an option in an open source world but a private code base could maybe get by with security through obscurity on a few things thinking "well, the code is private...".

frant-hartm 4y ago
No one with a little bit of sense of security would do such a thing. Private/proprietary code base != secret code base, there is a great number of ways how a code base might leak - past employees etc..
saagarjha 4y ago
> In Slack's case maybe they have a bunch of undocumented APIs which are publicly accessible and now with access to the source code you know what they are, and when you hit them they result in customer data being returned. It runs in their production environment off the live site so it doesn't involve anything crazy like you needing VPN access to their DB to get production data. Yeah, no, this is a security bug.

hnbad 4y ago

In a way. The difference is that if you develop something with public source code, you're vulnerable from day zero of development. That means severe vulnerabilities are more likely to surface before the product is mature enough for those vulnerabilities to represent massive risks. OSS applications benefit from survivorship bias: the code that's there probably contains fewer vulnerabilities because any vulnerabilities that were there have likely been exploited already, allowing them to be detected and fixed. Meanwhile if you allow a closed code base to grow and mature for years and then expose it to the prying eyes of the public, it might contain a few bangers that would have been caught much earlier if the code had been developed in public. Of course this assumes that vulnerabilities get fixed and dev teams learn to avoid them once they've found them. This somewhat breaks down in typical plugin-heavy open source stacks where any random plugin might be developed by a 13 year old in their bedroom and no longer maintained and your flagship product now depends on it because nobody noticed its glaring security flaws. Though this can be managed and avoided somewhat by being more deliberate when picking out plugins. EDIT: A really straightforward example is committing unencrypted secrets (API keys, passwords, whatever). In an OSS product this will likely be exploited almost instantly but this creates cultural awareness to not do that (either by learning from mistakes or by being told horror stories about those mistakes). In a closed source product this could easily go on for years with no consequences until someone exposes the code to the public.

nickjj 4y ago
Yep, this is very well put and tracking on the same page as what I was thinking too. I've done contract work for a bunch of small businesses (1-50 dev team sizes) and the amount of bangers I've seen are quite high. It's a whole different world when the expectation is your source code is private and the code has been been around for 2-10+ years. Committing secrets is pretty common (sometimes accidental, sometimes on purpose) but it goes way beyond that type of thing. There's a whole culture around the app being private. Survivorship bias is definitely real. Also "given enough eyeballs, all bugs are shallow": https://en.wiktionary.org/wiki/given_enough_eyeballs,_all_bugs_are_shallow https://en.wiktionary.org/wiki/given_enough_eyeballs,_all_bu...