Earlier this month Collin Anderson at Access published a whitepaper on the new Wassenaar controls relating to "intrusion software."

The whitepaper takes the position that the exchange of exploits and vulnerability information across borders is completely outside of the scope of what is controlled by Wassenaar. The whitepaper asserts that :

Exploitation is not concomitant with Intrusion Software nor is vulnerability research necessarily Intrusion Software development.

I'd like to think thats the case, but when I read the Wassenaar text I have trouble reaching the same conclusion. Even if Wassenaar didn't intend to cover vulnerability research, the text they wrote certainly seems to do so. I've come away with the conclusion that the Wassenaar authors may have crafted their policy under an erroneous understanding of how exploitation works.

Wassenaar defines "Intrusion Software" was follows:

"Software" specially designed or modified to avoid detection by 'monitoring tools', or to defeat 'protective countermeasures', of a computer or network-capable device, and performing... the modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions.

Lets expand that part of defeating 'protective countermeasures' as those are also defined specifically in the Wassenaar text:

"Software" specially designed or modified to defeat techniques designed to ensure the safe execution of code, such as Data Execution Prevention (DEP), Address Space Layout Randomisation (ASLR) or sandboxing, of a computer or network-capable device, and performing... the modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions.

This seems to be a perfect description of an exploit. In fact, I don't think that I could have written a clearer legal definition for "exploit" if I tried.

An exploit is software that modifies the standard execution path of a program in order to allow the execution of externally provided instructions. These days, most operating systems have countermeasures that are designed to make it difficult to write an exploit. Data Execution Prevention (DEP) and Address Space Layout Randomisation (ASLR) are examples of exploit countermeasures. If you're going to write a successful exploit for a modern operating system in this day and age, you have to contend with and defeat those countermeasures most of the time.

So, most exploits that are being written today meet both of these criteria. They defeat a countermeasure like DEP and then modify the execution path in order to ... [ Read More (1.0k in body) ]