Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

gist.github.com

Post reply on HN
Print view View original

301–310 of 453 posts

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#301

Post by rslashuser »

staticassertion wrote: post #279
rslashuser wrote: post #182

Earlier quoted context omitted.

I gather from the HN discussion that it's not simple to disable scripting in an SVG, in retrospect a tragically missing feature. I guess the next step is to propose a simple "noscripting" attribute, which if present in the root of the SVG doc inhibits all scripting by conforming renderers. Then the renderer layer at runtime could also take a noscripting option, so the rendering context could force it if appropriate.…

Disabling script execution in svgs is very easy, it's just also easy to not realize you're about to embed an svg. ` ` will not execute scripts, a bit like your "noscripting" attribute except it's already around and works. Content Security Policy will prevent execution as well, you should be setting one for image endpoints that blocks scripts. Sanitizing is hard to get right by comparison (svgs can reference other svg…

I had the impression from elsewhere in this thread that loading the svg in some other way, then you are not protected. This makes a no-brainer "don't run these ever" option in the browser seem appealing.

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#302

Post by wiether »

sammy2255 wrote: post #119
wiether wrote: post #114

Earlier quoted context omitted.

That's a bit simplistic. If you sign a contract with a "hacker", then you are expecting results. Otherwise how do you decide to renew the contract next year? How do you decide to raise it next year? What if, during this contract, a vulnerability that this individual didn't found is exploited? You get rid of them? So you're putting pressure on a person who is a researcher, not a producer. Which is wrong. And also ther…

They've already proved themselves as competent. $50k a year to a billion dollar company is nothing. Even if they find 0 vulnerabilities a year it's still worth it to them

So now they found a vulnerability, the company should pay them $50k a year until they retire because they proved themselves competent?

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#304

Post by wiether »

tptacek wrote: post #205
wiether wrote: post #114

Earlier quoted context omitted.

That's a bit simplistic. If you sign a contract with a "hacker", then you are expecting results. Otherwise how do you decide to renew the contract next year? How do you decide to raise it next year? What if, during this contract, a vulnerability that this individual didn't found is exploited? You get rid of them? So you're putting pressure on a person who is a researcher, not a producer. Which is wrong. And also ther…

Just going to say here that people routinely engage pentest firms, several times annually, for roughly that sum of money, hoping but not expecting game-over vulnerabilities (and, from bitter experience as a buyer rather than a seller of those services over the last 5 years --- "no game-over vulnerabilities" is a very common outcome!)

I completely agree!

But hiring a pentest firm is completely different than giving $50k a year to a guy, no questions asked.

The pentest firm is generally providing the whole package, from doing the actual pentest, with tools and workers of various experience and skill sets, giving you extended reports on what they did and the outcome, to providing guidance on how to fix their findings, how to make the necessary cultural changes to harden your apps, and also how to communicate that you have passed their audit.

You won't have all of that if you give free roam to a guy to _do what they do_.

This idea is more similar to patronage, which, imho, is a great idea, no matter the domain (arts or tech), but I doubt that there any company here that is willing to go this way.

Even the company that supposedly do actual patronage today are going to look at their ROI and stop as soon as they don't see the figures they're expecting.

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#305

Post by auxiliarymoose »

rcxdude wrote: post #161
poorman wrote: post #20

Earlier quoted context omitted.

All SVGs should be properly sanitized going into a backend and out of it and when rendered on a page. Do you allow SVGs to be uploaded anywhere on your site? This is a PSA that you're probably at risk unless you can find the few hundred lines of code doing the sanitization. Note to Ruby on Rails developers, your active storage uploaded SVGs are not sanitized by default.

Sanitisation is a tricky process, it can be real easy for something to slip through the cracks.

Yes. Much better to handle all untrusted data safely rather than try to transform untrusted data into trusted data.

I found this page a helpful summary of ways to prevent SVG XSS: https://digi.ninja/blog/svg_xss.php

Notably, the sanitization option is risky because one sanitizer's definition of "safe" might not actually be "safe" for all clients and usages.

Plus as soon as you start sanitizing data entered by users, you risk accidentally sanitizing out legitimate customer data (Say you are making a DropBox-like fileshare and a customer's workflow relies on embedding scripts in an SVG file to e.g. make interactive self-contained graphics. Maybe not a great idea, but that is for the customer to decide, and a sanitization script would lose user data. Consider for example that GitHub does not sanitize JavaScript out of HTML files in git repositories.)

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#306

Post by auxiliarymoose »

socalgal2 wrote: post #297
dllu wrote: post #5

The fact that SVG files can contain scripts was a bit of a mistake. On one hand, the animations and entire interactive demos and even games in a single SVG are cool. But on the other hand, it opens up a serious can of worms of security vulnerabilities. As a result, SVG files are often banned from various image upload tools, they do not unfurl previews, and so on. If you upload an SVG to discord, it just shows the raw…

IIUC, an untrusted inline SVG is bad. An image tag pointing to an SVG is not. I feel like this is common knowledge. Just like you don't inject untrusted HTML into your page. Untrusted HTML also has scripts. You either sanitize it. OR you just don't allow it in the first place. SVG is, at this point, effectively more HTML tags.

Also remember that if the untrusted SVG file is served from the same origin and is missing a `Content-Disposition: attachment` header (or a CSP that disables scripts), an attacker could upload a malicious SVG and send the SVG URL to an unsuspecting user with pretty bad consequences.

That SVG can then do things like history.replaceState() and include with HTML to change the URL shown to the user away from the SVG source and show any web UI it would like.

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#308

Post by auxiliarymoose »

Wowfunhappy wrote: post #218
lenzm wrote: post #148

Earlier quoted context omitted.

They are like PDFs in that they do not render the same with different software or on different devices.

I would say PDFs are actually reasonably consistent though. Weird things happen on occasion, but I've certainly had more success than with SVGs.

They are reasonably consistent because there is a de-facto reference implementation (Adobe Acrobat) which, if your implementation does not match exactly, users will think your implementation is broken.

There isn't such an implementation for SVG.

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#309

Post by OrangeMusic »

michaelt wrote: post #73
llmslave2 wrote: post #63

Earlier quoted context omitted.

You're right that it's a specific programming culture that is especially vulnerable to it. And for the same reasons they were vulnerable to the same thing to a lesser degree before the rise of LLMs. But like, this case isn't really a dependency or supply chain attack. It's just allowing remote code execution because, idk, the dev who implemented it didn't read the manual and see that MDX can execute arbitrary code or…

One might consider this a supply chain attack because the title of the post is “We pwned X, Vercel, Cursor, and Discord through a supply-chain attack”

Sometimes titles are inaccurate

Re: We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

#310

Post by prmoustache »

ex-aws-dude wrote: post #202
prmoustache wrote: post #137

Earlier quoted context omitted.

Open it with a browser running inside a jail.

I tried that and they wouldn't let me bring my laptop in

https://man.freebsd.org/cgi/man.cgi?jail https://github.com/Zouuup/landrun
Post reply on HN