kdbg

The fact journalists were compromised seems only incidental, the ruling is about weather or not NGO Group "exceeded authorization" on WhatsApp by sending the Pegasus installation vector through WhatsApp to the victims and not weather they were unauthorized in accessing the victims. Its a bit of a subtle nuance but I think its important.

Quoting the judgement itself:

> The court reasoned that, because all Whatsapp users are authorized to send messages, defendants did not act without authorization by sending their messages, even though the messages contained spyware. Instead, the court held that the complaint’s allegations supported only an "exceeds authorization" theory.

> The nub of the fight here is semantic. Essentially, the issue is whether sending the Pegasus installation vector actually did exceed authorized access. Defendants argue that it passed through the Whatsapp servers just like any other message would, and that any information that was 'obtained' was obtained from the target users' devices (i.e., their cell phones), rather than from the Whatapp servers themselves

> [...removing more detailed defendant argument...]

> For their part, plaintiffs point to section (a)(2) itself, which imposes liability on whoever "accesses a computer" in excess of authorized access, and "thereby obtains information from any protected computer" pointing to the word "any"

> [...]

> As the parties clarified at the hearing, while the WIS does obtain information directly from the target users’ devices, it also obtains information about the target users' device via Whatsapp servers.

Adding a little more detail that comes from the prior dockets and isn't in the judgement directly but basically NSO Group scripted up a fake Whatsapp client that could send messages that the original application wouldn't be able to send. They use this fake client to send some messages that the original application wouldn't be able to send which provide information about the target users' device. In that the fake client is doing something the real client cannot do (and fake clients are prohibited by the terms) they exceeded authorization.

Think about that for a moment and what that can mean. I doubt I'm the only person here who has ever made an alternative client for something before. Whatapp (that I recall) does not claim that the fake client abused any vulnerabilities to get information just that it was a fake client and that was sufficient. Though I should note that there were some redacted parts in this area that could be relevant.

I dunno, I mean the CFAA is a pretty vague law that has had these very broad applications in the past so I'm not actually surprised I was just kinda hopeful to see that rolled back a bit after the Van Bruen case a few years ago and the supreme court had some minor push back against the broad interpretations that allowed ToS violations to become CFAA violations.

Standard way being trying to measure the precise differences between requests. The smaller the difference the more requests are needed to level things out and that just becomes pretty impractical quickly but still possible in some situations.

If you actually wanted to do a timing attack on the web you'd probably want to do something like a "Timeless Timing Attack" [0]. At a high-level the idea is to measure relative timing differences rather than the precise difference. Answering which request completes faster rather than how much faster.

The specific attack from the paper is taking advantage of HTTP/2 multiplexing to send two requests within a single packet, ensuring they arrive at the same time. Then uses the response order to determine which was processed faster/slower. It still requires making multiple requests to smooth out the data just not as much since you're only interested in the relative competition time.

Its not practical everywhere, but its more practical for the web than the traditional technique.

Taking a look at x509.c[1] which I believe is the most likely to be able to reach the punnycode parser. (I am not at all familiar with the codebase). You can see that the OpenSSL fuzzer is basically doing a holistic fuzz (I assume the i2d* and d2i* functions exercise the parser), that is its just invoking key entrypoints that in theory can exercise all the rest of the functionality with the correct inputs.

Hanno's fuzzer on the other hand, is explicitly only testing the `ossl_punnycode_decode` function[3].

Given the breadth of the fuzzer, I think its very possible OSS-Fuzz just didn't hit it.