7 ms·

"Being open-source is a two-sided sword – attackers could also read details of implementation and find flaws easily." umm, really?

by jrm4 5y ago

robomc 5y ago
Yes. The security wins of being opensource are really only there if the project is being engaged with and reviewed by security conscious developers, improvements are being merged in, and the new improvements are being distributed. Otherwise it's usually going to lower your security by some degree.
- lucideer 5y ago
  > lower Using the word "lower" here implies you're comparing open source software to something (closed source software), in which case you'd be implying that closed source software is engaged with and reviewed by security conscious developers. If you think that's the case just because you've heard of a few high-profile open source vulnerabilities, I've got news for you...
- dathinab 5y ago
  > going to lower your security by some degree. Not really, the security is the same. You just make the work for attackers a bit faster=>cheaper. But IMHO for an experienced attacker it's just a matter of "a bit faster" (like their attack comes a few days earlier), not a matter of "being more secure" (like their attack doesn't come at all).
  - deleted 5y ago
    [deleted]
- Spooky23 5y ago
  Look at the lists of CVEs that come out every month for closed source software. How did they fix them? You don’t know. I can tell you that that my colleagues have found cases where major vendors don’t “fix” a defect - they prevent the public exploit from executing. With open source, you can see exactly what was fixed and how. You don’t lower or raise security.
whynotminot 5y ago
Yes absolutely. There’s definitely a bit of a cult of open source. Just because I can look at your code does not inherently, magically make it more secure. Especially in a world where the black market pays better than bug bounty programs. Not necessarily advocating for closed source approaches, but it’s something to bear in mind.
- echelon 5y ago
  > Especially in a world where the black market pays better than bug bounty programs. In crypto/DeFi/croins/crokens/whatever, the bug bounty can be the entire holdings. And there are no legal ramifications or manners of recourse/restitution.
  - lmm 5y ago
    The whole point of the game is that the tokens belong to whoever got the code to run to transfer them to them, isn't it? Complaining that someone "stole" your tokens is like complaining that someone "stole" your gold in an MMORPG.
  - jjnoakes 5y ago
    > And there are no legal ramifications or manners of recourse/restitution. I'd appreciate a source on that... Both seem unlikely to me. More difficult perhaps, but impossible you say?
    - VTimofeenko 5y ago
      Well in crypto there does seem to exist a somewhat widespread notion of "code is law". If the existing business logic is used to do something undesirable (transfer all money to another person) - in such axiom set that action would be considered in line with the " law".
      - 3np 5y ago
        This notion is only used in context of smart contracts and on-chain virtual machine code. This is in contrast to wallet implementations.
Ensorceled 5y ago
How is this controversial? I mean, we may believe the trade-offs are worth it but this is definitely in the "con" column.
- lucideer 5y ago
  How this is controversial is extremely obvious to anyone who works in security. So much so that the opposite of this tenet is literally the first thing generally taught about security (Kerckhoffs's principle). It's well-known, and pretty uncontroversially accepted in the security community. The general idea here is that, while it can be useful to have some "security through obscurity", it's important not to rely on it, and in most cases where it is cites as a measure, it is relied on (often heavily). A good phrase I've heard used to elucidate on this is that "sunlight is the best disinfectant". For example, a more recent related discussion is Schneier's Law[0], which basically posits that any amateur can make a piece of software that they themselves can't break into. True security comes from sharing & discussing it with alternative perspectives (ideally whitebox - not black/greybox - discussions). It's telling about the audience that flock to "crypto(currency)" related posts that the comment is buried in downvotes, because I would think the typical average HN user would not be downvoting this comment. [0] https://www.schneier.com/blog/archives/2011/04/schneiers_law.html https://www.schneier.com/blog/archives/2011/04/schneiers_law... > Kerckhoffs's principle.
  - Ensorceled 5y ago
    You are completely missing the point. Risk analysis is a balancing act: Pros: open source, white hats can easily inspect the source Cons: open source, black hats can easily inspect the source You don’t get to just delete the cons you don’t like, even, if like me, you think the pro out weighs the con.
    - lucideer 5y ago
      > if like me, you think the pro out weighs the con. My point is very simply that in my opinion that you're wrong to think this, and that opinion is shared by most of the security community. There is ample evidence that the cons FAR outweigh the pros in this particular comparison. --- Another way to visualize your comparison would be: - Closed source: -- Pros: 1 white hat can easily inspect the source -- Cons: 1000 hackers can blackbox-attack the application - Open source: -- Pros: 100 white hats can easily fix the source -- Cons: 1000 black hats can whitebox-attack the application You're arguing that 99 white hats don't trump black-vs-white. --- Even if I play devil's semi-advocate here and consider that the pros balance the cons, the statement in the article is still wildly out of place in that context.
mrharrison 5y ago
Security in obscurity
bravetraveler 5y ago
Absolutely! So many compromises against IoT devices or network equipment come from inspecting the open/recycled firmware. There are a lot of interesting defcon videos about using this method edit: To clarify, this isn't to imply that I think closed source would necessarily be better. I think this quote puts it well. An all-too-common story about security in open source... of four people: Everybody, Somebody, Anybody, and Nobody: "Anybody could have done it, but Nobody did it. Somebody got angry about that, because it was Everybody's job. Everybody thought Anybody could do it but Nobody realized that Everybody wouldn't do it. It ended up that Everybody blamed Somebody when Nobody did what Anybody could have done." Source: https://www.youtube.com/watch?v=OnJ18pyMncE https://www.youtube.com/watch?v=OnJ18pyMncE
- lucideer 5y ago
  Heavy citation needed here I think.
  - bravetraveler 5y ago
    I didn't write this with anything specific in mind; it's based on a binge of Defcon videos from at least a year ago - consider that my citation. Honestly, anyone that invests the slightest amount of effort in researching how vulnerabilities are found could arrive here. I'm surprised there's skepticism, quite honestly. It often comes down to the would-be attacker downloading a published update, looking around the PHP or whatever within, and finding unprotected or bugged APIs to leverage -- often to write their own modified version of that same update.
    - lucideer 5y ago
      Well if I re-read your comment, you technically don't say anything too controversial: "so many" isn't really countable. But the implication is that compromises were found because those firmwares were open and/or that closed firmwares suffer fewer similar compromises. Which is what I would question.
- dathinab 5y ago
pcthrowaway 5y ago
Interestingly, the most popular web3 wallet for EVM chains (Metamask), is source-available but not open source.
bashwizard 5y ago
One of the main things I do when doing any application security tests is - you guessed it - read the documentation and source code (if it's open source). It's basically like reading a manual on how to exploit the application.
hpen 5y ago
Have you never considered this or do you actually have a valid argument as to why it isn't true? I thought this was something that was agreed upon by most engineers.

"Being open-source is a two-sided sword – attackers could also read details of implementation and find flaws easily." umm, really?

by jrm4 5y ago

"Being open-source is a two-sided sword – attackers could also read details of implementation and find flaws easily." umm, really?

robomc 5y ago

Yes. The security wins of being opensource are really only there if the project is being engaged with and reviewed by security conscious developers, improvements are being merged in, and the new improvements are being distributed. Otherwise it's usually going to lower your security by some degree.

lucideer 5y ago
> lower Using the word "lower" here implies you're comparing open source software to something (closed source software), in which case you'd be implying that closed source software is engaged with and reviewed by security conscious developers. If you think that's the case just because you've heard of a few high-profile open source vulnerabilities, I've got news for you...
dathinab 5y ago
> going to lower your security by some degree. Not really, the security is the same. You just make the work for attackers a bit faster=>cheaper. But IMHO for an experienced attacker it's just a matter of "a bit faster" (like their attack comes a few days earlier), not a matter of "being more secure" (like their attack doesn't come at all).
- deleted 5y ago
  [deleted]
Spooky23 5y ago
Look at the lists of CVEs that come out every month for closed source software. How did they fix them? You don’t know. I can tell you that that my colleagues have found cases where major vendors don’t “fix” a defect - they prevent the public exploit from executing. With open source, you can see exactly what was fixed and how. You don’t lower or raise security.

whynotminot 5y ago

Yes absolutely. There’s definitely a bit of a cult of open source. Just because I can look at your code does not inherently, magically make it more secure. Especially in a world where the black market pays better than bug bounty programs. Not necessarily advocating for closed source approaches, but it’s something to bear in mind.

echelon 5y ago
> Especially in a world where the black market pays better than bug bounty programs. In crypto/DeFi/croins/crokens/whatever, the bug bounty can be the entire holdings. And there are no legal ramifications or manners of recourse/restitution.
- lmm 5y ago
  The whole point of the game is that the tokens belong to whoever got the code to run to transfer them to them, isn't it? Complaining that someone "stole" your tokens is like complaining that someone "stole" your gold in an MMORPG.
- jjnoakes 5y ago
  > And there are no legal ramifications or manners of recourse/restitution. I'd appreciate a source on that... Both seem unlikely to me. More difficult perhaps, but impossible you say?
  - VTimofeenko 5y ago
    Well in crypto there does seem to exist a somewhat widespread notion of "code is law". If the existing business logic is used to do something undesirable (transfer all money to another person) - in such axiom set that action would be considered in line with the " law".
    - 3np 5y ago
      This notion is only used in context of smart contracts and on-chain virtual machine code. This is in contrast to wallet implementations.

Ensorceled 5y ago

How is this controversial? I mean, we may believe the trade-offs are worth it but this is definitely in the "con" column.

lucideer 5y ago
How this is controversial is extremely obvious to anyone who works in security. So much so that the opposite of this tenet is literally the first thing generally taught about security (Kerckhoffs's principle). It's well-known, and pretty uncontroversially accepted in the security community. The general idea here is that, while it can be useful to have some "security through obscurity", it's important not to rely on it, and in most cases where it is cites as a measure, it is relied on (often heavily). A good phrase I've heard used to elucidate on this is that "sunlight is the best disinfectant". For example, a more recent related discussion is Schneier's Law[0], which basically posits that any amateur can make a piece of software that they themselves can't break into. True security comes from sharing & discussing it with alternative perspectives (ideally whitebox - not black/greybox - discussions). It's telling about the audience that flock to "crypto(currency)" related posts that the comment is buried in downvotes, because I would think the typical average HN user would not be downvoting this comment. [0] https://www.schneier.com/blog/archives/2011/04/schneiers_law.html https://www.schneier.com/blog/archives/2011/04/schneiers_law... > Kerckhoffs's principle.
- Ensorceled 5y ago
  You are completely missing the point. Risk analysis is a balancing act: Pros: open source, white hats can easily inspect the source Cons: open source, black hats can easily inspect the source You don’t get to just delete the cons you don’t like, even, if like me, you think the pro out weighs the con.
  - lucideer 5y ago
    > if like me, you think the pro out weighs the con. My point is very simply that in my opinion that you're wrong to think this, and that opinion is shared by most of the security community. There is ample evidence that the cons FAR outweigh the pros in this particular comparison. --- Another way to visualize your comparison would be: - Closed source: -- Pros: 1 white hat can easily inspect the source -- Cons: 1000 hackers can blackbox-attack the application - Open source: -- Pros: 100 white hats can easily fix the source -- Cons: 1000 black hats can whitebox-attack the application You're arguing that 99 white hats don't trump black-vs-white. --- Even if I play devil's semi-advocate here and consider that the pros balance the cons, the statement in the article is still wildly out of place in that context.

mrharrison 5y ago

Security in obscurity

bravetraveler 5y ago

Absolutely! So many compromises against IoT devices or network equipment come from inspecting the open/recycled firmware. There are a lot of interesting defcon videos about using this method edit: To clarify, this isn't to imply that I think closed source would necessarily be better. I think this quote puts it well. An all-too-common story about security in open source... of four people: Everybody, Somebody, Anybody, and Nobody: "Anybody could have done it, but Nobody did it. Somebody got angry about that, because it was Everybody's job. Everybody thought Anybody could do it but Nobody realized that Everybody wouldn't do it. It ended up that Everybody blamed Somebody when Nobody did what Anybody could have done." Source: https://www.youtube.com/watch?v=OnJ18pyMncE https://www.youtube.com/watch?v=OnJ18pyMncE

lucideer 5y ago
Heavy citation needed here I think.
- bravetraveler 5y ago
  I didn't write this with anything specific in mind; it's based on a binge of Defcon videos from at least a year ago - consider that my citation. Honestly, anyone that invests the slightest amount of effort in researching how vulnerabilities are found could arrive here. I'm surprised there's skepticism, quite honestly. It often comes down to the would-be attacker downloading a published update, looking around the PHP or whatever within, and finding unprotected or bugged APIs to leverage -- often to write their own modified version of that same update.
  - lucideer 5y ago
    Well if I re-read your comment, you technically don't say anything too controversial: "so many" isn't really countable. But the implication is that compromises were found because those firmwares were open and/or that closed firmwares suffer fewer similar compromises. Which is what I would question.
dathinab 5y ago

pcthrowaway 5y ago

Interestingly, the most popular web3 wallet for EVM chains (Metamask), is source-available but not open source.

bashwizard 5y ago

One of the main things I do when doing any application security tests is - you guessed it - read the documentation and source code (if it's open source). It's basically like reading a manual on how to exploit the application.

hpen 5y ago

Have you never considered this or do you actually have a valid argument as to why it isn't true? I thought this was something that was agreed upon by most engineers.