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.

> Necessary qualifier: for browser-based user sessions.

> Plenty of good uses for JWTs for service-to-service communication.

This is the sensible conclusion right there. I agree JWTs are the wrong tool for the use case of user sessions in the browser.

To give some more arguments:

All the signature and encryption stuff in JWTs is complex. While common JWT libraries have now mostly got their stuff together, this has not always been the case. There were plenty of libraries accepting the "none" algorithm [1] or allowing attackers to forge tokens by using a public key as a shared secret [2]. This is the direct result of the complexity criticized in the linked blog post.

JWTs also cannot do some stuff you want for user sessions. You can't invalidate them without keeping a revocation list somewhere. But if you have to check an identifier for revocation on every request you could just use an opaque session ID and look that up on every request instead! Sure, you can use short-lived tokens and refresh them all the time, but why bother with that for a typical application that has to keep some state anyway?

All that being said, I wholeheartedly agree that there are use cases in distributed systems and machine-to-machine communication where signed tokens can be useful. Just please don't confuse the two cases.

[1] https://nvd.nist.gov/vuln/detail/cve-2022-23540

[2] https://nvd.nist.gov/vuln/detail/CVE-2024-54150 (just a random example from googling, I don't know what library made this one infamous)

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.

Yes, you're definitely right that there are edge cases and I was simplifying a bit. Notably, it's called SameSite, NOT SameOrigin. Depending on your application that might matter a lot.

In practice, SameSite=Lax is already very effective in preventing _most_ CSRF attacks. However, I 100% agree with you that adding a second defense mechanism (such as the Sec header, a custom "Protect-Me-From-Csrf: true" header, or if you have a really sensitive use case, cryptographically secure CSRF tokens) is a very good idea.

I work as a pentester. CSRF is not a problem of the user proving their identity, but instead a problem of the browser as a confused deputy. CSRF makes it so the browser proves the identity of the user to the application server without the user's consent.

You do need a rigid authentication and authorization scheme just as you described. However, this is completely orthogonal to CSRF issues. Some authentication schemes (such as bearer tokens in the authorization header) are not susceptible to CSRF, some are (such as cookies). The reason for that is just how they are implemented in browsers.

I don't mean to be rude, but I urge you to follow the recommendation of the other commenters and read up on what CSRF is and why it is not the same issue as authentication in general.

Clearly knowledgeable people not knowing about the intricacies of (web) security is actually an issue that comes up a lot in my pentesting when I try to explain issues to customers or their developers. While they often know a lot about programming or technology, they frequently don't know enough about (web) security to conceptualize the attack vector, even after we explain it. Web security is a little special because of lots of little details in browser behavior. You truly need to engage your suspension of disbelief sometimes and just accept how things are to navigate that space. And on top of that, things tend to change a lot over the years.

The SameSite cookie flag is effective against CSRF when you put it on your session cookie, it's one of its main use cases. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/... for more information.

SameSite=Lax (default for legacy sites in Chrome) will protect you against POST-based CSRF.

SameSite=Strict will also protect against GET-based CSRF (which shouldn't really exist as GET is not a safe method that should be allowed to trigger state changes, but in practice some applications do it). It does, however, also make it so users clicking a link to your page might not be logged in once they arrive unless you implement other measures.

In practice, SameSite=Lax is appropriate and just works for most sites. A notable exception are POST-based SAML SSO flows, which might require a SameSite=None cookie just for the login flow.

I don't believe this is true, as https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... exists. It does need an extension to be installed, but I think that's fair in your comparison with NPAPI.

Direct link to the comment with the new information (apparently it is not possible to keep the URL fragment): https://github.com/microsoft/vsmarketplace/issues/1168#issue...

The gist of it:

> The publisher account for Material Theme and Material Theme Icons (Equinusocio) was mistakenly flagged and has now been restored.

Previous discussion here, which is also the reason why I think this resolution is relevant as well: https://news.ycombinator.com/item?id=43178831

The article doesn't mention possible security implications. However, we already get lots of vulnerabilities exactly _because_ implementations disagree on delimiters. Examples for this are HTTP request smuggling[1, 2, 3] and SMTP smuggling[4].

As the references show, this is already a big source of vulnerabilities - trying to push for a change in standards would likely make the situation much worse. At the very least, old unmaintained servers will not change their behavior.

I think we should accept that this ship has sailed and leave existing protocols alone. Mandate LF and disallow CRLF in new protocols, that's fine, but I don't think we should open this particular Pandora's Box.

[1] Simple example that doesn't use CRLF/LF disagreement: https://portswigger.net/web-security/request-smuggling

[2] Complex example that uses CRLF/LF disagreement: https://portswigger.net/web-security/request-smuggling/advan... (see heading 'Request smuggling via CRLF injection')

[3] Random report on HackerOne I found where allowing LF created a vulnerability in NodeJS: https://hackerone.com/reports/2001873

[4] https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-...

`git push -u origin HEAD` pushes the current branch to `origin` with the same name you have locally. You could even add an alias for that.

And another party trick: Base64-encoded JSON objects always start with "ey".

Are there any resources you can recommend to understand D-wave's quantum computing a bit better?

I took a very basic course about gate-model quantum computing at my university. The (mathematics) professor would have loved to be able to explain adiabatic quantum computing on a basic level, but was unable to find entry-level material to really understand how it works or what problems it can solve.

For the Fibonacci example the author claims:

> Notice how state was introduced? It made the code easier to read.

Correct me if I'm wrong, but the only state in that snippet lives in Stream.iterate(), the Fibonacci object is still immutable and next() on it is a pure function. To me this still looks very much like a functional programming approach.

Which just shows that moving business logic into properly named abstractions is good, no matter the programming paradigm.

The real stateful example is the IncrementSupplier and the impure get() method. I personally don't really like it ( Stream.iterate(0, i -> i + 1) is pretty readable to me), but that's probably just personal taste.

Thanks! Just defining it as a config variable is far too obvious in hindsight, I don't know why it didn't cross my mind.

I'll definitely try it out!

Is there a way to manage different "categories" of systems with chezmoi? For example, a "linux-server" category would contain an essential set of dotfiles, but not all the window manager related stuff from my linux laptop. Looking at the documentation, the only way to do this would be hostname-based templating, but that seems cumbersome as you would have to change every single template to add the new hostname to the section in question.

The Bundesnetzagentur does not have the capacity to ban random devices for children.

They banned these devices because they are essentially bugs/covert listening devices and are even marketed as such. Devices that look innocious (such as children's watches or teddy bears) but in reality are covert listening devices are banned in Germany by §90 TKG. [1]

This is why the Bundesnetzagentur banned the smartwatches in question. They even cited cases in which these watches were used to monitor teachers in classrooms. [2]

"Normal" smartwatches are NOT banned. "Normal" smartwatches for children are also NOT banned. Only watches with monitoring functions fall under the §90 TKG law. [3] Note that using an app to bring covert listening functionality to a phone or watch also converts that device into an illegal listening device.

[1] https://www.gesetze-im-internet.de/tkg_2004/__90.html (Just for reference)

[2] https://www.bundesnetzagentur.de/SharedDocs/Pressemitteilung... (German, but google translate works sufficiently well)

[3] https://www.bundesnetzagentur.de/DE/Sachgebiete/Telekommunik... (German, use a translator)