Hacker News Reader

Comment by bagels | Hacker News Reader

I don't think comparing software to buildings is always apt.

If a building collapses, it's likely that people will die.

The consequences of failing software can be mere annoyances depending on the context of its use.

Obviously certain industries that use software have much more dire consequences of failure though (eg. large machinery, transport, health care).

I think one could come up with all sorts of analogies that fit or don't fit, such as, applying a similar argument to door locks. Why should it be legal to use ordinary keyed locks on houses when they are so easy to circumvent with basic lockpicks?

View on HN

Programs written in memory-unsafe languages are riddled with RCE vulns. This is true even for software written by companies that hire the very best security engineers in the world. The consequences of such software that processes untrusted input is more than mere annoyance. This sort of behavior is the root of RATs operated by both criminals and oppressive states. It does not matter if your program is intended for something as seemingly non-critical as text messaging - it will still be used to cause terrible harm.

I do not think that the lock is a reasonable comparison here, because exploitation of software scales so so so much more effectively than picking locks. One exploit easily scales to millions of devices. So the harm caused by vulnerable software has a much higher ceiling than the harm caused by a weak lock.

The point of the lock analogy is to point out the absurdity of analogies here.

Then drop the analogy.

If I install software that was written in C++ on a device I own and it processed untrusted content then I put myself as fairly major risk of all sorts of harm. There are only two resolutions for this problem:

1. No more memory-unsafe languages on security boundaries.

2. Extremely effective sandboxing and process isolation.

#2 has proven very hard. But we know how to do #1. We just need to spend the effort.

Part of the problem is that the actual impact of vulnerabilities in the program is often divorced from it's actual purpose. A simple TODO list that allows RCE is one example. It also has a wide variety of impact based on the user - is it just installed on a random personal computer? Or is it on a hospital server?

I don't know that it's particularly possible for a developer to truly understand all the possible impacts of an error in their program.

I'm not sure what the best way to handle that uncertainty is. Assuming all failures are critical would do the job, but certainly isn't free. However doing something like is suggested here - somehow requiring safer languages - might be a decent middle ground. The cost of using languages more built-in safety features is often not very high. Actually often such languages claim that those features make them cheaper to use.

Reply on news.ycombinator.com