"An app may be able to execute arbitrary code with kernel privileges. The issue was addressed with improved memory handling. This issue is fixed in iOS 16.1 and iPadOS 16, macOS Ventura 13, watchOS 9.1."

https://revealjs.com/

https://www.cvedetails.com/top-50-vendors.php

It's the equivalent of a lot of make-up applied poorly.

It would be clearer to simply communicate concisely.

1. The message is secondary to the medium.

2. The communication requires numerous unnecessary click throughs to obtain the relevant information.

3. The division of the information into various panels and mediums does not enhance the communication, rather the messages are divided in a way that doesn't match a hierarchal introduction of detail. It often serves no purpose whatsoever.

Also this is not some personal attack on identity "who she wants to be", it's a commentary on poor communication - don't attempt to equate the two, it's incredibly poor taste, and flame baiting.

> The message is secondary to the medium.

What if the message was in a language that you don't understand? Would that make it poor communication, or is it rather poor listening.

The pressure to be average, normal, and conformist is what neurodiverse individuals struggle with daily - especially in professional and educational settings. "Poor communication skills" are very much a personal attack - at least from my perspective as an ND individual. This is Lina's personal time and she can communicate how she pleases.

Find where I infer anything about the author in my comment. It's not present, you've invented this narrative as a strawman argument.

You are presenting something inappropriate and frankly revolting for the furtherance of merely disagreeing.

Also just so we are clear: I'm not going to engage you in discussing a person's identity. Continually referring to the author's identity is deeply offensive.

yes it is. see:

> ... all of the gimmick and gloss in the presentation and accompanying youtube video is ...

I find that disgusting.

i am unfazed

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newsguidelines.html

The format is indeed relevant.

"Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

https://news.ycombinator.com/newsguidelines.html

Internet threads have a strong tendency to get stuck on annoyances that aren't pertinent to the actual topic. It's a bit like a branch getting snagged at the side of a creek: all sorts of detritus accumulates around the branch, clogging the flow. This isn't just about comments—it's at least as much about upvotes—such subthreads invariably attract a lot of those. (To disgress a bit: I think that's because upvotes are often driven by familiarity, and the annoyances we're talking about are quite familiar.)

On HN, we don't have any rule against going off topic per se, because sometimes offtopic tangents are fun and interesting—usually when they're unpredictable, i.e. when they're about something specific that doesn't get talked about much, or maybe has never been talked about.

But presentation errors, usability errors, and so on, are the opposite of this: they're predictable because they happen a lot and the patterns tend to repeat, and also because they're annoying and people tend to express annoyance in the same ways over and over. This becomes repetitive and repetition is the enemy of curiosity [1], so it actually follows from HN's Prime Directive [2] that we should try to avoid this.

The other thing to understand about that guideline is that it's not denying the correctness of your annoyance! Of course you're right that formatting, presentation, usability, design, etc., are important. The issue is that discussions tend to get clogged by comments about these things, precisely because they are annoying. I'm as annoyed by them as anyone and I think most of us are.

Our challenge as a community is to experience those annoyances and process them however we process them but not to complain about them in the comments—rather to stay on topic (or at least on something unpredictable), not because crappy websites or whatever deserve better, but because we as a community deserve better—interesting conversations about interesting things to read.

