[halfastack]

Sure, but there's a difference between "yea, we like 7-zip, let's put some money into it" and "yea, we use Tomcat to actually run our apps connected to the DB, might be nice if it got a bit of patching" (and funnily enough, some of the user-centric apps have more funding than some of the backend, mission-critical SW).

[pedrocr]

My evaluation of the benefit is completely opposite to yours. An exploitable bug in 7-zip has a much higher impact than a bug in Tomcat. Tomcat is running somewhere in the backend so an exploitable bug is not usually usable as a direct attack. A bug in 7-zip can suddenly create a bunch of ransomware attacks just by distributing malicious files.

We have a mountain of C code running in the wild parsing binary formats that's in real need of some fuzzing or ideally replacement by safer languages.

[halfastack]

The thing is, "somewhere in the backend" is generally accessible from the internet, and vulnerable to attackers (so you need only a maliciously crafted packet, or something similar); whereas for 7-zip vulnerability, there must be: a) a maliciously crafted zip file, b) a user who wilfully opens it.

What's more, getting into one's backend servers/gaining some kind of access to DB, config files of the machine, etc. is, in my mind, just infinitely worse than gaining access to a computer of a person/uploading some ransomware/something similar.

We're just probably working with different SW, so we both see the thing that touches us the most as the problem... :))

[pedrocr]

> The thing is, "somewhere in the backend" is generally accessible from the internet

If this is the case you have much bigger problems that a bug bounty won't fix.

> in my mind, just infinitely worse than gaining access to a computer of a person/uploading some ransomware/something similar

That depends heavily on what the backend server is. There are plenty of databases where a hack is irrelevant because the data is public and there are backups. Meanwhile most people have poor backups and a hack can be incredibly damaging.

>we both see the thing that touches us the most as the problem

I think you're heavily discounting the risk that all these code bases in general usage pose. I've fuzzed C++ binary parsing code on just a laptop and was amazed at how many crashing bugs I was able to find in a short amount of time. Many of those were probably easily exploitable.

[mantas]

Gov agencies do accept zip files from general population. Send them something, they'll have to open it to respond to your request... Bam, you broke into a PC with sensitive system inside of a gov network.

[noir_lord]

> We have a mountain of C code running in the wild parsing binary formats that's in real need of some fuzzing or ideally replacement by safer languages.

In an ideal world that's what would happen but even if there where the will and the money it would take decades to replace all of this stuff in practice.

Sometimes when I'm feeling pessimistic I don't think we can ever truly secure (to a reasonable standard) anything.

[pedrocr]

>In an ideal world that's what would happen but even if there where the will and the money it would take decades to replace all of this stuff in practice.

In a previous discussion here someone pointed out you could actually compile C with hardening for out of bounds accesses for example. So maybe we need to isolate those input paths in programs and harden them.

>Sometimes when I'm feeling pessimistic I don't think we can ever truly secure (to a reasonable standard) anything.

I don't think we can either. In part it's just economics, the cost/value of the exploits is just too high for low-value targets. But it's yet another of the reasons I don't see how cryptocurrency ecosystems can really work. The security of the end-points is just way too low for me to trust that kind of thing.