Wednesday, September 5, 2007

Separation of Code and Data

One of the most surprising things for a savvy information security practitioner is the continued prevalence of intermingling of code and data in modern information systems. It is as if some mandate dictates that these items must be desegregated. This is the root cause of every buffer overrun/overflow exploit, every XSS or SQL Injection attack, even Microsoft's infamous run of bugs in office documents and images (think GDI). Yet, today, there are simply too many systems that do not properly (if at all) segregate data objects from executable code objects in memory.

Buffer overruns
The gist is that a program allocates memory for a data object (as in "information" of some type), but because of some implementation bug, executable code can be passed to the function instead of data (because the program does not distinguish the two). And eventually for one reason or another, but mainly because the system does not require executable code to be stored in a location with better access control separate from data elements, the data object is unintentionally executed, frequently containing malicious payloads.

Cross Site Scripting
Most cases of XSS are no different. Essentially, data elements (usually expected to be in the form of plain, rich, or html text) are uploaded containing client-side executable scripts with malicious payloads.

SQL Injection
Again, same song, second verse, only this time the "data" is really malicious SQL commands uploaded as text.

Why, if the top technical causes of malware all share the commonality of not properly segregating code and data, do we not yet have systems that build this property in?

Excellent question, of course. The current-generation attempts to solve this include Address Space Layout Randomization (ASLR), and, more formidably, No Execute (NX). Windows Vista's downfall, of course (all debate on licensing aside) is that for backwards-compliance's sake old applications cannot be forced to segregate their memory objects. And the patterns of lazy or ignorant developers yet again plague both the consumer and the enterprise.

Perhaps one day we'll get this right.

No comments: