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)
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)
Wouldn't it be more like "pretty illegal"? They could have simply used body: JSON.stringify("worked"), i.e. not sent target machines’ actual environment variables, including keys.
It's an unfortunate incentive structure. If you're doing offensive security research, there's two ways you can go about it: you can report the potential vulnerability without exploiting it, in which case you risk the company coming back to you and saying "thanks but we don't consider this a vulnerability because it's only exploited through misconfiguration and we're too smart for that". Maybe you get some token reward of $50.
Or you can exploit it and say here's the PoC, this many people at your company fell for it, and this is some of the valuable data I got, including some tokens you'll have to rotate. This puts you into actual bug bounty territory. Certainly the PR side of things alone will incentivize them to pay you so you don't make too much of a noise about how Cursor leaked a bunch of credentials due to a misconfiguration that surely every good programmer knows about and defends against (like so many vulnerabilities seem so dumb in hindsight).
Cursor does not have a bug bounty though, and its hard to see how this constitutes anything other than a direct attack on them, their users, or both. "The incentive structure made me do it" does not justify acting like a criminal.
Shouldn't this alone be considered criminal negligence at this point? Cursor isn't some random open source project. It's a company that has funding, and subscriptions. Hell, I pay Cursor for a monthly subscription. Pretty incredible that they have no bounty program.
You can also console.log those credentials as a PoC, and then show that the console.log could trivially be replaced by a fetch().
Kind of like a lot of exploit PoCs just "pop a calc" (AKA open the Calculator app), not because opening the calculator is valuable to an attacker, but because if you can open calculator, you can do anything.
The problem there though, is that with PoCs like this, as an attacker you want to have a ping back to your system so that you know the attack has been successful (in this case they probably expected/hoped someone at Cursor to install the package, that's the usual objective in a dependency confusion attack). But what they could have done, is send a less sensitive thing like just the current working directory or current effective user, instead of the whole environment.
What actually changes though in your scenario? Potential bad actor gets RCE on your dev machines, it doesn't really matter what they sent home, you're rotating keys and doing your due diligence either way.
I wonder how viable it would be to find a public key your target owns and use it to encrypt the data you send back. Then you could prove to them that you exfiltrated real data without exposing it to anyone outside the company.
Alternatively, you could hash it and say “Look, it’s a sha of your database password hyphen “yougotpwnd””
Yeah, I agree the incentive structure is broken for bug bounty hunters. Until the BB platforms themselves create some rules for their customers and researchers, we are gonna continue to have the sh*t show that we do now. The reality is that bug bounty hunters are deploying a significant percentage of the total malicious NPM packages each month.
> The reality is that bug bounty hunters are deploying a significant percentage of the total malicious NPM packages each month.
I don't actually think that is a bad thing.
The TSA screening at airports would be vastly better if TSA maintained a "red team" that regularly tried smuggling guns (or water bottles or whatever) into airports. The agents would be more attentive if the number of incidents they dealt with was large enough that they could practice more often. The system could improve if it had actual feedback on how accurate and effective it was. And instead of agents overreacting or underreacting they could tune their responses to an appropriate level.
The same applies to supply chain attacks. The REAL ones are rare, dangerous, and performed by experts; having a chance to practice catching them, to assess our detection rates, and to adjust our reactions is healthy.
Yeah, it sucks, but that's the way it is. It is super common for bug bounty findings to be ignored or downgraded unless you show actual code exec on their machines or dump some of their creds.
It may interest you that Guy Podjarny, one of the Snyk founders, now has an AI coding company (https://www.tessl.io/about) that looks like a competitor of yours
When I grew up online in the 90s, on IRC, AOL/AIM, ICQ and web forums, it was extremely common. Most of the people I know from then still do it, and I still do it with them and in many other places, although for whatever reason I don't do it here. Although it's 50/50 when on their phones now that phones auto-capitalize by default now.
Rules are put in place to be followed, for a reason. Capital letters at the start of the sentence increase readability. People who don't bother with them are being incosiderate towards their readers.
yes but there could be many possible reasons, for instance
- it's muuch faster on mobile
- you're aiming to convey litheness to potential target audiences who will know to recognize it as intentional litheness
- you've gotten used to minimizing the amount of keystrokes necessary for communicating things, to the point it's second nature
- you've worked a lot in the past with older nlp systems, where ignoring capitalization was a given for inputs anyhow, and just got used to treating it as syntactic cruft only strictly necessary in more formal settings ;)
I tend to shy away from intentional illiteracy and laziness, both of which this is an example of. Not capitalizing does also affect readability. That said, I was honestly asking because I’ve seen it a few times on HN in the last couple of weeks and was curious if it’s coincidence or an actual trend.
It’s a low effort flex. As in: you’re unimportant, this is unimportant, and I’m very busy, so I can’t or won’t bother to capitalize. Which is ironic because it’s more effort to not capitalize.
Without commenting on this subthread (I don't have an opinion), you or anyone else with this concern should look into sticky modifiers (modifiers that apply to the next key press without being held). They were a game changer for me personally as far as managing RSI, as I had a bad habit of tilting my wrist to eg type a capital T.
This looks really cool! I'm excited to see a production deployment of DiskANN.
According to the single-threaded QPS experiments, your DiskANN solution should clock in at about 4.5ms latency (1000ms/224QPS) whereas pgvector is about 5.8ms latency (1000ms/173QPS). How is that possible? My (very shallow) knowledge of DiskANN vs HNSW tells me that DiskANN should generally have higher latency than HNSW — DiskANN needs to touch the SSD while HNSW only touches RAM.
Also, compared to pgvector and HNSWPQ in faiss, how much less RAM does your DiskANN-based solution use?
(Blog author here). Thanks for the question. In this case the index for both DiskANN and pgvector HNSW is small enough to fit in memory on the machine (8GB RAM), so there's no need to touch the SSD. We plan to test on a config where the index size is larger than memory (we couldn't this time due to limitations in ANN benchmarks [0], the tool we use).
To your question about RAM usage, we provide a graph of index size. When enabling PQ, our new index is 10x smaller than pgvector HNSW. We don't have numbers for HNSWPQ in FAISS yet.
Any chance me, a lowly OSS Developer and Twitch Streamer of the Small Variety, could acquire access early? I would love to try using it for things like writing Mods for Games and such.
Scaling is definitely why this hasn't been done before — it is hard! Recent research in private information retrieval shows that we can do it for 1 million people (see e.g. https://www.usenix.org/conference/osdi21/presentation/ahmad and https://www.cs.utexas.edu/~dwu4/spiral.html). All of the recent advances still scale as n^2 with the number of users, which becomes prohibitive after 1 million people, but we are working on a paper that shows how we can scale subquadratically (n^{1+1/k}*c^k for a fixed c and any k). With an n^1.33 scheme, 1 billion people suddenly becomes feasible.
With all respect, it is not obviously false. You should take a look at our whitepaper: https://anysphere.co/anysphere-whitepaper.pdf (the figure on page 2 might be helpful). To my knowledge, no other communication platform provides complete metadata privacy like we do. I would love to be disproved here though! It would be awesome if other completely private communication tools exist.
I do agree that there is a general problem where companies make hyperbolic claims, especially when it comes to security/privacy. For example, “zero trust” has been abused by so many people that even in the cases where it might apply, you cannot say that it applies to you because the term has lost its meaning. In our case, users do not need to place any trust in our servers, but we decided not to call it “zero trust” because people have taken it to mean “trust your employees less” or something else similarly outrageous.
If you have any suggestions for how we can improve our messaging here I’d love to take them. In other words, how could we convey that we are indeed the only completely private communication platform, without provoking a reaction similar to yours?
It is obviously false. End-to-end encryption doesn't leak metadata in the way you propose it does in your whitepaper. And it doesn't help that you don't define metadata in your paper, you just repeat it over and over again.
Specifically, what are you talking about protecting? Does this extend to deep packet inspection? Because your paper doesn't mention anything about that either. OR, you know, literally just talking to another server. You don't mention relays. You casually mention Tor in passing but make no concrete statements about the design of it by comparison.
Your paper isn't rigorous, your claims are superfluous, and they further attempt to discredit security progress across the entire field.
YOU are the only one who has ever created truly secure communication? Get real. What a complete joke.
It's like someone selling water and saying no one has ever created pure water before US.
Edit: If you want to appeal to security people, use plain language, be precise, and state your intentions. You do none of those things with this software.
Instead you:
* Use provably wrong marketing language
* Propose a provably wrong whitepaper
* Do not state your intentions for building the software
What it looks like to me is that you received some modest funding ($200,000) to write software and your sponsors didn't realize your work doesn't pass the smell test.
Shengtong chiming in here. We are working on a rigorous security proof here https://anysphere.co/anysphere-security-definition.pdf. Included in it is a definition of metadata, a definition of exactly what we are defending against, as well as a rigorous proof of defense against adversaries that can manipulate packets. It is still work in progress, so there may be a lot of typos, but I believe it is a correct proof.
Let us know if there is anything else you want to be proved, or if the adversary in the paper is not strong enough :).
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)