Hijacking is Buffer Overflow (2001) | Hacker News Reader

Hijacking is Buffer Overflow (2001)

paulgraham.com

48 pointseropple17 comments

Bruce Schneier has often made the observation that air travel is much safer now, but not because of any of the "Security Theatre" antics of the TSA. Because of two facts: passengers know they should fight back, and cockpits are now behind locked sturdy bulkheads.

To make it exceedingly clear: many taxis were better protected than planes. Taxis often have a shield between the passengers and driver, ensuring driver safety and integrity. Planes didn't.

Bad analogy. Hijacking isn't caused/enabled by a plane having more passengers than it was designed to carry. Why do people admire this sort of thing? If he wants to argue that we should focus on strengthening cockpit doors rather than passenger screening, fine. But does anyone actually think the spurious analogy to buffer makes his argument more compelling?

Thank you, because I'm wondering that myself (and I submitted the story!). I didn't post it as a story because it was a good one. More to see exactly how deep HN has gone into parts unknown to see what happens when "presented without comment" really is presented without comment. "It's just after September 11th, so I'm going to talk about how the world should be more like my favorite programming language" is at best wacky and that that didn't get picked up before your post is interesting to me.

Well, I'm glad to hear that. But now I feel like kind of a dummy, because I assumed that then article was submitted approvingly, and I expected to get down votes and hate replies. Sometimes it's good to be wrong.

Yeah...I wanted to disclaim it, but that would have defeated the purpose of the post. :-)

Yeah! Hijacking is a failure of type systems due to dynamic dispatch. Plane control should have been restricted to only statically defined pilot values.

Yeah! Hijacking is a failure of type systems due to command injection. Properly typed planes world fail to allow passenger actions to be interpreted as pilot actions.

To prevent these threats, the TSA should confiscate bad analogy guns or at least validate strict isomorphism.

(And as far as the article goes, it's not even correct. Your "data" includes closures/function pointers/whatever and if that data gets corrupted you could get the program to call into the wrong function.)

Analogies are a good spur for creativity, even if they have to be sanity-checked afterward. Someone who didn't already know that cockpits are sealed might consider it by relating hijacking to buffer overflows. Your own analogies both suggest that some way of binding "pilotability" to the actual pilot would be useful -- maybe a retinal scan or DNA check before activating the controls.

The only thing worse than an aircraft controlled by a hijacker is an aircraft piloted by no one at all because the security system locked out the legitimate pilots. I'd give this a resounding NOPE.

I wish people used analogies less. Because often analogies are either bad, or at some point stretched. And in most cases, dealing with the subject directly is more straightforward and less prone to misinterpretation.

Hmm, If one wishes a broad formulation for computer Hijacking, I would say that it's a mismatch between input-scanning and interpreter behavior. This view would include both SQL-injection and buffer-overruns (while the interpreter is the chip itself).

Of course something like Heartbleed is a bit different because it's around extract data that shouldn't have been there in the first place.

But still, some kind of "interpreter" is needed for any language and challenge is to make sure that user-input remains "data" as the interpreter understands it. This "sanitizing" is an ultimately hard problem even as each version of the problem (preventing buffer overruns, prevent sql-injection, etc) seems easy.

Security similarly is hard in that finding all weak points and strengthening them is hard even as strength weak-point-X may seem easy.

A few terrorists among hundreds of good people have little chance now. Too many canaries. Terrorists will only have their corrupt data invalidated.

From http://en.wikipedia.org/wiki/Buffer_overflow_protection#Cana...

Canaries or canary words are known values that are placed between a buffer and control data on the stack to monitor buffer overflows. When the buffer overflows, the first data to be corrupted will usually be the canary, and a failed verification of the canary data is therefore an alert of an overflow, which can then be handled, for example, by invalidating the corrupted data.

> The defense that doesn't work is to check the data on the way in, to make sure it isn't longer than the memory set aside for it.

This defense is only one that needs to be done if you use a language without memory safety in the first place.

Wow, how have I not seen this one before?!

Because he removed it from all traces of his site, except for the index.

The problem is that when a program contains a JIT compiler, then suddenly, code == data.

When a program runs on a CPU and a buffer is overrun, then code==data, when it runs on a JIT, isn't it (eq, code, data)?

Reply on news.ycombinator.com