It's extremely hard to make the case that publishing sources makes it easier to find vulnerabilities when you're talking about simply stripping out comments and internal naming from Java / JavaScript code... Take a look at http://www.underhanded-c.org/_page_id_25.html … if you think sources are magic.
-
-
Show this thread
-
If you're trying to find an intentional backdoor, the developers are your adversaries. If you're looking at the sources they choose to publish, you're looking at the code in the format where they cleverly hid a vulnerability in a deniable way if they aren't total idiots.
Show this thread -
Assuming your adversaries are idiots is always a bad move. It is not necessarily a good idea to even bother looking at the source code if you're looking for a backdoor. Imagine trying to find a backdoor in C sources by someone like
@johnregehr with undefined behavior as a hobby.Show this thread -
Oh, and don't be so sure that reproducible builds where you're *highly* encouraged to use exactly the same (out-of-date!) toolchain as the adversaries is a great idea. AOSP/CopperheadOS/Chromium builds are reproducible. Is it a security feature? We wouldn't claim it to be one...
Show this thread -
Anyone that isn't a complete idiot isn't going to make a backdoor that isn't 100% deniable by being a completely plausible vulnerability. The best way to do it is leveraging a library or toolchain bug where it's not even a bug in the code written by the adversary...
Show this thread -
How often do you run into library / toolchain bugs? Just pick one, trigger the same bug you triggered by accident and there's your backdoor. It's not even a bug in your code. It's not just completely deniable that you added a backdoor, it won't even appear to be your mistake.
Show this thread
End of conversation
New conversation -
-
-
Part is asymmetry in attack vs defense budgets & unpaid participants. Lack of source may make audit prohibitively expensive, but not substantially affect attackers, and...
-
...with open source you get a considerable amount of audit for free just by eyes dealing with building/bug reports/porting.
-
Whenever someone reports a program not working with musl, I almost always run across significant source level bugs while investigating.
-
Most open source projects are developed by only a couple people are rarely if ever have anyone else looking at more than an API. It's not really helping defenders to have tens of millions of GitHub repositories.
-
For example, do you think it would be good or bad for your security to put all of your dotfiles without credentials on GitHub? You might have a glaring security hole in your configuration. Someone might point it out to you so you can fix it, or someone might exploit it.
-
Attackers often don't have a lot of resources. You might just make a troll angry on IRC or Twitter and they look through your profiles, GitHub repositories, etc. and find a mistake in a configuration file or some plugin / script you made that lets them exploit you.
-
Whether it's a net benefit is based on how helpful the sources are (very helpful for C, ridiculously helpful for C++, negligible for Java) and whether people actually end up using the sources to make the software more secure / robust (not the case for 99% of projects).
-
Rust sources are perhaps even more helpful than C++ sources since the code has so many layers of simple abstractions designed to be reliably stripped away by trivial compiler optimizations and they default to LTO (C++ abstractions are harder to strip away).
- 6 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.