11 ms·

This could be a viable direction but I have some concerns. I feel it will simply push attackers to be selective and it will be difficult for these techniques to

This could be a viable direction but I have some concerns. I feel it will simply push attackers to be selective and it will be difficult for these techniques to avoid standing out. For example, consider their technique of making things non exploitable by overwriting unused variables. What’s to stop adversaries from prioritizing which bug to investigate based on profile data counting uses of variables? Now these chaff bugs need to somehow match the dynamic use counts of real variable. What about the over constraint? Well the authors point out that attacker’s can use SMT solvers to determine that a bug is safely constrained. They propose spreading out the constraining to force the attacker to reason about all paths. Again, Nothing stops the adversary from profiling the memory regions to learn what constraints are being applied followed by prioritizing the least constrained regions. While clever in that it tries to use fundamental limits of reasoning against the adversary, I need more experimental analysis before I am convinced that these chaff bugs are actually indistinguishable to an attacker unless they truly collect profiling data that is exponential in size of programming paths. I think that a few runs would suffice to distinguish the chaff bugs and real bugs.

heavenlyblue 8y ago
I think you're missing the point here: the exploitable bugs in their nature will exist forever. As you are either giving up the Turing-completeness, or are allowing them to possibly exist. Just like it were in 2000s: the fight between the people who were capable of unpacking the executables from their respective defensive mechanisms and the people who implement various mechanisms of obfuscating the executable. For example: online en/decryption of the code, or the later stages of this concept implemented first in Assassin's Creed, where the servers would store various connecting components between stages of the game. So you would need to reach point A under constraints C1 and C2, before the server would tell you what follows A. My point is, you can't take defensive mechanisms implemented in software at their extreme. Simply because of Turing-completeness. The moment we've got the tools that could, under a certain amount of constraints, prove that you can never execute any code that have not been compiled into the executable - is the moment when we don't actually need to develop any new software to defend ourselves.
- heavenlyblue 8y ago
  There's another addendum to this: an another issue that is incredibly relevant to software per se. Most of the time when we build software, the only source of truth, that defines the way a given software must behave - is it's own source code. Thus even when we can prove for sure, that the source code that is being executed is the source code we had just written - we might be missing the cases when we were the ones responsible for introducing the behaviour that we ourselves had not expected. I think the only way to fix that is to introduce even more constraints on the already built system. We use exactly the same mechanics in out legal systems: while there's a single source of truth for most of the laws - there's always the court that checks every single day, if these laws still hold true for a given moment in time, or if they hold true for a given specific scenario. I believe a set of closed-source tests provided by different providers for open-sources software, for example - could work really well. E.G. every time you push a new commit to nginx repository - there's organisations A, B and C which would also report their independent findings on the possible exploitation of the new code. Those findings do not need to be aiming for the same bugs. One of them might be more people-oriented, and another one would be incredibly technical, reaching for the bugs that happen due to compiler design.
- pawelmurias 8y ago
  > The moment we've got the tools that could, under a certain amount of constraints, With strong enough constraints such tools exist.
moyix 8y ago
Yep, as I mention in this thread (https://twitter.com/moyix/status/1025393125567737857 https://twitter.com/moyix/status/1025393125567737857) indistinguishability is the hardest missing piece! You're right that you could try to do some kind of profiling and come up with heuristics, but I would note that real security bugs are most often not on a "hot" path anyway (more frequently executed code is actually less likely to contain security bugs, as we found in a paper from last year: https://www.usenix.org/system/files/conference/atc17/atc17-li_yiwen.pdf https://www.usenix.org/system/files/conference/atc17/atc17-l...).

heavenlyblue 8y ago

I think you're missing the point here: the exploitable bugs in their nature will exist forever. As you are either giving up the Turing-completeness, or are allowing them to possibly exist. Just like it were in 2000s: the fight between the people who were capable of unpacking the executables from their respective defensive mechanisms and the people who implement various mechanisms of obfuscating the executable. For example: online en/decryption of the code, or the later stages of this concept implemented first in Assassin's Creed, where the servers would store various connecting components between stages of the game. So you would need to reach point A under constraints C1 and C2, before the server would tell you what follows A. My point is, you can't take defensive mechanisms implemented in software at their extreme. Simply because of Turing-completeness. The moment we've got the tools that could, under a certain amount of constraints, prove that you can never execute any code that have not been compiled into the executable - is the moment when we don't actually need to develop any new software to defend ourselves.

heavenlyblue 8y ago
There's another addendum to this: an another issue that is incredibly relevant to software per se. Most of the time when we build software, the only source of truth, that defines the way a given software must behave - is it's own source code. Thus even when we can prove for sure, that the source code that is being executed is the source code we had just written - we might be missing the cases when we were the ones responsible for introducing the behaviour that we ourselves had not expected. I think the only way to fix that is to introduce even more constraints on the already built system. We use exactly the same mechanics in out legal systems: while there's a single source of truth for most of the laws - there's always the court that checks every single day, if these laws still hold true for a given moment in time, or if they hold true for a given specific scenario. I believe a set of closed-source tests provided by different providers for open-sources software, for example - could work really well. E.G. every time you push a new commit to nginx repository - there's organisations A, B and C which would also report their independent findings on the possible exploitation of the new code. Those findings do not need to be aiming for the same bugs. One of them might be more people-oriented, and another one would be incredibly technical, reaching for the bugs that happen due to compiler design.
pawelmurias 8y ago
> The moment we've got the tools that could, under a certain amount of constraints, With strong enough constraints such tools exist.

moyix 8y ago

Yep, as I mention in this thread (https://twitter.com/moyix/status/1025393125567737857 https://twitter.com/moyix/status/1025393125567737857) indistinguishability is the hardest missing piece! You're right that you could try to do some kind of profiling and come up with heuristics, but I would note that real security bugs are most often not on a "hot" path anyway (more frequently executed code is actually less likely to contain security bugs, as we found in a paper from last year: https://www.usenix.org/system/files/conference/atc17/atc17-li_yiwen.pdf https://www.usenix.org/system/files/conference/atc17/atc17-l...).