4 ms·

I read it, and "attack" does not make sense. If you grant access to MCP to access some data (data you want anybody has access to like public repos, and data tha

by mirzap 1y ago

I read it, and "attack" does not make sense. If you grant access to MCP to access some data (data you want anybody has access to like public repos, and data that only you want to access to like private repos), you will always be able to craft the prompt that will "leak" the data you are only supposed to access. That's not surprising at all. The only way to prevent these kind of "leaks" is not to provide the data feed with private data to the agent.

motorest 1y ago
> I read it, and "attack" does not make sense. Do you believe that describe a SQL injection attack an attack also does not make sense?
- mirzap 1y ago
  That's the thing. LLM or MCP is not a database. You can’t compare it. You simply can't set the permissions or guardrails within LLMs or MCPs. You always do it layer above (scoping to what LLM has access to).
  - motorest 1y ago
    > That's the thing. LLM or MCP is not a database. You can’t compare it. You can. Read the article. A malicious prompt is injected into an issue to trigger the repo owner's LLM agent to execute it with the agent's credentials.
    - mirzap 1y ago
      "with the agent's credentials." - so you are surprised that agent can respond with private repository details when it has access to it? WoW! anyone and anything with credentials can access it. Github action, Jenkins, me. "injected" is so fancy word to describe prompting - one thing that LLMs are made to do - respond to a prompt.
      - dylanfw 1y ago
        The "surprise" is not that the agent can respond with private repository details, it's that it can receive and act upon prompts issued by someone other than the person running the agent, hence "prompt _injection_". Or to come back to the SQL injection analogy, no one is surprised that the web app can query the database for password hashes. The surprise is that it can be instructed to do so when loading the next image in a carousel.
      - cutemonster 1y ago
        Did you read the article? The attack is not via the prompt the victim types to the AI, but via [text in an issue or PR in the repo] that the victim is unaware about.
  - mirzap 1y ago
    @motorest read again what I wrote: "That's the thing. LLM or MCP is not a database. You can’t compare it. You simply can't set the permissions or guardrails within LLMs or MCPs. You always do it layer above (scoping to what LLM has access to)." You can not HIDE the data MCP has access to. With a database and SQL, you can! So it can not be comparable with SQL injection.
    - frabcus 1y ago
      Absolutly you can - the UX of the whole experience MCP is part of could make it clear to the user what repositories can be accessed according to the project they're working on. Rather than when they're working on the public project, the LLM being given access to repos of the private projects.
krisoft 1y ago
> That's not surprising at all An attack doesn’t have to be surprising to be an attack. > The only way to prevent these kind of "leaks" is not to provide the data feed with private data to the agent. Yes. That is exactly what the article recommends as a mitigation.
- mirzap 1y ago
  > An attack doesn’t have to be surprising to be an attack. If you open an API to everyone, or put a password as plain text and index it, it's no surprise that someone accesses the "sensitive" data. Nor do I consider that an attack. You simply can't feed the LLM the data, or grant it access to the data, then try to mitigate the risk by setting "guardrails" on the LLM itself. There WILL ALWAYS be a prompt to extract any data LLM has access to. > Yes. That is exactly what the article recommends as a mitigation. That's common sense, not mitigation. Expecting "security experts" to recommend that is like expecting a recommendation to always hash the password before storing it in the DB. Common sense. Obvious.
  - Xelynega 1y ago
    I don't understand your logic. Should security reports never be published that say "hash the password before storing it in the DB". Boring research is boring most of the time, that doesn't make it unimportant, no?
    - mirzap 1y ago
      No, but it's not the database's fault if you don't hash your password. Same here, it's human error, not "MCP vulnerability". It's not that GitHub MCP needs fixing, but rather how you use it. That's the entire point of my reasoning for this "exploit."
  - krisoft 1y ago
    > it's no surprise The amount of your surprise is not a factor weather it is an attack or not. You have been already asked about sql injections. Do you consider them attacks? They are very similar. You concatenate an untrusted string with an sql query, and execute the resulting string on the database. Of course you are going to have problems. This is absolutely unsuprising and yet we still call it an attack. Somehow people manage to fall into that particular trap again and again. Tell me which one is the case: do you not consider sql injection attacks attacks, or do you consider them somehow more surprising than this one? > That's common sense, not mitigation. Something can be both. Locking your front door is a mitigation against opportunistic burglars, and at the same time is just common sense. > Expecting "security experts" to recommend that is like expecting a recommendation to always hash the password before storing it in the DB. That is actually a real world security advice. And in fact if you recall it is one many many websites were not implementing for very long times. So seemingly it was less common sense for some than it is for you. And even then you can implement it badly vs implement it correctly. (When i started in this business a single MD5 hash of the password was often recommended, then later people started talking about salting the hash, and even later people started talking about how MD5 is entirely too weak and you really ought to use something like bcrypt if you want to do it right.) Is all of that detail common sense too? Did you sprung into existence fully formed with the full knowledge of all of that, or had you had to think for a few seconds before you reinvented bcrypt on your own? > Common sense. Obvious. Good! Excelent. It was common sense and obvious to you. That means you are all set. Nothing for you to mitigate, because you already did. I guess you can move on and do the next genious thing while people less fortunate than you patch their workflows. Onward and upward!
raesene9 1y ago
The key is, it's not the person who grants the MCP access who is the attacker. The attacker is some other person who can create issues on a public Repo but has no direct access to the private repo.
- mirzap 1y ago
  The point is this is NOT a GitHub MCP vulnerability, but how you use it. There is nothing to be fixed in MCP itself; rather how you use it.
  - motorest 1y ago
    > The point is this is NOT a GitHub MCP vulnerability, but how you use it. You're the only one talking about GitHub MCP vulnerabilities. Everyone else is talking about GitHub MCP exploits. It's in the title, even.
    - mirzap 1y ago
      Tomato-Tomato. It's not even an exploit. I will give you my token with access only to public repos. Try and access my private repos with Github MCP. Guess what - you can't - so it is not Github MCP exploit.
skywhopper 1y ago
Not surprising to you, but surprising to thousands of users who will not think about this, or who will have believed the marketing promises.
- mirzap 1y ago
  Well I saw vibe coders commit .env files with real credentials to public repository, but I didn't see anyone blaming Git for allowing .env or secrets to be commited in the first place.
bloppe 1y ago
Your issue with the semantics of the word "attack" is uninteresting. Clearly this is a security flaw of the MCP server that could be mitigated in several different ways.

by mirzap 1y ago

motorest 1y ago

> I read it, and "attack" does not make sense. Do you believe that describe a SQL injection attack an attack also does not make sense?

mirzap 1y ago
That's the thing. LLM or MCP is not a database. You can’t compare it. You simply can't set the permissions or guardrails within LLMs or MCPs. You always do it layer above (scoping to what LLM has access to).
- motorest 1y ago
  > That's the thing. LLM or MCP is not a database. You can’t compare it. You can. Read the article. A malicious prompt is injected into an issue to trigger the repo owner's LLM agent to execute it with the agent's credentials.
  - mirzap 1y ago
    "with the agent's credentials." - so you are surprised that agent can respond with private repository details when it has access to it? WoW! anyone and anything with credentials can access it. Github action, Jenkins, me. "injected" is so fancy word to describe prompting - one thing that LLMs are made to do - respond to a prompt.
    - dylanfw 1y ago
      The "surprise" is not that the agent can respond with private repository details, it's that it can receive and act upon prompts issued by someone other than the person running the agent, hence "prompt _injection_". Or to come back to the SQL injection analogy, no one is surprised that the web app can query the database for password hashes. The surprise is that it can be instructed to do so when loading the next image in a carousel.
    - cutemonster 1y ago
      Did you read the article? The attack is not via the prompt the victim types to the AI, but via [text in an issue or PR in the repo] that the victim is unaware about.
- mirzap 1y ago
  @motorest read again what I wrote: "That's the thing. LLM or MCP is not a database. You can’t compare it. You simply can't set the permissions or guardrails within LLMs or MCPs. You always do it layer above (scoping to what LLM has access to)." You can not HIDE the data MCP has access to. With a database and SQL, you can! So it can not be comparable with SQL injection.
  - frabcus 1y ago
    Absolutly you can - the UX of the whole experience MCP is part of could make it clear to the user what repositories can be accessed according to the project they're working on. Rather than when they're working on the public project, the LLM being given access to repos of the private projects.

krisoft 1y ago

> That's not surprising at all An attack doesn’t have to be surprising to be an attack. > The only way to prevent these kind of "leaks" is not to provide the data feed with private data to the agent. Yes. That is exactly what the article recommends as a mitigation.

mirzap 1y ago
> An attack doesn’t have to be surprising to be an attack. If you open an API to everyone, or put a password as plain text and index it, it's no surprise that someone accesses the "sensitive" data. Nor do I consider that an attack. You simply can't feed the LLM the data, or grant it access to the data, then try to mitigate the risk by setting "guardrails" on the LLM itself. There WILL ALWAYS be a prompt to extract any data LLM has access to. > Yes. That is exactly what the article recommends as a mitigation. That's common sense, not mitigation. Expecting "security experts" to recommend that is like expecting a recommendation to always hash the password before storing it in the DB. Common sense. Obvious.
- Xelynega 1y ago
  I don't understand your logic. Should security reports never be published that say "hash the password before storing it in the DB". Boring research is boring most of the time, that doesn't make it unimportant, no?
  - mirzap 1y ago
    No, but it's not the database's fault if you don't hash your password. Same here, it's human error, not "MCP vulnerability". It's not that GitHub MCP needs fixing, but rather how you use it. That's the entire point of my reasoning for this "exploit."
- krisoft 1y ago
  > it's no surprise The amount of your surprise is not a factor weather it is an attack or not. You have been already asked about sql injections. Do you consider them attacks? They are very similar. You concatenate an untrusted string with an sql query, and execute the resulting string on the database. Of course you are going to have problems. This is absolutely unsuprising and yet we still call it an attack. Somehow people manage to fall into that particular trap again and again. Tell me which one is the case: do you not consider sql injection attacks attacks, or do you consider them somehow more surprising than this one? > That's common sense, not mitigation. Something can be both. Locking your front door is a mitigation against opportunistic burglars, and at the same time is just common sense. > Expecting "security experts" to recommend that is like expecting a recommendation to always hash the password before storing it in the DB. That is actually a real world security advice. And in fact if you recall it is one many many websites were not implementing for very long times. So seemingly it was less common sense for some than it is for you. And even then you can implement it badly vs implement it correctly. (When i started in this business a single MD5 hash of the password was often recommended, then later people started talking about salting the hash, and even later people started talking about how MD5 is entirely too weak and you really ought to use something like bcrypt if you want to do it right.) Is all of that detail common sense too? Did you sprung into existence fully formed with the full knowledge of all of that, or had you had to think for a few seconds before you reinvented bcrypt on your own? > Common sense. Obvious. Good! Excelent. It was common sense and obvious to you. That means you are all set. Nothing for you to mitigate, because you already did. I guess you can move on and do the next genious thing while people less fortunate than you patch their workflows. Onward and upward!

raesene9 1y ago

The key is, it's not the person who grants the MCP access who is the attacker. The attacker is some other person who can create issues on a public Repo but has no direct access to the private repo.

mirzap 1y ago
The point is this is NOT a GitHub MCP vulnerability, but how you use it. There is nothing to be fixed in MCP itself; rather how you use it.
- motorest 1y ago
  > The point is this is NOT a GitHub MCP vulnerability, but how you use it. You're the only one talking about GitHub MCP vulnerabilities. Everyone else is talking about GitHub MCP exploits. It's in the title, even.
  - mirzap 1y ago
    Tomato-Tomato. It's not even an exploit. I will give you my token with access only to public repos. Try and access my private repos with Github MCP. Guess what - you can't - so it is not Github MCP exploit.

skywhopper 1y ago

Not surprising to you, but surprising to thousands of users who will not think about this, or who will have believed the marketing promises.

mirzap 1y ago
Well I saw vibe coders commit .env files with real credentials to public repository, but I didn't see anyone blaming Git for allowing .env or secrets to be commited in the first place.

bloppe 1y ago

Your issue with the semantics of the word "attack" is uninteresting. Clearly this is a security flaw of the MCP server that could be mitigated in several different ways.