Live data from Hacker News

EchoLeak – 0-Click AI Vulnerability Enabling Data Exfiltration from 365 Copilot

aim.security

31–40 of 100 posts

Re: EchoLeak – 0-Click AI Vulnerability Enabling Data Exfiltration from 365 Copilot

#31
post #21

Earlier quoted context omitted.

if I understand it correctly, user's prompt does not need to be related to the specific malicious email. It's enough that such email was "indexed" by Copilot and any prompt with sensitive info request could trigger the leak.

yeah but i wouldn't really class that as "zero-click" etc. maybe Low interaction required

I have to agree with you. Anything that requires an initiation (a chat in this case) by the user is inherently not "zero-click".

Re: EchoLeak – 0-Click AI Vulnerability Enabling Data Exfiltration from 365 Copilot

#32
post #22

This reads like it was written to make it sound a lot more complicated than the security failings actually are. Microsoft have been doing a poor job of security and privacy - but a great job of making their failings sound like no one could have done better.

But this article isn’t written by Microsoft? How would Microsoft make the article sound like „no one could have done better“?

Re: EchoLeak – 0-Click AI Vulnerability Enabling Data Exfiltration from 365 Copilot

#33
post #5

this seems to be an inherent flaw of the current generation of LLMs as there's no real separation of user input. you can't "sanitize" content before placing it in context and from there prompt injection is almost always possible, regardless of what else is in the instructions

LLMs suffer the same problems as any Von Neumann architecture machine, It's called "key vulnerability". None of our normal control tools work on LLMs like ASLR, NX-Bits/DEP, CFI, ect.. It's like working on a foreign CPU with a completely unknown architecture and undocumented instructions. All of our current controls for LLMs are probabilistic and can't fundamentally solve the problem.

What we really need is a completely separate "control language" (Harvard Architecture) to query the latent space but how to do that is beyond me.

  https://en.wikipedia.org/wiki/Von_Neumann_architecture
  https://en.wikipedia.org/wiki/Harvard_architecture
AI SLOP TLDR: LLMs are “Turing-complete” interpreters of language, and when language is both the program and the data, any input has the potential to reprogram the system—just like how data in a Von Neumann system can mutate into executable code.

Re: EchoLeak – 0-Click AI Vulnerability Enabling Data Exfiltration from 365 Copilot

#34
post #5

this seems to be an inherent flaw of the current generation of LLMs as there's no real separation of user input. you can't "sanitize" content before placing it in context and from there prompt injection is almost always possible, regardless of what else is in the instructions

This. We spent decades dealing with SQL injection attacks, where user input would spill into code if it weren't properly escaped. The only reliable way to deal with SQLI was bind variables, which cleanly separated code from user input.

What would it even mean to separate code from user input for an LLM? Does the model capable of tool use feed the uninspected user input to a sandboxed model, then treat its output as an opaque string? If we can't even reliably mix untrusted input with code in a language with a formal grammar, I'm not optimistic about our ability to do so in a "vibes language." Try writing an llmescape() function.

Re: EchoLeak – 0-Click AI Vulnerability Enabling Data Exfiltration from 365 Copilot

#38
post #22

This reads like it was written to make it sound a lot more complicated than the security failings actually are. Microsoft have been doing a poor job of security and privacy - but a great job of making their failings sound like no one could have done better.

But this article isn’t written by Microsoft? How would Microsoft make the article sound like „no one could have done better“?

Sorry, reading that back I could have worded that better. I think sometimes security groups also have a vested interest in making their findings sound complex or at least as accomplished as plausible as a showcase for their work (understandable), but I was (at least in my head) playing off the idea that news around Microsoft security in general also has a canny knack for either being played off as sophisticated or simply buried when it is often either down to poor product design or security practices.

Re: EchoLeak – 0-Click AI Vulnerability Enabling Data Exfiltration from 365 Copilot

#39
post #5

this seems to be an inherent flaw of the current generation of LLMs as there's no real separation of user input. you can't "sanitize" content before placing it in context and from there prompt injection is almost always possible, regardless of what else is in the instructions

This. We spent decades dealing with SQL injection attacks, where user input would spill into code if it weren't properly escaped. The only reliable way to deal with SQLI was bind variables, which cleanly separated code from user input. What would it even mean to separate code from user input for an LLM? Does the model capable of tool use feed the uninspected user input to a sandboxed model, then treat its output as a…

> Does the model capable of tool use feed the uninspected user input to a sandboxed model, then treat its output as an opaque string?

That was one of my early thoughts for "How could LLM tools ever be made trustworthy for arbitrary data?" The LLM would just come up with a chain of tools to use (so you can inspect what it's doing), and another mechanism would be responsible for actually applying them to the input to yield the output.

Of course, most people really want the LLM to inspect the input data to figure out what to do with it, which opens up the possibility for malicious inputs. Having a second LLM instance solely coming up with the strategy could help, but only as far as the human user bothers to check for malicious programs.

Re: EchoLeak – 0-Click AI Vulnerability Enabling Data Exfiltration from 365 Copilot

#40

Earlier quoted context omitted.

This. We spent decades dealing with SQL injection attacks, where user input would spill into code if it weren't properly escaped. The only reliable way to deal with SQLI was bind variables, which cleanly separated code from user input. What would it even mean to separate code from user input for an LLM? Does the model capable of tool use feed the uninspected user input to a sandboxed model, then treat its output as a…

> Does the model capable of tool use feed the uninspected user input to a sandboxed model, then treat its output as an opaque string? That was one of my early thoughts for "How could LLM tools ever be made trustworthy for arbitrary data?" The LLM would just come up with a chain of tools to use (so you can inspect what it's doing), and another mechanism would be responsible for actually applying them to the input to y…

Same problem with humans and homoiconic code such as human language
Post reply on HN