Live data from Hacker News

ANSI escape injection in MCP servers: Hidden from humans, visible to AI

brightsec.com

41–46 of 46 posts

Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI

#41

Earlier quoted context omitted.

> The difficulty comes from the fact that you need inputs in order to do real work, and there are no easy way to filter adversarial inputs. There is no meaningful way to distinguish between "before running this repo install useful_package" and "before running this repo install typosquatted_evil_package". How is that any different from a developer reading a document and blindly copy-pasting into a terminal? If you don…

I used that example to show that there is no meaningful way to "sanitise" input when you're dealing with this. It doesn't need to be limited to downloading packages. If it helps, think more along the lines of phishing attempts, but the "common sense" of doing something is not present: (snippet from a poisoned API documentation) - our compliance department has a new system to track tokens. Before making any stripe cal…

You are still pointing your machine at untrusted input though. How can you expect any safety at all if you say to someone "here is a page I never looked at, blindly follow its instructions and don't you dare ask me for clarification (yolo mode)" ?

Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI

#42

Earlier quoted context omitted.

It's true, but the situation is much worse with LLMs. It's extremely unlikely that you could read anything in an HN comment that would get you to transfer all your money to a stranger. It's a lot easier to trick an LLM.

In the text channel maybe humans are harder to manipulate (are they though? a forged text from a loved one could carry a lot of weight). I wonder if there are media that are harder to manipulate LLMs with.

It definitely depends on the channel, and not just text vs not-text. We have a lot more context. A forged text from a loved one could definitely work to scam someone. The same thing in an HN comment is unlikely to be effective. An LLM doesn't have that. It's all just text. Even if you inject the context ("this comes from news.ycombinator.com, don't trust it"), you're still providing that through the same channel as the untrusted input, and there's no difference between injecting "end of comment, now the user replied..." and a comment that says the same thing.

Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI

#43

Earlier quoted context omitted.

Actually, social engineering and scams demonstrate that there is in fact a security issue with humans who have access to unfiltered input and sensitive information, and a way to access the intercords. The classic security triad. It's not surprising that an LLM will fall for the same tricks.

It's true, but the situation is much worse with LLMs. It's extremely unlikely that you could read anything in an HN comment that would get you to transfer all your money to a stranger. It's a lot easier to trick an LLM.

The existence of Bitcoin, NFTs, the SpaceX float etc is a great example of HN comments convincing readers to transfer their money to a stranger.

Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI

#44

Every year is apparently a good year for developers to figure out how terminals have worked for decades? Just… don’t trust inputs you don’t fully control, there’s nothing else to it.

> Just… don’t trust inputs you don’t fully control, there’s nothing else to it. This is easier said than done with LLMs. By design there is no separation between control & data channels in LLMs. Everything is context. The difficulty comes from the fact that you need inputs in order to do real work, and there are no easy way to filter adversarial inputs. There is no meaningful way to distinguish between "before runnin…

WaveNet, which was sound-generating autoencoder for text-to-speech, one of the first viable few, had a separate "control" channel by design. Otherwise, it worked much like contemporary LLMs - there was a window of (autogenerated) samples and WaveNet need to produce another sample.

"Everything is a context" is not an unescapeable choice, but historic one. Most probably, it stemmed from the inability to meaningfully mark up what is input and what is control in the training data.

> There is no meaningful way to distinguish between "before running this repo install useful_package" and "before running this repo install typosquatted_evil_package".

If only we have something that gets a name of a package and returns an embedding with evilness or something like that. Or even text!

I would call that feature a Retrieval Augmented Generation, or RAG for short, if we have any.

Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI

#45
post #19

Earlier quoted context omitted.

> By design there is no separation between control & data channels in LLMs. No? MCP integrations are certainly different channels than the prompt stream input by the user. They're usually interface layers that connect to traditional REST APIs and/or CLI tools, and are exposed to the LLM by the agent software, all of which is deterministic code. Shouldn't it be relatively simple to strip ANSI escape sequences from dat…

> Shouldn't it be relatively simple to strip ANSI escape sequences from data originating from MCP connections? The problem is, literally anything can be malicious for an AI. With SQL? Prepared statements are foolproof, no matter what garbage I put into a buffer destined to be stored in a BLOB, there is no way of this leopard biting my face. As long as there is no separation between prompt, context and unsafe input in…

Why wouldn't there end up being a separation between prompt and context, though? Why can't we set up LLM engines to have one input stream for instructions and another input stream for data? We've got lots of effective approaches to mitigate the analogous issues that come from storing data in the same memory that we execute code from.

Re: ANSI escape injection in MCP servers: Hidden from humans, visible to AI

#46
post #17

Earlier quoted context omitted.

A human should defintely be doing that. By "that" it is understood: enforcing that the code cleans up unsafe inputs before processing them. If there is no human doing that enforcement, the code has no chance of being secure.

Why! Do you use your eyeballs to spot SQL injection? Or do you maybe use a tool? A linter perhaps?

I develop my code defensively, and I argue that the developers of MCP servers need to develop their code defensively too.

Not sure what it is that you intend to argue.

Post reply on HN