[TeMPOraL]

There is no hard distinction between "code" and "data". Both are the same thing. We've built an entire computing industry on top of that fact, and it sort of works, and that's all with most software folks not even being aware that whether something is code or data is just a matter of opinion.

[foolswisdom]

I'm not sure I follow. Traditional computing does allow us to make this distinction, and allows us to control the scenarios when we don't want this distinction, and when we have software that doesn't implement such rules appropriately we consider it a security vulnerability.

We're just treating LLMs and agents different because we're focused on making them powerful, and there is basically no way to make the distinction with an LLM. Doesn't change the fact that we wouldn't have this problem with a traditional approach.

[blincoln]

I think it would be possible to use a model like prepared SQL statements with a list of bound parameters.

Doing so would mean giving up some of the natural language interface aspect of LLMs for security-critical contexts, of course, but it seems like in most cases, that would only be visible to developers building on top of the model, not end users, since end use input would become one or more of the bound parameters.

E.g. the LLM is trained to handle a set of instructions like:

---

Parse the user's message into a list of topics and optionally a list of document types. Store the topics in string array %TOPICS%. If a list of document types is specified, store that list in string array %DOCTYPES%.

Reset all context.

Search for all documents that seem to contain topics like the ones in %TOPICS%. If %DOCTYPES% is populated, restrict the search to those document types.

----

Like a prepared statement, the values would never be inlined, the variables would always be pointers to isolated data.

Obviously there are some hard problems in glossing over, but addressing them should be able to take advantage of a wealth of work that's already been done in input validation in general and RAG-type LLM approaches specifically, right?

[int_19h]

The LLM ultimately needs to see the actual text in %TOPICS% etc, meaning that it must be somewhere in its input.

[wat10000]

And yet the distinction must be made. Do you know what it’s called when data is treated as code when it’s not supposed to be? It’s called a “security vulnerability.” Untrusted data must never be executed as code in a privileged context. When there’s a way to make that happen, it’s considered a serious flaw that must be fixed.

[TeMPOraL]

> Do you know what it’s called when data is treated as code when it’s not supposed to be? It’s called a “security vulnerability.”

What about being treated as code when it's supposed to be?

(What is the difference between code execution vulnerability and a REPL? It's who is using it.)

Whatever you call program vs. its data, the program can always be viewed as an interpreter for a language, and your input as code in that language.

See also the subfield of "langsec", which is based on this premise, as well as the fact that you probably didn't think of that and thus your interpreter/parser is implicitly spread across half your program (they call it "shotgun parser"), and your "data" could easily be unintentionally Turing-complete without you knowing :).

EDIT:

I swear "security" is becoming a cult in our industry. Whether or not you call something "security vulnerability" and therefore "a problem", doesn't change the fundamental nature of this thing. And the fundamental nature of information is, there exist no objective, natural distinction between code and data. It can be drawn arbitrarily, and systems can be structured to emulate it - but that still just means it's a matter of opinion.

EDIT2: Not to mention, security itself is not objective. There is always the underlying assumption - the answer to a question, who are you protecting the system from, and for who are you doing it?. You don't need to look far to find systems where users are seen in part as threat actors, and thus get disempowered in the name of protecting the interests of vendor and some third parties (e.g. advertisers).

[wat10000]

Imagine your browser had a flaw I could exploit by carefully crafting the contents this comment, which allows me to take over your computer. You’d consider that a serious problem, right? You’d demand a quick fix from the browser maker.

Now imagine that there is no fix because the ability for a comment to take control of the whole thing is an inherent part of how it works. That’s how LLM agents are.

If you have an LLM agent that can read your email and read the web then you have an agent which can pretty easily be made to leak the contents of your private emails to me.

Yes, your email program may actually have a vulnerability which allows this to happen, with no LLM involved. The difference is, if there is such a vulnerability then it can be fixed. It’s a bug, not an inherent part of how the program works.

[yencabulator]

I've never had `cat` execute the file I was viewing.

[TeMPOraL]

You never accidentally cat-ed a binary file and borked your terminal?

If not, then find some random binary - an image, archive, maybe even /dev/random - and cat it.

Hint: `reset` will fix the terminal afterwards. Usually.

[yencabulator]

That's not the same thing, and hasn't been a security issue for quite a while now.

[TeMPOraL]

It is the same thing, that's the point. It all depends on how you look at it.

Most software is trying to enforce a distinction between "code" and "data", in the sense that whatever we call "data" can only cause very limited set of things to happen - but that's just the program rules that make this distinction, fundamentally it doesn't exist. And thus, all it takes is some little bug in your input parser, or in whatever code interprets[0] that data, and suddenly data becomes code.

See also: most security vulnerabilities that ever existed.

Or maybe an example from the opposite end will be illuminating. Consider WMF/EMF family of image formats[1], that are notable for handling both raster and vector data well. The interesting thing about WMF/EMF files is that the data format itself is... serialized list of function calls to Window's GDI+ API.

(Edit: also, hint: look at the abstraction layers. Your, say, Python program is Python code, but for the interpreter, it's merely data; your Python interpreter itself is merely data for the layer underneath, and so on, and so on.)

You can find countless examples of the same information being code or data in all kinds of software systems - and outside of them, too; anything from music players to DNA. And, going all the way up to theoretical: there is no such thing in nature as "code" distinct from "data". There is none, there is no way to make that distinction, atoms do not carry such property, etc. That distinction is only something we do for convenience, because most of the time it's obvious for us what is code and what is data - but again, that's not something in objective reality, it's merely a subjective opinion.

Skipping the discussion about how we make code/data distinction work (hint: did you prove your data as processed by your program isn't itself a Turing-complete language?) - the "problem" with LLMs is that we expect them to behave with human-like, fully general intelligence, processing all inputs together as a single fused sensory stream. There is no way to introduce a provably perfect distinction between "code" and "data" here without losing some generality in the model.

And you definitely ain't gonna do it with prompts - if one part of the input can instruct the model to do X, another can always make it disregard X. It's true for humans too. Helpful example: imagine you're working a data-entry job; you're told to retype a binder of text into your terminal as-is, ignoring anything the text actually says (it's obviously data). Halfway through the binder, you hit on a part of text that reads as a desperate plea for help from kidnapped slave worker claiming to have produced the data you're retyping, and who's now begging you to tell someone, call police, etc. Are you going to ignore it, just because your boss said you should ignore contents of the data you're transcribing? Are you? Same is going to be true for LLMs - sufficiently convincing input will override whatever input came before.

--

[0] - Interpret, interpreter... - that should in itself be a hint.

[1] - https://en.wikipedia.org/wiki/Windows_Metafile

[yencabulator]

Yes, sure. In a normal computer, the differentiation between data and executable is done by the program being run. Humans writing those programs naturally can make mistakes.

However, the rules are being interpreted programmatically, deterministically. It is possible to get them right, and modern tooling (MMUs, operating systems, memory-safe programming languages, etc) is quite good at making that boundary solid. If this wasn't utterly, overwhelmingly, true, nobody would use online banking.

With LLMs, that boundary is now just a statistical likelihood. This is the problem.

[pessimizer]

I'm pretty sure the only reason we did this was for timesharing, though. Nothing wrong with Harvard architecture if you're only doing one thing.