[HN Gopher] Apple fixes zero-day bug in Apple Vision Pro that 'm...
___________________________________________________________________
Apple fixes zero-day bug in Apple Vision Pro that 'may have been
exploited'
Author : arkadiyt
Score : 84 points
Date : 2024-02-04 17:32 UTC (5 hours ago)
(HTM) web link (techcrunch.com)
(TXT) w3m dump (techcrunch.com)
| judge2020 wrote:
| Possibly related -
| https://x.com/0xjprx/status/1753575170101461266?s=20
|
| > 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=...
| charcircuit wrote:
| That only shows a kernel panic. An exploit would prevent the
| kernel from crashing.
| swozey wrote:
| How can malware prevent a panic? Its process is priority over
| pid1? I'm very ignorant to this stuff. Wouldn't the kernel
| know it's being manipulated, like a startup/JIT checksum or
| something?
| mort96 wrote:
| A kernel panic is caused by some serious issue in either
| the kernel or the hardware. In itself, it's relatively
| "harmless": it just means the OS stops doing anything and
| you need to hard reboot the machine (such as by cutting
| power).
|
| 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.
| swozey wrote:
| Thanks! Yeah I really need to work on my low level
| security knowledge this stuff is fascinating when it
| isn't presented in the form of a crypto algorithim that
| is heirogylphics to me.
| PeterisP wrote:
| The general idea is that an exploitable remote code
| execution bug is some specific circumstances where the
| processor starts to execute whatever is in some wrong
| address which can be manipulated by an attacker.
|
| 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.
| qingcharles wrote:
| RealityDevice running on xrOS.
| bpye wrote:
| I'm kind of impressed that a kernel panic doesn't just result
| in a black screen and that passthrough still works.
| teaearlgraycold wrote:
| I'm not super informed here, but I believe the AR stuff,
| including eye tracking, takes place on a coprocessor. The OS
| on the M2 chip could die and you'd still have passthrough.
| hparadiz wrote:
| Valve Index is similiar. I've had my whole desktop freeze
| but the spatial orientation is still drawing within the VR
| as the headset is moving albiet in a frozen state.
| charcircuit wrote:
| The Valve Index does not do reprojection on the device.
| It does not even do tracking on the device.
| FirmwareBurner wrote:
| It does it on the PC?
| jsjohnst wrote:
| Yep, R1 chip.
| orangepanda wrote:
| Sure it helps but does it _have_ to be on a separate chip?
| In ye olden days when everything else had crashed and was
| frozen, skype calls still kept working
| michaelt wrote:
| Historically, it's generally been cheaper and easier to
| have two chips than to persuade a consumer or server OS
| to provide reliable time guarantees.
| charcircuit wrote:
| Hypervisors like that already exist and are needed by
| cloud providers.
| bpye wrote:
| Well, even in that context you have AWS for example doing
| control plane operations on a different SoC -
| https://docs.aws.amazon.com/whitepapers/latest/security-
| desi...
| threeseed wrote:
| I think it's more the fact that the M2 chip is used
| across multiple product lines that don't need the unique
| capabilities of the R1 chip.
| ibero wrote:
| The current theory in the community is that since visionOS is
| based on iPadOS that it's more of a reference to a possible known
| exploitation on iPad that requires similar attestation on
| visionOS.
| fouc wrote:
| Imagine walking or driving when your AR gets hijacked, you could
| be at risk of walking into traffic or crashing the vehicle.
| GenerocUsername wrote:
| If only there was a way to prevent this
| randallsquared wrote:
| Avoiding any walking or driving? Sure, I guess, but most
| people can't stay at home forever any more than they could
| avoid using a phone.
| bpye wrote:
| You can still walk or drive - just take the headset off to
| do it...
| pinkmuffinere wrote:
| How are you supposed to know when the headset is going to
| fail though??? I guess in some failure modes you might
| anticipate it failing, but surely not all... (/s)
| Detrytus wrote:
| But walking with your headset on can be a part of the
| value proposition, by adding some metadata to what you
| see. Imagine being shown directions in an unfamiliar
| place. Or seeing a distant bus and being told that this
| is the bus you're trying to catch. Once the technology
| becomes popular people will find a lot of reasons to walk
| with their headsets on.
| dimask wrote:
| maybe with less intrusive and lighter optical AR glasses
| that do not cover all your field of view, walking around
| the city would be more possible. But expecting to go
| around the streets or even drive with a huge AR headset
| is unreasonable for our times.
| ayhanfuat wrote:
| Imagine not wearing a distracting device while you are in
| traffic.
| hparadiz wrote:
| I could see a driving mode being useful since you could do
| things with nothing but your eyes leaving your hands free.
| Svennisen wrote:
| Because you don't need your eyes when driving? The thought
| of people driving around and multi tasking with their AR
| goggles gives me the heebie-jeebies.
| hparadiz wrote:
| As opposed to looking at a map?
|
| It's always something with you folks.
| kramerger wrote:
| That should be illegal. It removes a huge part of your
| field of vision.
| wongarsu wrote:
| We already have countless studies that talking on your
| phone while driving is really bad for reaction times and
| accident rates, even in hands-free setups. I can only
| imagine who much worse these numbers will look if you add
| distractions for your eyes to the mix.
| nullindividual wrote:
| Like this?
|
| https://www.youtube.com/shorts/TlkzcIel_pY
| mtlmtlmtlmtl wrote:
| This person should lose their licence.
| seagulls wrote:
| That will definitely prevent them from driving.
| mtlmtlmtlmtl wrote:
| In this case, I think the stupidity is also sufficient to
| confiscate the vehicle in some jurisdictions.
| bsimpson wrote:
| I'm surprised they shipped with the product name
| RealityDevice14,1.
| quenix wrote:
| The code name is always displayed in panic and crash logs. For
| example, a kernel panic on my MacBook would display
| MacBookAir10,1.
|
| Or do you mean you find the code name itself funny?
| LeoPanthera wrote:
| (Jan 31) - before launch day.
___________________________________________________________________
(page generated 2024-02-04 23:01 UTC)