RagingCactus

First of all, thank you for carefully making your point and not conflating your criticism on the communication with questioning the seriousness of the technical issue.

I personally also found the level of marketing noise on some of the websites distasteful for an extremely serious vulnerability of this caliber. I agree that probably didn't help with credibility for readers without any security knowledge.

That being said, the writeups and demos published on these sites made it very clear to anyone with basic knowledge about how things like UAFs get exploited (and I mean basic, I couldn't write a working exploit for something like this myself!) that this is a very serious issue. The presented facts lined up with the claimed impact, unlike the many hallucinated slop repos that appeared before the public disclosure. My issue is that for some reason non-security people often don't believe the security people in cases like these, and I don't quite understand why that is such a consistent issue. And besides, as you already mentioned, it wasn't just OpenAI, Wiz, Calif saying that this was bad, the PHP people said the same. They certainly had no interest in blowing this out of proportion.

I also personally think the concerns about 15 minute exploits were genuine and warranted. Maybe the chance for that wasn't overwhelming, but I believe it was there. The bigger issue, however, comes from the ability of adapting an exploit to other builds once one exists. Another comment on this post asserts this vulnerability "will never be a one-size-fits-all-PWN-button". And historically this has been somewhat true for binary exploitation (depending on your threat model). But the problem is, even if public LLMs can't quite consistently one-shot a full pwn exploit in 15 minutes, they absolutely can very easily adapt an existing exploit to other target versions and builds.

Thank you for consistently being a source of reason in these types of posts. I come here often to look how the wider software community feels about security, and to see if people understand how dire the entire software security situation is.

And I'm usually unpleasantly surprised, but I can deal with it, I know most developers don't have the knowledge to deeply understand if something is really really bad or just a small problem. But now I'm finally at a point where I wonder if people will ever understand. We have critical vulnerabilities in widely used software coming out every other day, we get exploits for (on a technical level) very hard to exploit vulnerabilities in record speed, and yet non-security people still spout "full weaponized PoC or it isn't real" like it's 1999 (not that I was old enough to know that was happening at the time).

I don't understand why nobody believes that security people might know a thing or two. Is it just that it's so much more convenient to close your eyes and pretend that nothing is wrong? I wonder what needs to happen to allow us all to finally have a conversation about how we can make sure that the software that runs all aspects of our life gets more secure.

While I dislike the feature getting removed, this argument does not hold up to scrutiny. They will remove using external SMTP servers to send emails from external, third-party addresses. Sending as another Gmail or Google Workspace address will continue to work, but that path is fully Google-internal.

Emphasis mine:

> You can continue to use "Send as" for any -->Google-hosted identities<--, including other Gmail addresses or aliases associated with your Google Workspace account. The discontinuation will not impact these addresses, which only applies to third-party, non-Google email accounts.*

You can do that, but my understanding is you can't get the browser to attach cookies to your request in this way, while you can with forms. Do you agree?

This is fundamentally a CSRF issue and framing CSRF as an access control issue often yields to wrong conclusions. With CSRF you might face the situation that the request has a valid session cookie, but is actually created by an attacker coercing the victim's browser into sending a request unbeknownst to the victim.

This case gets more and more complicated with browser defenses such as SameSite cookies or fetch headers you can use to mitigate this case, but let's ignore that for now.

To drive my point home, similar to how ensuring the content-type is set correctly on your JSON endpoint prevents CSRF, it's actually also a very real defense to require a custom header to be set, e.g.

  I-Promise-To-Not-Be-Malicious: true

Requiring this header will prevent CSRF because browsers won't allow you to set that cross-origin (unless of course you allow anyone to set it via CORS)

You can massage a text/plain form into valid JSON. text/plain is also one of the allowed default types. It works if the server doesn't check the content-type.

Source: I've done that successfully in multiple pentests.

Edit: lazy LLM generated example:

  <form action="https://example.com/api" method="POST" enctype="text/plain">
    <input name='{"key":"value", "ignore":"' value='"}'>
  </form>

That gives you

  {"key":"value", "ignore":"="}

The trick is to stuff the = character you cannot control into an irrelevant value.

> Some libraries being buggy never was an argument against using libraries. And do you expect your single-purpose code not to be?

Of course you should use battle-tested and well-maintained libraries for the really hard stuff such as cryptography primitives. However, that is not the point I was trying to make.

My points here are:

1) If you can get away with not using cryptography for something, you probably should. Your web framework already supports session cookies. Even if it doesn't, it's very hard to mess up opaque tokens from SecureRandom or /dev/urandom and a corresponding database lookup.

