I am one of the developers, so I can offer some small clarifications. While it was not clear from the writeup (and when it got posted) this experiment was run 2 days after the bug disclosure and well before patches started to stabilize. The post had to go through a review before we could publish it.

The A3 stack relies on syscall monitoring (via virtual machine introspection), network filters (which are protocol specific) and filesystem-neutral monitoring. Some of this stuff is readily comprehensible to a sysadmin, other stuff is not. Automatic application profiling is an area of ongoing work for the project.

This is very interesting work. Thanks for publishing it. One thought experiment for you (which perhaps you've discussed already): could an attacker potentially influence and predict the state of patched software on the target system, introducing vulnerabilities which did not exist prior to patching? Also along that line, have you attempted to fuzz the input fields in scenarios such as your shellshock example?

That thought experiment falls under the umbrella of adversarial machine learning, which is something that we are aware of but has not been a focus for us thus far. Getting the correct adaptation in the first place was the primary goal. To trigger adaptation/patching, an attacker needs to drive the protected application to an undesirable state (exploit it, in other words), so an insidious attack that predicted and triggered multiple patches in the name of creating some ultimate vulnerability is a pretty high bar to clear. I would not claim it is impossible, but I do not know under what conditions that path would ultimately be easiest for the attacker.

We have done some work with fuzzing malicious inputs to produce better network filters, but that work focused on integrating a 3rd party fuzzer: https://dist-systems.bbn.com/papers/2013/Automated%20Self-Ad...