7 ms·

[EDIT: See the response by a Cursor dev below — looks like it was not authorized by them] Sounds to me like Cursor internally has a private NPM registry with t

by n2d4 2y ago

[EDIT: See the response by a Cursor dev below — looks like it was not authorized by them] Sounds to me like Cursor internally has a private NPM registry with those packages. Because of how NPM works, it's quite easy to trick it to fetch the packages from the public registry instead, which could be used by an attacker [0]. Assumably, this Snyk employee either found or suspected that some part of Cursor's build is misconfigured as above, and uploaded those packages as a POC. (Given the package description "for Cursor", I'd think they were hired for this purpose.) If that's the case, then there's not much to see here. The security researcher couldn't have used a private NPM registry to perform the POC if the point is to demonstrate a misconfiguration which skips the private registry. . [0] In particular, many proxies will choose the public over the private registry if the latest package version is higher: https://snyk.io/blog/detect-prevent-dependency-confusion-attacks-npm-supply-chain-security/ https://snyk.io/blog/detect-prevent-dependency-confusion-att...

arkadiyt 2y ago
> If that's the case, then there's not much to see here They could have demonstrated the POC without sending data about the installing host, including all your environment variables, upstream. That seems like crossing the line
ArVID220u 2y ago
cursor dev here. reasonable assumptions, but not quite the case. the snyk packages are just the names of our bundled extensions, which we never package nor upload to any registry. (we do it just like how VS Code does it: https://github.com/microsoft/vscode/tree/main/extensions https://github.com/microsoft/vscode/tree/main/extensions) we did not hire snyk, but we reached out to them after seeing this and they apologized. we did not get any confirmation of what exactly they were trying to do here (but i think your explanation that someone there suspected a dependency confusion vulnerability is plausible. though it's pretty irresponsible imo to do that on public npm and actually sending up the env variables)
- syndicatedjelly 2y ago
  [flagged]
  - benatkin 2y ago
    Yeah, I strongly disagree with the way it's characterized here.
    - TimTheTinker 2y ago
      > we reached out to them after seeing this and they apologized. How does this make it sound like they made Snyk apologize?
- IAmGraydon 2y ago
  [flagged]
  - Atotalnoob 2y ago
    It’s a techbro thing. Sama does it too
    - brookst 2y ago
      e. e. cummings, techbro. who knew?
    - benatkin 2y ago
      You're writing in rust-inspired English it seems, omitting the punctuation mark at the end of your second sentence so it gets returned.
      - compootr 2y ago
        it's typesafe and efficient
  - deleted 2y ago
    [deleted]
nomilk 2y ago
> If that's the case, then there's not much to see here. Allowing someone full access to the contents of your environment (i.e. output of env command) is a big deal to most, I suspect.
- LtWorf 2y ago
  If /proc is mounted you can read all of that.
NitpickLawyer 2y ago
Wasn't this supposed to be fixed in NPM? I remember a talk by the researcher behind portswigger (sorry blanking on his name) doing this a while back, with great success (apple,ms,meta, basically all faang were vulnerable at that time).
rdegges 2y ago
Hey there! I run DevRel & SecRel @ Snyk, we just published a piece to help dispel all the rumors, etc. This provides a lot of in-depth info on the situation: https://snyk.io/blog/snyk-security-labs-testing-update-cursor-com-ai-code-editor/ https://snyk.io/blog/snyk-security-labs-testing-update-curso...
- BeefWellington 2y ago
  This response doesn't make a lot of sense. What's the justification for taking all of the environment variables? This post tries to paper over that particular problem. If your goal was to see if you could attack the dependency chain the first steps of user+hostname would have been sufficient to prove your case. Taking the environment variables is about taking the secrets, and kind of moves this from PoC to opposition supply chain attack. Not to mention it's not only Cursor devs that would be affected by this, it could have (if your plan worked) attacked anyone using the extensions. It's also a tough buy given the note about the Snyk cofounder moving to compete directly with Cursor (courtesy @tankster): https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-500m-valuation-to-build-ai-that-writes-and-maintains-code/ https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50... Assuming truly innocent motivations, you guys still need to give your heads a shake and rethink your approaches here.
  - bangaladore 2y ago
    Frankly I wouldn't be surprised if this was a case of Hanlon's razor. Some "researcher" thought well ENV vars will certainly show us what we want and that's where the conversation ended without thinking a little harder into what else might be in the vars.
    - neonerosion 2y ago
      That's not really plausible in the modern legislative environment (pun intended), considering your env vars will contain GDPR-controlled data like your username, at the very least. Combined with the IP address it was collected from, they know who you are and where you live.

by n2d4 2y ago

arkadiyt 2y ago

> If that's the case, then there's not much to see here They could have demonstrated the POC without sending data about the installing host, including all your environment variables, upstream. That seems like crossing the line

ArVID220u 2y ago

cursor dev here. reasonable assumptions, but not quite the case. the snyk packages are just the names of our bundled extensions, which we never package nor upload to any registry. (we do it just like how VS Code does it: https://github.com/microsoft/vscode/tree/main/extensions https://github.com/microsoft/vscode/tree/main/extensions) we did not hire snyk, but we reached out to them after seeing this and they apologized. we did not get any confirmation of what exactly they were trying to do here (but i think your explanation that someone there suspected a dependency confusion vulnerability is plausible. though it's pretty irresponsible imo to do that on public npm and actually sending up the env variables)

syndicatedjelly 2y ago
[flagged]
- benatkin 2y ago
  Yeah, I strongly disagree with the way it's characterized here.
  - TimTheTinker 2y ago
    > we reached out to them after seeing this and they apologized. How does this make it sound like they made Snyk apologize?
IAmGraydon 2y ago
[flagged]
- Atotalnoob 2y ago
  It’s a techbro thing. Sama does it too
  - brookst 2y ago
    e. e. cummings, techbro. who knew?
  - benatkin 2y ago
    You're writing in rust-inspired English it seems, omitting the punctuation mark at the end of your second sentence so it gets returned.
    - compootr 2y ago
      it's typesafe and efficient
- deleted 2y ago
  [deleted]

nomilk 2y ago

> If that's the case, then there's not much to see here. Allowing someone full access to the contents of your environment (i.e. output of env command) is a big deal to most, I suspect.

LtWorf 2y ago
If /proc is mounted you can read all of that.

NitpickLawyer 2y ago

Wasn't this supposed to be fixed in NPM? I remember a talk by the researcher behind portswigger (sorry blanking on his name) doing this a while back, with great success (apple,ms,meta, basically all faang were vulnerable at that time).

rdegges 2y ago

Hey there! I run DevRel & SecRel @ Snyk, we just published a piece to help dispel all the rumors, etc. This provides a lot of in-depth info on the situation: https://snyk.io/blog/snyk-security-labs-testing-update-cursor-com-ai-code-editor/ https://snyk.io/blog/snyk-security-labs-testing-update-curso...

BeefWellington 2y ago
This response doesn't make a lot of sense. What's the justification for taking all of the environment variables? This post tries to paper over that particular problem. If your goal was to see if you could attack the dependency chain the first steps of user+hostname would have been sufficient to prove your case. Taking the environment variables is about taking the secrets, and kind of moves this from PoC to opposition supply chain attack. Not to mention it's not only Cursor devs that would be affected by this, it could have (if your plan worked) attacked anyone using the extensions. It's also a tough buy given the note about the Snyk cofounder moving to compete directly with Cursor (courtesy @tankster): https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-500m-valuation-to-build-ai-that-writes-and-maintains-code/ https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50... Assuming truly innocent motivations, you guys still need to give your heads a shake and rethink your approaches here.
- bangaladore 2y ago
  Frankly I wouldn't be surprised if this was a case of Hanlon's razor. Some "researcher" thought well ENV vars will certainly show us what we want and that's where the conversation ended without thinking a little harder into what else might be in the vars.
  - neonerosion 2y ago
    That's not really plausible in the modern legislative environment (pun intended), considering your env vars will contain GDPR-controlled data like your username, at the very least. Combined with the IP address it was collected from, they know who you are and where you live.