(I should add that when I say "crappy websites" I'm not talking about the OP - I didn't spend more than a couple seconds looking at it and didn't personally experience annoyance. I just mean we all have our own set of triggers and they work more or less the same way in everyone.)

[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...

[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

The content may be excellent. The packaging utterly frustrates accessing that, and flouts all standard conventions of design. The author took a risk. The author lost.

It’s the most unintuitive mechanism unless you’ve already internalized what deck structures should be.

It seems like it’s optimized for the presenter but it’s often used for after the fact sharing with everyone else who won’t know the order.

It really needs a linear mode, with the option to see presenter notes.

Space key

I’m not defending it, because I legitimately think their multidimensional view is horrible for post facto sharing, especially on mobile. But it does mean that you can quickly navigate between chunks of the deck if you need to backtrack as a presenter.

here: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-3294...

Is there a sanitized version anywhere?

In Safari and Chrome, it makes a lot more sense now. The interactive demo slide is impressive!

Update: Weirdly enough, after another refresh I now also see slides on Firefox.

It probably failed to load some piece of JS or CSS the first time around.

"Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead."

https://news.ycombinator.com/newsguidelines.html

That doesn't seem excessively authoritarian to me and I don't see how we could do it differently without giving up on the site's mandate, which is not an option.

I.e if you report after someone else or report after it’s already been identified internally , you’re not likely to get a payout unless you have novel details

Lower, easier to get payouts are arguably better than rare jackpot payouts you have to fight over...

It's several years salary for many people.

How many people do you think could pull this off? I certainly couldn't. Could you?

Perhaps not for people with this level of applied skills who live in the US. But salaries vary drastically around the world, and remote jobs are not feasible for everyone.

How do you know that?

A level only fit for products where [3]: "some confidence in correct operation is required, but the threats to security are not viewed as serious" which is one level lower than "demonstrating resistance to penetration attackers with a basic attack potential" [4]. Which is four full levels below "demonstrating resistance to penetration attackers with a moderate attack potential" [5].

Apple has never once, over multiple decades of failed attempts, demonstrated "resistance to penetration attackers with a moderate attack potential" for any product. It should be no surprise that the systems, processes, and people who lack the knowledge, ability, technology, and experience to make a system resistant to moderate attackers, despite nearly unlimited resources, have the security of their systems completely defeated by moderate attacks like small groups of skilled researchers. Apple positively, absolutely, 100%, certifies they can not. Though, it would be nice if their marketing were restricted to what their engineering can prove.

[1] https://support.apple.com/guide/certifications/macos-securit...

[2] https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/CE...

[3] https://www.commoncriteriaportal.org/files/ccfiles/CC2022PAR... Page 14

[4] https://www.commoncriteriaportal.org/files/ccfiles/CC2022PAR... Page 16

[5] https://www.commoncriteriaportal.org/files/ccfiles/CC2022PAR... Page 20

What we derive from companies only able to achieve EAL < 5 is that their systems are not designed, nor capable of protecting against moderate attackers. This has been borne out by decades of experience where the security properties of these systems have been routinely defeated by attackers with moderate or lower attack potential. The certification process is both effective and accurate at identifying that these consumer operating systems are inadequate against attackers of moderate ability as an upper bound.

We further know from decades of experience that any system that attempts EAL5 certification and then fails has structural deficiencies that make it practically impossible for any configuration to ever be certified without a total redesign. As far as I know, nobody has ever achieved that despite decades of attempts and billions of dollars spent attempting to retrofit inherently insecure designs such as Windows, Linux, or macOS.

So, what we know is that macOS, iOS, Linux, Windows, BSDs, etc. are structurally insecure against moderate attacks such as those employed by commercial hackers and organized crime, let alone state-level actors, and that it is hopeless for them to ever be improved to reach such a level. Anything less than EAL5 is inadequate for the modern threat landscape of established commercial hackers and state actors as experienced by consumers, businesses, and governments. Therefore, the systems currently deployed are universally unfit for their usage in these connected systems and we have the certifications and continuous examples to prove it.

No EAL>4 certification does not imply that something is insecure.

Judging something as "insecure" or "structurally insecure" is highly opinionated. Not everyone has the same tolerance of risk. For most users the common operating system is secure enough. Besides that security is not only depending on the kernel. Smartphone operating systems which are based on Linux practically provide more security through app isolation than most desktop-oriented Linux-based distributions.

Besides that a CC certification does not necessary certify the product as a whole which finally means you cannot even derive a state of security statement for the end user.

Example: Integrity OS has been certified on EAL6, yet the have provided a vulnerable telnet server: https://nvd.nist.gov/vuln/detail/CVE-2019-7715

Another example was the genugate firewall which has been certified on EAL4+ (including ALC_FLR.2, ALC_PAM.1, ASE_TSS.2, AVA_VAN.5), so in the end it was certified against attack with a high attack potential. Yet, the product was vulnerable to a simple authentication bypass of the management interface resulting in a CVSS score of 9.8: https://nvd.nist.gov/vuln/detail/CVE-2021-27215

I know, the standard is embarrassingly low by modern attack standards. It really should be much stricter these days, but even at these embarrassingly low levels the standard commercial vendors such as Apple can not achieve them.

No, my statement on structural insecurity is quite objective. I said they are structurally insecure against commercial hackers and organized crime. That is a statement relative to a threat model and can be objectively verified.

Our objective verification is that their security properties get routinely invalidated by such attackers thousands of times a year. You would be hard pressed to find a professional hacker who would say something like: “Oh no, they are using a Mac, my plans are foiled.”

Commercial hackers and organized crime are expected threat actors. If you are running a commercial enterprise, you will be attacked by commercial hackers these days. If your systems are useless against them, then your security is objectively inadequate for your use case. Using systems certified to be inadequate for your use case is just engineering malpractice.

Yes, a Common Criteria certification does not mean the entire product is certified in much the same way that a nail certification does not mean your airplane is certified. You need to certify the entire product for the entire product to be certified. That should be obvious.

I do not know why you bring up uncertified composed products having problems in uncertified components. Yes, those components suck, we already know that. That in no way supports using composed products consisting entirely of inadequate components.

You seem to be confused about how you should use a Common Criteria certification to evaluate a product. EAL5 does not mean you are guaranteed to be protected against moderate attackers. It just provides some reasonable confidence that might be the case. What it really tells you is that you should have minimal or no confidence in systems not certified (or even worse failed certification) to EAL5.

A AVA_VAN.5 component might be vulnerable to moderate attacks. But a component that failed certification to AVA_VAN.3 is certainly vulnerable to moderate attacks.

The genugate firewall is EAL4. I do not see how this bolsters your point. There is a reason why we use EAL instead of just reporting the AVA_VAN requirement.

I do not have any particular insights into their product or that vulnerability. It is certainly possible they were over certified.

Looking at the PoC, it seems to indicate a administrator login authentication bypass. In the genugate firewall TOE [2] it indicates that the administrator network is assumed to be isolated and trusted. If an administrator login page is only meant to be accessible from the administrator network then the CVE would be out of scope of their certification. Though the CVE indicates other logins that might be affected, so I can not speculate any further. Certainly could be over-certified. But again, certification does not mean confidently secure, it is non-certification which means confidently insecure.

[1] https://www.commoncriteriaportal.org/files/ccfiles/CEM2022R1...

[2] http://www.commoncriteriaportal.org/files/epfiles/0300b.pdf

OS development, security, shader programming, etc.

The code is clean and has plenty of comments explaining what is happening at each step.

Additionally, I thought it was only $1k? I remember the Asahi account on Mastodon saying it was a $1k bounty.

See: https://security.apple.com/bounty/categories/

Is there any evidence for this? I've seen a bunch of people say it on HN.

Finally, and my personal favorite: Asahi’s VTuber reveal was by “hacking” and hijacking one of Marcan’s streams. The introduction was literally replacing Hector.

> The fact that the comment you replied to is buried shows that it's probably too close to be true and makes people uncomfortable

"People think I'm an asshole, that means I must be right"

If you say something nonsensical or incorrect, people ignore you. But if they laugh or get irate, then you're probably on to something.

Anyway, it's an asahilina.net page, not a cve.mitre.org page. That domain is for the Virtual YouTuber Lina-chan, so I would not expect it to be the most friendly for developers.

As a VTuber follower, I do really like the style :D

https://news.ycombinator.com/newsguidelines.html.

> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.

Given that many are praising the formatting, I don't see how the rule applies.

I'd like to point out that the slides have source available and use the reveal js slides framework, but I'm not sure if this would be considered as breaking the rules?

Source for slides: https://github.com/asahilina/agx-exploit/tree/main/slides

- Use Metal shader code to get a page table

- Use Metal shader code to acquire read/write access to physical memory

- Use Metal shaders to access the kernel page table

- Deals with ASLR to find the kernel base address

- Obtains process user credentials data structure via the process data structure (from the kernel memory)

- Sets uid and gid to 0 (root) to the user credentials data structure, giving root privileges to the process

GPUs are a very interesting attack vector. Especially as more computation is being pushed to GPUs, and they’re not always well isolated.

That said, fingerprinting is not as big a risk as what I was thinking of, which is one process being able to peer into another’s on the GPU. There are various takes on isolation on the GPU but they tend to have strong caveats attached.

They were so preoccupied with whether they could, the never stopped to consider whether they should.

Lots of computation is moving to GPUs.

Press down to see the slides

[0] https://support.apple.com/en-md/HT213488

For example, this is the same person who’s working on Asahi Linux for ARM macs. This means that they probably know what their talking about and this is gonna be a good article.