MajesticHobo2

It's not. Or if it is, it's unclear. The article seems more focused on the integrity of remote development servers and deployment targets:

> Unlike Tramp, which lives off the land on the remote connection, VSCode mounts a full-scale invasion: it runs a Bash snippet stager that downloads an agent, including a binary installation of Node.

> I would be a little nervous about letting people VSCode-remote-edit stuff on dev servers, and apoplectic if that happened during an incident on something in production.

Is it? I've read the article twice (yesterday when you posted it and last year when it was first published), and that was not my interpretation.

This part of VSCode's architecture is acceptable to me. The reverse direction, where a compromised remote can do whatever it wants to my local machine, is not.

That is a linear growth problem whose answer is very easy to intuit.

You also don't want adversaries to be able to disrupt long-lived streams with bad password guesses, since I think part of Wormhole's security model is it will terminate the session if the other side gets it wrong.

They say it's rate-limited, so at least it probably won't scale to large botnets or similar...

notabug wontfix; that's the end-to-end principle in action. Bring your own all of that.

Browser sandboxing is now fully solved.

It's the same style I see on Twitter and LinkedIn a lot.

Why does it have to be deliberate? It's not surprising that people exposed to output from LLMs will unconsciously pick up their linguistic habits.

I'd say also add a test that shows the HTML injection (which spurred the PR) isn't possible. Given an attacker-controlled URL of:

    foo onclick

the following shouldn't render:

    <a class="item muted sidebar-item-link" href=foo onclick>

The following should:

    <a class="item muted sidebar-item-link" href="foo onclick">

It was definitely partially about model quality. The frontier models are capable of producing valid findings with (reasonably) complex exploit chains on the first pass (or with limited nudging) and are much less prone to making up the kinds of nonsensical reports that were submitted to curl. Compared to now, the old models essentially didn't work for security.

If those script kiddies had been using today's models instead and _still_ didn't do any filtering, a lot more of those bugs would have been true positives.

> With decompilation I think there's a higher risk of it missing the intention of the code.

I'm not sure but suspect the lack of comments and documentation might be an advantage to LLMs for this use case. For security/reverse engineering work, the code's actual behavior matters a lot more than the developer's intention.

That was then, this is now. The new models are scarily good. If you're skeptical, just take an hour to replicate the strategy the article references. Point Claude at any open-source codebase you find interesting and instruct it to find exploitable vulnerabilities. Give it a well-defined endpoint if you want (e.g., "You must develop a Python script that triggers memory corruption via a crafted request") and see how well it does.

Third or fourth, maybe, not first.

Yes, but it would likely have to be chained with other bugs - at minimum, something that gives you an info leak.

Yeah, somebody came up with one here: https://news.ycombinator.com/item?id=46469897

It’s a phase 1 clinical trial designed only to assess safety and determine the appropriate dosage. Future trials will focus on efficacy.

Wouldn't platforms see the supposed XSS payloads in their logs and publish analyses of them, or at the very least, announce that they happened?

I'm sure they can store far more than 20 TB now, but it is true that the content pool is much larger. I would guess it's not a favorable ratio.

Thanks for making this! I've been looking for something like this for a while.

  xxd IMGP0847.DNG | grep 03e400:
  0003e400: ffd8 ffc3 000e 0e10 800c 5002 0011 0001  ..........P.....

Look at the byte at offset 11 (0xb), it's there.

Yes:

  dd status=none if=IMGP0847.DNG bs=1 skip=0x3e40b count=1 | xxd
  00000000: 02

You need to click the link that says "RAW (33.0MB)". The filename should be "IMGP0847.DNG".

I AirDropped the PoC to my vulnerable iPhone. It didn't cause a crash until I tried to edit it in the Photos app.

That's exactly why I don't agree that GETs should be broadly exempted from CSRF protections. I'm not talking about CORS at all.

The problem boils down to the lack of equivalence between a site and an origin. The article explains how https://app.example.com and https://marketing.example.com may sit at very different trust levels, but are considered the same site by the browser. You don't want https://marketing.example.com to be able to make requests to https://app.example.com with your authentication cookies, but SameSite wouldn't prevent that.

Not sure I agree with this part:

> Allow all GET, HEAD, or OPTIONS requests.

> These are safe methods, and are assumed not to change state at various layers of the stack already.

Plenty of apps violate this assumption and do allow GET requests to alter state.

XFF handling is the bug that keeps on giving. I'd estimate I've seen incorrect parsing of it in at least half of the web applications I've audited professionally.

The funniest is when the app renders user IP addresses somewhere and you can get XSS through it.

You can use FTP and SVN.