[schwag09]

> In computing, the relationship between structure and behavior, between program and process, is perplexing in itself. That this relationship so often can be subverted, allowing an untrusted data provider to preternaturally gain control over program execution, is disquieting. Why is this a common phenomenon in computer systems?

Mixing code and content leads to all the most common injection-style vulnerability classes: buffer overflows, XSS, SQLi, command injection, etc. Fundamentally, I believe this is at the heart of the problem. The paper does go on to address this:

> Another proposed theory blames John von Neumann's stored program concept [15] for the woes of arbitrary code execution; the fact that data and program in computers are stored on the same storage medium may allow an attacker to illegitimately modify the program rather than the intended data [10].

From there it provides ROP as a counterpoint to the "stored-program hypothesis." This makes sense because ROP allows one to achieve arbitrary code execution without necessarily modifying the code. Although, while I agree that mixing code and content may not be the highest level abstraction for concern here, I do think it's often a fundamental flaw from a practical perspective.

[ukj]

Your fundamental flaw is my prized feature.

Metaprogramming/reflection would be impossible without treating code as content.

[schwag09]

Let me rephrase, I think it's often a fundamental flaw from a practical, security perspective. Reflection and constructs like 'eval' are often at odds with security. You could more generally say that utility is often at odds with security.

Maximizing utility on a website might look like dropping a user into a root REPL so they can perform arbitrary actions and are unlimited in their capabilities. Maximizing security might look like shutting down the website and all its associated servers. In reality, from a security perspective, we try to achieve a balance between the two by maximizing utility while minimizing security risk.

Personally, I think code as content, reflection, eval, etc move the slider too far in the utility direction. Of course this is a difficult problem to solve because nearly all our systems are built on the idea of code as content, which is also what makes it such a generalized vulnerability class.

[lisper]

And this tension in goals is not limited to software. Modifying and repairing hardware is similarly fraught. You can get yourself into all kinds of trouble by tinkering with (say) your car.

The real difference is that you generally have to be in physical proximity to hardware in order to tinker with it, and that puts a very hard constraint on random people mucking with your car. Not so for software, especially in the age of the internet.

[lucian1900]

Not at all, even in Lisps there’s quoting. In-band signalling isn’t necessary for either meta programming or reflection.

[ukj]

Saying the same thing from yet another perspective:

What you call in-band - I call data. What you call out-of-band - I call code.

What I call metaprogramming is erasing the distinction.

[ukj]

Signalling is the same thing as mutability. To signal is to flip a bit.

If code is data and data is immutable then code is immutable.

I am sure you see the contradiction in objectives.