"Being open-source is a two-sided sword – attackers could also read details of implementation and find flaws easily."
umm, really?
umm, really?
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."
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.
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.
Some of the best/easiest ways for someone with experience to find vulnerabilities is to throw automatic analysis tools at it. Many of which do work on binaries/disassembly, too.
Don't forget that in many cases it's not too hard to disassemble binaries.
Sure having the source can make it easier, but then things being open source also means that non evil actors might look at you code and help you find/fix problems before they become big. Which I believe somewhat balances it out. (for larger/widely used projects).
Like imagine log4j becoming known because of multiple supper wide spread attacks happening all over the internet, instead of getting known and then fixed and then mass attacks happened because updates take so long. And the log4j vulnerability is totally discoverable without source code. Idk. who found it but I wouldn't be surprised if someone ran into a non-security bug triggered by it and was, hey, wait a moment. Even if it didn't happen like that, it totally could have(1). Closed source would not have helped at all. At best it would delayed it and then made the effects worse due to coordinated wide spread attacks before there is a fix/mitigations.
On the contrary, log4j incident is an excellent example of how relying on open source for security completely failed. This vuln existed for years, all while being open to security researchers to find it. They didn't. Instead, there is evidence that black hats found the vuln first (perhaps because log4j is open source?).
Please, let's continue this back-and-forth of condescension. It's really productive. /s
Maybe it's not, maybe you guys have drastically improved things. What makes me strongly doubt it is that we still haven't seen substantial liability or other consequences for bad or negligent actors in this space.
FAANG security is just like everywhere else: mixed. There are mixed levels of knowledge & experience, and mixed views: i.e. even though there's a lot of consensus on high-level tenets and frameworks, like e.g. Google's Beyondcorp stuff (along with some certain security 101 stuff that's been discussed for the past 138 years), you'll always get engineers who don't like X or Y. Just like anywhere else.
Nothing is a continuum.
It seems the places where the manual digging occurs most are with devices where nobody has even thought or bothered to use such tools.
The vulns the people find are often incredibly laughable; unauthenticated actions leading to a clever path to higher privileges.
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.
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.
I'd appreciate a source on that... Both seem unlikely to me. More difficult perhaps, but impossible you say?
This is in contrast to wallet implementations.
Code is law.
Additionally, they were lucky they could find the 16 yr old kid, otherwise they wouldn't known in which jurisdiction to sue :)
Welcome to the decentralized world!
So plenty of examples on that site.
What would the recourse be if none of the malicious actors can be found? ( In almost all cases).
My opinion is that you'll get relatively more blackhat "eyes" on your code and fewer whitehat "eyes" if you go closed source.
Personally, I don't know anyone who would reverse a closed-source wallet to report bugs "out of the goodness of their hearts", but I do know a bunch of people who would report bugs in good faith to open-source projects.
And open source projects likely pay nothing! I've certainly never heard of a paid bug bounty for any open source project, which doesn't mean they don't exist, it just means it's not that common.
https://www.hackerone.com/internet-bug-bounty
An open system at least means _you_ can have a quick look into it. Every other advantage is not guaranteed, but with the amount of pure snake oil out there this one guaranteed advantage is friggin important.
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...
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).
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.
I mean, we may believe the trade-offs are worth it but this is definitely in the "con" column.
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...
> Kerckhoffs's principle.
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.
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.
And there would be interest, imagine the street cred...
Examples: https://en.wikipedia.org/wiki/Speck_(cipher) and https://en.wikipedia.org/wiki/Simon_%28cipher%29 and https://en.wikipedia.org/wiki/GOST_(block_cipher)
Security engineer here. No they aren't. I'd say they are being a much more comprehensive in their security analysis by including the cons in their calculation rather than dismissing them and assuming that the pros outweigh them.
>opinion is shared by most of the security community.
No it isn't.
Security by obscurity is a very valid defense-in-depth measure. There's a reason you disable "debug-level logging" on production webservers.
>There is ample evidence that the cons FAR outweigh the pros in this particular comparison.
Show said evidence, please, because there is ample evidence that open source software magically being reviewed by hordes of people is many times a myth.
Heartbleed was caused because pretty much nobody cared to look at openssl's code and review it for vulnerabilities. Just because it is available to be looked at by white hats doesn't mean anyone actually is looking at it. And if something so critical to security like openssl isn't even being reviewed by security researchers, what gives you any confidence that random software like JoesCoolLoggingLibrary is reviewed with any more scrutiny?
Speaking of logging, Log4shell is yet another example. The most ubiquitous libraries in use. Used everywhere by some of the largest tech companies in the world, that all have the largest and most well-budgeted security organizations. The vulnerability was present in code for years, available for anyone in the world to look at, and yet...? Instead, there is evidence that Log4shell was being exploited by black hats before any white hats discovered it.
>You're arguing that 99 white hats don't trump black-vs-white.
No, they're arguing that there is no guarantee that these 99 white hats are somehow better than the 1000 black hats, and I'd add to it that there is also no guarantee that these 99 white hats magically appear, anyway. In fact, I think a more realistic visualization for most software is:
- Closed source:
-- Pros: 1 well paid white hat can easily inspect the source
-- Cons: 1000 hackers can blackbox-attack the application
- Open source:
-- Pros: 1-2 unpaid volunteer white hats might inspect the source if they have time
-- Cons: 1000 black hats can whitebox-attack the application
As a security engineer, I know which one I feel more comfortable with.
No it isn't. The whole notion of "defense-in-depth" generally does more harm than good IME, as it creates confusion about where the actual security boundaries are.
> Speaking of logging, Log4shell is yet another example. The most ubiquitous libraries in use. Used everywhere by some of the largest tech companies in the world, that all have the largest and most well-budgeted security organizations.
log4j2 was widely disliked and rarely used, IME.
The security departments of multiple FAANGs, not to mention security experts, completely disagree with you.
>log4j2 was widely disliked and rarely used, IME.
Tell that to the tens of thousands of FAANG engineers who worked all weekend remediating the hundreds of thousands (not exaggeration) instances in their companies where it is in use.
It is outright ridiculous ( even malicious) to point to examples of bugs that were found _by 3rd party users reviewing the code_ as evidence of lack of 3rd party code review.
However, try to find evidence of issues found by a 3rd party reviewing a closed crypto system .
There is a literal objective benefit to having an open system, and that is why every engineer worth its salt is nowadays going to consider a closed crypto system as the snake oil it is.
> Security by obscurity is a very valid defense-in-depth measure. There's a reason you disable "debug-level logging" on production webservers.
This is also missing the point. What is meant here is that a crypto system should not rely on obscurity of its design (rather, the design should be open for cryptonanalysis), not that you have to provide friggin debug- level access to every implementation of the system, even production.
Those "bugs" were found by third party hackers reviewing the code. Heartbleed was found by someone conducting a blackbox pentest. Log4shell was found by someone reviewing the code, and using the exploit before white hats discovered it as a 0-day. This is the exact opposite of championing open source white hats, and is exactly the concern raised by the original author of the statement which created this entire thread.
>However, try to find evidence of issues found by a 3rd party reviewing a closed crypto system .
I can speak from personal experience at a FAANG that this happens literally every day, multiple times a day. Just because you don't hear about it happening because its behind closed doors does not mean it isn't happening.
>There is a literal objective benefit to having an open system
And there is literal objective disadvantage to having an open system, as well. The entire point is that you must weigh the tradeoffs.
>why every engineer worth its salt is nowadays going to consider a closed crypto system as the snake oil it is.
The majority of software you use is using closed crypto systems. Just because the core algorithm used is open source doesn't mean the rest of the implementation is. The security industry does not view this as snake oil. If you think we do, you have a misunderstanding of the security industry.
>This is also missing the point. What is meant here is that a crypto system should not rely on obscurity of its design (rather, the design should be open for cryptonanalysis), not that you have to provide friggin debug- level access to every implementation of the system, even production.
It seems like you're the one that completely missed the point. Relying on third party cryptanalysis for your security goals (especially by unpaid volunteers, or low-paid bounty hunters) is terrible and lazy security, and will almost certainly not get you what you want. The design of a crypto wallet being open is a product decision made because your users want some level of assurance that you aren't secretly stealing their BTC, but it is not a security decision that can be relied on to secure your product from vulnerabilities.
> No it isn't. Security by obscurity is a very valid defense-in-depth measure.
No-one has said otherwise. I said this in the gp of the comment you're replying to.
> Show said evidence, please
No need: you've just shown two good examples yourself. Bugs found by scrutinising open source software. I'd be curious to see how many examples you have of the same found in closed-source software (or are you suggesting there's no closed-source software out there with vulns of the same vintage as Heartbleed).
> No, they're arguing that there is no guarantee that these 99 white hats are somehow better than the 1000 black hats
This sentence seems to make the same assumption others have: that "black hats" are exclusively looking at open source software.
> 1-2 unpaid volunteer white hats might inspect the source if they have time
This might be true of a library noone uses (in which the impact of an exploit is limited by it's popularity). For popular libraries, there's an entire SCA industry of commercial vendors selling products that disprove this (transient dependency reporting is done throughout large corps that rely on open source supply chains). Admittedly this industry is more mature in some areas than others (e.g. package-managed language ecosystems -vs- orchestrated system deps), but it's still not insignificant. There's absolutely no comparison between this effort and the number of eyes looking at proprietary products internally in any given org.
Yes, need.
>you've just shown two good examples yourself. Bugs found by scrutinising open source software.
Bugs found years after they were introduced, and not found by white hats until after black hats were already exploiting them. This is your example of open source software being secure? These are poor examples, and the exact opposite of what you're arguing for.
>This sentence seems to make the same assumption others have: that "black hats" are exclusively looking at open source software.
It makes no such assumption. You appear to have completely missed the point.
>This might be true of a library noone uses (in which the impact of an exploit is limited by it's popularity). For popular libraries, there's an entire SCA industry of commercial vendors selling products that disprove this
Nope. You again seem to have completely missed the point. Openssl and log4j completely destroy your argument here, as they are two of the most used software packages in history and yet nobody noticed the bugs for years. I don't know how you can champion this as a win for open source security with a straight face. We still do not understand the full extent to which these vulnerabilities were exploited, but we do absolutely know that they were exploited before open source white hat researchers found anything. These were abject failures for open source.
> There's absolutely no comparison between this effort and the number of eyes looking at proprietary products internally in any given org.
You're right that there's no comparison. Right now in my company there are thousands of well-paid engineers whose full-time job is to look for vulnerabilities in our closed-source code bases. The amount of scrutiny that open-source libs get doesn't hold a candle to it.
It's basically like reading a manual on how to exploit the application.