Apple fixes zero-day bug in Apple Vision Pro that 'may have been exploited'
techcrunch.com
techcrunch.com
> The world's first(?) kernel exploit for Vision Pro- on launch day!
image 1: https://pbs.twimg.com/media/GFXzO5kXMAA-y7k?format=jpg&name=...
image 2: https://pbs.twimg.com/media/GFXzQOJWYAA41sV?format=jpg&name=...
No shiny AR or "spatial computing" distractions. Just visibility.
That would be incredibly useful, and cool.
Christ the people on the website are just another level.
The people driving today with the headset (even for the memes) are the insane ones. It does not have the FOV for you to be fully aware of the road (I've used one in-store). I've also heard that even 12ms is apparently still too much latency for a driver to react promptly to emergencies.
As another user of the road do I get a say in this as well besides Apple and the moron with their headset on?
This is one of the dumbest things that you could possibly do, a heads up display I can get behind assuming it is very much limited in how much information can be displayed but a device that utterly obscures your vision, removes your peripheral vision and replaces it with a screen that isn't necessarily pointing in the direction that your head is pointing in whilst driving a vehicle sounds like an excellent way to have a serious accident. I do hope it is a one sided one, this is Darwin award level stuff.
Your glass windshield doesn't need a source of power to stay transparent, but Vision Pro does.
I absolutely do not believe that the current iteration of the product should ever be used while operating a moving vehicle. You are right to call it dumb.
Software or hardware glitch. Or power glitch.
R1 runs an RTOS, though, passthrough continues to run even if the main processor (the M2) completely crashes. So it already seems to try to fail safe. I can't imagine that's by accident. Maybe it's not that they're going to use the Vision Pro in these situations, but that maybe they might use the R1 or a future generation of it for their self-driving cars.
running from the inevitable only makes you tired.
A bulk of this (really interesting!) information can be found on their HDK documentation, but that requires you to sign up with Steamworks.
Therefore the data path from camera to screen has to entirely happen without the kernels involvement.
> If I had to guess, it feels like it’s under 10ms.
too many miss the value in such a statement.
“feel.”
subjective, but also sublime.
it doesn’t need to meet a metric, it needs to match a vibe. the metric is an approximation, as backwards as it might seem.
However, if the kernel panic is caused by a software bug (rather than something like a broken RAM stick), then the bug which causes the kernel panic might also be exploitable by malicious code to do things like arbitrary kernel level code execution. For example, if the problem is that the kernel somehow allows the user to change a piece of memory which the kernel interprets as a function pointer, then the result of carelessly changing that piece of memory will cause the kernel to jump into some part of memory that's not valid code, causing a kernel panic; however, a very clever attacker may pick a jump address which causes the kernel to keep executing without crashing but doing something which the developer of the kernel didn't intend. Maybe the attacker can cause the kernel to jump to a location in memory which the attacker has control over, which would mean that the attacker can run arbitrary code in kernel mode.
This stuff is all very complicated and very interesting, I recommend reading up on it if it interests you.
And no, the kernel can't really check if it's being manipulated. A checksum at startup wouldn't do it since these sorts of exploits don't tend to involve changing the kernel bytes on disk, but rather tricking the kernel into doing something it's not supposed to. There are various mechanisms to try to make bugs unexploitable (such as address space layout randomisation), but fundamentally, you can't perfectly protect against potential bugs.
If the bug is successfully exploited, the attacker arranges so that everything is just so that device runs "as if normal" but executes whatever code attacker decided to be executed; but if the bug is triggered accidentally or without a working exploit, then it attempts to execute something random and that results in a kernel panic.
So the way how "malware prevents a kernel panic" is that it's a successful exploit if and only if it manages to ensure that valid (but attacker-controlled) code runs and actually works, and if it instead results in a kernel panic, well, that's not a working malware, unless all the attacker wanted was a denial of service exploit.
The analog here would be a if you looked at the "wrong" thing (image, or a "malicious" QR code!) with Vision Pro and it contained the 0-day and then you were hacked!
FYI - I don’t know what the rules are that they put into place and what I read was based on comments from some early demos that Apple was giving so it remains to be seen what you actually can and cannot do while wearing one. I’m sure that this will start to come out now that people are using these in the field.
I’d just hate for AR to become synonymous with head mounted displays instead of a more general definition.
It's always something with you folks.
It doesn't even make sense. What do you want blinking arrows on the ground to show the way instead of the much superior way of just looking at google maps now?
Or do you mean that you are nuts enough to get one in your skull?
Or do you mean you find the code name itself funny?
AudioAccessory1,1 – First gen HomePod
AudioAccessory5,1 - HomePod mini
AudioAccessory6,1 - Second gen HomePod