5 ms·

Here is Kees Cook talk from the Linux Security Summit, "The State of Kernel Self Protection Project", he makes the same analogy to car safety in his talk: http

by tux1968 10y ago

Here is Kees Cook talk from the Linux Security Summit, "The State of Kernel Self Protection Project", he makes the same analogy to car safety in his talk: https://www.youtube.com/watch?v=aMkCKeZ8xZw https://www.youtube.com/watch?v=aMkCKeZ8xZw All the available videos from the Linux Security Summit are listed here: https://www.linux.com/news/linux-security-summit-videos https://www.linux.com/news/linux-security-summit-videos

drvdevd 10y ago
I will have to watch these videos as I think the article did not do his analogy justice...
sohkamyung 10y ago
LWN also did a write-up on Kees Cook's talk on Kernel Self Protection Project [1]. Interesting read. - [1] https://lwn.net/Articles/698827/ https://lwn.net/Articles/698827/
Animats 10y ago
It's not like car safety. There's an enemy. The enemy is not random. Patch and release only works against inept opponents, and there are more non-inept opponents. It won't work against opponents who can develop or buy their own exploits. Patch and release gives the illusion of working because it stops vast numbers of inept attacks from clowns who just want to send spam emails. Someone in military base security once said that you have to avoid tying up too much of your resources chasing kids throwing rocks at the perimeter fence. The real threat is the janitor who has access to the spare parts stores. Patch and release, and pattern-matching virus scanners, are chasing kids throwing rocks.
- tux1968 10y ago
  You're making his point for him. His point is that cars used to be built assuming there would never be an accident. They were very comfortable until you crashed into something, and then everyone died. Today cars are built defensively, so that when the unforeseen happens, you are still protected. That's the idea. Building in defenses that protect you against unknown bugs and exploits.
  - tedunangst 10y ago
    But cars still only offer protection against mostly random events, not determined adversaries rail gunning projectiles through the wind shield.
    - eximius 10y ago
      There should be some limit to the threat model, though. It should not attempt to remain secure when something can do arbitrary read and writes (VM), for example. Even determined adversaries will merely be armed, not equipped with WMDs.
    - deleted 10y ago
      [deleted]
- tiraniddo 10y ago
  I think you're also missing the point that adding mitigations into a platform is about reducing the number of exploitable bugs and ideally making the ones which are still exploitable take more time, are less reliable and cost more. I think this fits the car safety analogy pretty well. If you want to think of this in the car safety analogy then consider all possible ways of killing someone in a car before and after the changes in safety standards. In the bad old days random events could kill you but if you had a targeted attacker they could use the same techniques and just drive a car into you, or force you into a wall. Now with newer safety standards the chance that a random event would kill you is much reduced, but the targeted attacker (assuming they don't just fire a bunker buster at you) needs to spend time researching the type of car, finding weak points, developing something to exploit those weak points etc. So it goes with exploit mitigations. It wasn't that long ago that running a fuzzer on a product (and sadly fuzzers are still useful) would yield a massive amount of trivially exploitable bugs. These days, not as much, at least in mature platforms. You could think of the fuzzer discovered "random" bugs to be the case exploit mitigations are trying to protect against (re random collisions which car safety protect against). Even the simplest stuff like stack cookies make exploitation significantly harder. Are there no stack overflow bugs? Nope they still exist. Are they completely unexploitable? Nope, especially in the hands of a skilled attacker. Are you protected against randomly introduced bugs which cause a stack overflow and have a low chance of having some useful behaviour which makes them exploitable? Absolutely. Honestly if someone _wants_ to _kill_ you I'm sure they could. If the attacker is willing to spend the time, effort and money to find better, more exploitable bugs and you're a target worthy of their efforts then you're screwed no matter what exploit mitigations you put in place (this is why imo bug hunting still has some semblance of value). But are you _that_ important? Would the FBI be willing to a throw a $1m iOS exploit at you for example?
- haasn 10y ago
  In the car analogy, the car crashing is the equivalent of the programmer introducing a bug. The adversary is out of the picture here - you want to write your kernel in a way that makes accidental bugs hard/harmless. (i.e. prevent “random crashes”)

by tux1968 10y ago

drvdevd 10y ago

I will have to watch these videos as I think the article did not do his analogy justice...

sohkamyung 10y ago

LWN also did a write-up on Kees Cook's talk on Kernel Self Protection Project [1]. Interesting read. - [1] https://lwn.net/Articles/698827/ https://lwn.net/Articles/698827/

Animats 10y ago

It's not like car safety. There's an enemy. The enemy is not random. Patch and release only works against inept opponents, and there are more non-inept opponents. It won't work against opponents who can develop or buy their own exploits. Patch and release gives the illusion of working because it stops vast numbers of inept attacks from clowns who just want to send spam emails. Someone in military base security once said that you have to avoid tying up too much of your resources chasing kids throwing rocks at the perimeter fence. The real threat is the janitor who has access to the spare parts stores. Patch and release, and pattern-matching virus scanners, are chasing kids throwing rocks.

tux1968 10y ago
You're making his point for him. His point is that cars used to be built assuming there would never be an accident. They were very comfortable until you crashed into something, and then everyone died. Today cars are built defensively, so that when the unforeseen happens, you are still protected. That's the idea. Building in defenses that protect you against unknown bugs and exploits.
- tedunangst 10y ago
  But cars still only offer protection against mostly random events, not determined adversaries rail gunning projectiles through the wind shield.
  - eximius 10y ago
    There should be some limit to the threat model, though. It should not attempt to remain secure when something can do arbitrary read and writes (VM), for example. Even determined adversaries will merely be armed, not equipped with WMDs.
  - deleted 10y ago
    [deleted]
tiraniddo 10y ago
I think you're also missing the point that adding mitigations into a platform is about reducing the number of exploitable bugs and ideally making the ones which are still exploitable take more time, are less reliable and cost more. I think this fits the car safety analogy pretty well. If you want to think of this in the car safety analogy then consider all possible ways of killing someone in a car before and after the changes in safety standards. In the bad old days random events could kill you but if you had a targeted attacker they could use the same techniques and just drive a car into you, or force you into a wall. Now with newer safety standards the chance that a random event would kill you is much reduced, but the targeted attacker (assuming they don't just fire a bunker buster at you) needs to spend time researching the type of car, finding weak points, developing something to exploit those weak points etc. So it goes with exploit mitigations. It wasn't that long ago that running a fuzzer on a product (and sadly fuzzers are still useful) would yield a massive amount of trivially exploitable bugs. These days, not as much, at least in mature platforms. You could think of the fuzzer discovered "random" bugs to be the case exploit mitigations are trying to protect against (re random collisions which car safety protect against). Even the simplest stuff like stack cookies make exploitation significantly harder. Are there no stack overflow bugs? Nope they still exist. Are they completely unexploitable? Nope, especially in the hands of a skilled attacker. Are you protected against randomly introduced bugs which cause a stack overflow and have a low chance of having some useful behaviour which makes them exploitable? Absolutely. Honestly if someone _wants_ to _kill_ you I'm sure they could. If the attacker is willing to spend the time, effort and money to find better, more exploitable bugs and you're a target worthy of their efforts then you're screwed no matter what exploit mitigations you put in place (this is why imo bug hunting still has some semblance of value). But are you _that_ important? Would the FBI be willing to a throw a $1m iOS exploit at you for example?
haasn 10y ago
In the car analogy, the car crashing is the equivalent of the programmer introducing a bug. The adversary is out of the picture here - you want to write your kernel in a way that makes accidental bugs hard/harmless. (i.e. prevent “random crashes”)