2) If you actually need the things JWTs can do, the standard is still needlessly complex and easy to mess up in ways that are not inherent to the problems JWTs are trying to solve. I'm not saying this means you should roll your own solution (again, I agree that there is value in well-tested libraries), I'm further strengthening point 1) with this. Don't use JWTs if you don't need to

> Also, WTF is wrong with people who accepted algorithm "none."

They dared to use the default validation function of their JWT library. They did not choose to accept "none".

And the library authors implemented it because it's in the spec. It doesn't excuse that the default was to accept "none", but it is an explanation and in my opinion a valid critique of the standard.

> First, we need to add a token_secret column to our users table:

> ALTER TABLE users ADD COLUMN token_secret;

So it's "stateless" but we have to query the users database on every request? How is that more stateless than SELECT * FROM session WHERE id = cookie?

Ignoring that and taking the mechanism as given: Why the obsession with cryptography, in this case HMAC? I don't see any reason why another signature is needed here when I believe the same outcome could be accomplished with a token_epoch field in both the signed JWT and the users table. Just increment the epoch to revome old tokens. Or even better, drop the epoch field and have an iat_not_before field per user. The field in the JWT is signed, the whole point is that you can trust it.

Do let me know if I miss anything here please. Assuming I haven't: it's always puzzling to me to see people being so eager to sprinkle more cryptography on anything that is supposed to be secure. For me, I've become more afraid of cryptography the more I learned about it. Cryptography is hard. It's not a magic ingredient for security. At best, it's dangerous black magic -- very potent, but pronounce a single syllable of your magic spell wrong and it _will_ blow up in your face.

As a security person it is tiring to see so many people here either directly claim or at least allude to the claim that this is somehow much less scary because the _published_ exploit does not bypass ASLR. The writeup claims there is a way to reliably bypass ASLR with this attack. And that is a good default assumption I would be willing to believe without evidence.

ASLR is a defense-in-depth technique intended to make exploitation more difficult. In almost all cases it is only a matter of time and skill to also include an ASLR bypass. Both requirements continue being lowered by LLM agents every few weeks. It is only a matter of time (and probably not a lot of time) until a fully weaponized exploit is developed. It may be published, it may also be kept private.

It is straight up wrong to say "if you have ASLR enabled, you're not at any risk from this" and saying this is extremely harmful for anyone that trusts claims like that.

This wrong belief that you shouldn't care about security vulnerabilities because mitigations may make exploitation more difficult has already caused so much harm in the past. Be glad that modern mitigations exist, but patch your stuff asap. If you are a vendor, do not treat vulnerability reports as invalid because the researcher has not provided an ASLR bypass. Fix the root cause and hope mitigations buy you enough time to patch before you get owned.

Seeing the confusion in the comments I want to provide some examples of situations where this might come up in a security or CTF context:

* You have a restricted shell or other way to execute a restricted set of commands or binaries, often with arbitrary parameters. You can use GTFOBins in interesting ways to read files, write files, or even execute commands and ultimately break out of your restricted context into a shell.

* Someone allowed sudo access or set the SUID bit on a GTFOBin. Using these tricks, you may be able to read or write sensitive files or execute privileged commands in a way the person configuring sudo did not know about.

Lots of people here are (perhaps rightfully) pointing to the unwrap() call being an issue. That might be true, but to me the fact that a reasonably "clean" panic at a defined line of code was not quickly picked up in any error monitoring system sounds just as important to investigate.

Assuming something similar to Sentry would be in use, it should clearly pick up the many process crashes that start occurring right as the downtime starts. And the well defined clean crashes should in theory also stand out against all the random errors that start occuring all over the system as it begins to go down, precisely because it's always failing at the exact same point.