PolyX is useful in a number of scenarios, with two primary use cases:
- Processing potentially hostile external data. Any system that directly processes external data (e.g. input from a web api or directly from an HTML query) is vulnerable to memory based attacks. PolyX can provide protection against those hostile attacks.
- Dynamic Application Security Testing. There are a number of compelling DAST products in the market, such as those from Contrast Security and others. However, many of those products focus on protecting and analyzing the application at the script language level. PolyX can extend that testing to include the binary code portions of the application as well.
- Honeypots. PolyX's resilience and detection of BlindROP style attacks makes it an ideal addition to a honeypot. Safely detect adversaries attempting a memory takeover.
PolyX does extensive and continuous rewriting of the binary code--all while it is running. Thus, there are certain programming patterns that PolyX is not compatible with, such as programs that dynamically modify their own binary code. We strong recommend testing before putting any system into production with PolyX.
Typically, if a program is not compatible with PolyX (e.g. it does do dynamic modification of code), PolyX will cause a crash pretty rapidly. It is rare (but not impossible) to have the crash show up intermittently or only after a long period of time. An easy litmus test is to try running sample apps from DynamoRio (or other DBI platforms like Pin) against your application. If those fail, then it is unlikely that PolyX will be compatible with your application.
However, if DynamoRio samples work, and PolyX is still crashing, please contact firstname.lastname@example.org and we will help you out.
PolyX detects incoming attacks and reports them through standard Linux reporting channels. Currently, PolyX's detection features generate a stack smashing error, "stack smashing detected". Note that PolyX can detect stack smashing, even in the presence of a Blind ROP attack.