Bats Can No Longer Haunt Apple VR Headsets Via Web Exploit

Bug reporting doesn’t usually have a lot of visuals. Not so with the visionOS bug [Ryan Pickren] found, which fills a user’s area with screeching bats after visiting a malicious website. Even better, closing the browser doesn’t get rid of them! Better still? Doesn’t need to be bats, it could be spiders. Fun!

The bug has been fixed, but here’s how it worked: the Safari browser build for visionOS allowed a malicious website to fill the user’s 3D space with animated objects without interaction or permission. The code to trigger this is remarkably succinct, and is actually a new twist on an old feature: Apple AR Quick Look, an HTML-based feature for rendering 3D augmented reality content in Safari.

How about spiders, instead?

Leveraging this old feature is what lets an untrusted website launch an arbitrary number of animated 3D objects — complete with sound — into a user’s virtual space without any interaction from the user whatsoever. The icing on the cake is that Quick Look is a separate process, so closing Safari doesn’t get rid of the pests.

Providing immersive 3D via a web browser is a valuable way to deliver interactive content on both desktops and VR headsets; a good example is the fantastic virtual BBC Micro which uses WebXR. But on the Apple Vision Pro the user is always involved and there are privacy boundaries that corral such content. Things being launched into a user’s space in an interaction-free way is certainly not intended behavior.

The final interesting bit about this bug (or loophole) was that in a way, it defied easy classification and highlights a new sort of issue. While it seems obvious from a user experience and interface perspective that a random website spawning screeching crawlies into one’s personal space is not ideal, is this a denial-of-service issue? A privilege escalation that technically isn’t? It’s certainly unexpected behavior, but that doesn’t really capture the potential psychological impact such bugs can have. Perhaps the invasion of personal space and user boundaries will become a quantifiable aspect of bugs in these new platforms. What fun.

33 thoughts on “Bats Can No Longer Haunt Apple VR Headsets Via Web Exploit

      1. I’d say it’s the opposite – knowing humans will do whatever they can get away with, we created a society that could punish at least some of the worst excesses, thus incentivising people not to do that stuff.

    1. This is less “malicious” and more just an annoyance.
      It is on par with auto-playing embedded videos or how browsers first implemented push notifications.
      You might notice how chrome/firefox responded by adding “Allow/Ask/Deny” settings for all of those things.
      This is just apple/safari relearning the same lessons the big players had to learn long ago.

      1. Depending on the person. Feeding someone peanut butter might be annoying, or it might kill them.

        I don’t think it should have ever been allowed to spawn without user interaction. The addition of ‘unlimited’ objects, or more than one and with sounds is just completely insane. Who was asking for this ‘functionality’ in the first place. Icarus programming department at Apple.

      2. THIS implementation is less malicious. It is intended to shock people into awareness of a problem.

        The exploit could have been extremely malicious.

        The AR nature means there is some level of object/surface recognition.

        An exploit could have been crafted to suddenly startle users or use an oversized object to “blank” the screen just as a user takes a step down stairs.

        Objects could also be positioned and moved in a way to screw with people’s balance. And could be triggered to appear only while the user was walking.

        1. This trick is uploading fixed 3D objects, animations and sounds to the 3D space. They are then automatically rendered because they are found ‘there’.

          But having objects that interact with the real world, is something completely different.

          I agree with you in the general sense of what you are saying. But those things are not possible with this hack. You would need to be able to upload proper code.

          Now, I am not an expert in this matter, but asking for a friend: is it possible to associate some script to a 3D object and upload it to the user’s 3D space? ;)

          1. I thought the bats hung from the walls?

            If the 3d space is posted to the server by script, they can put the objects in trickier spots.

            Horrors peaking out from under the ottoman.
            Odorous’ cuttlefish lurking under the wainscoting.
            Giant lampreys or tarantulas in all the toilets.

            Only limited by how much fun the author wants to have.

            Who knows, if the hardware goes right and they integrate kinematic cameras, maybe someday: Your dead grandma climbing up your leg with a K-bar in her mouth. (Image stolen from HST.)

            It’ll be great!

      3. Define “less”. I have a pretty raging level of arachnophobia, and suddenly springing those spiders on me while in VR/AR has a pretty good chance of killing me on the spot. My heart stopped being shock rated decades ago.

      4. Many of such settings had permission prompts from day one. Not all or all browsers but it quickly got to the point where nearly any potential new feature, to even be discussion worthy, required a detailed plan for obtaining user permissions. Now almost anything requires some hueristic user interaction to even be able to prompt for permission.

        It’s been an endless loop since browsers could play sound and open pop up Windows.

        Browser vendors constantly push for true web apps – software only a URL away, like some fantastical utopian software future.

        Then they make it impossible or infeasible for developers to do almost any of the same things native apps do and generally without any permission pop ups. That keeps apps in their app stores, where they can profit off them and control them.

        Any native app could do all this, in fact much worse even without permission pop ups.

        The solution isn’t permission pop ups (fine grained permission controls are still good to have, of course) or reducing or isolating browsers further from everything else.

        For years, we’ve been teased with the dream of web apps actually being able to compete. Progress has definitely been made. But more than one proposal has been delayed or dropped due to implementation concerns such as permission acquisition UX, security concerns, etc.

        Vendors don’t want real web apps. PWAs are great, but always restricted compared to native apps. For example, notifications. Even with all permissions accepted, a PWA/web app can’t send notifications as fast, often or with the same detail (UI/UX concerns such as buttons and images) as native apps. In fact, in one instance I was testing I had to dig through several settings pages and menus to flip a toggle for the app under notification permissions for them to show on screen and not just in the drawer, even though permissions were accepted already.

        An app I’m developing could be 100% implemented as a PWA if stuff like this wasn’t the case, but instead Google/Apple would much prefer me to go native – even if the whole app is still a PWA with the native code only handling such things like notifications – because then they get their 30% cut.

        The solution is education. People seem to know better than to download random sketchy software more than they seem to know to not visit random sketchy sites.

        Want to protect people? We already have reputation based protection for apps now, why not web apps? Because – more PWA/web apps means less app store apps which means they can’t force their 30% cut via their monopolistic app stores. PC OS vendors only do it for customer security reputation (and more control) , they want users knowing their OS is secure. If it was truly for humanity/global security benefit, then they could easily do it for websites/web apps, just as easily as they could handle notifications as fast/rich as native apps.

        Kinda funny too because a lot of this is Google fighting Google. Got devs trying to push PWA and putting in time to make it work and got managers watching the bottom line and crippling or killing anything threatening it. Google Graveyard anyone?

  1. This is the funniest “denial of service” attack I’ve ever seen. Better than any fork bomb or infinite popup or spiders-on-desktop griefing. Anchoring the models to walls really sells it. If you just wanted a regular DoS attack, transparency and lighting features exist in the spec.

  2. Seems crazy to me a modern browser can spawn another process at all without the user jumping through a few hoops to make it happen…

    What a great bit of ‘fun malicious’ work though, I wonder if there is a more genuine threat vector beyond just being annoying though…

  3. I assume you could have popped up a virtual object that looked exactly like a system password dialog or similar, so this is a phishing exploit.

    Outside of that it’s “just” a UX flaw, and all desktop environments have the same flaw, which is that the UI to show you what’s running has very little to do with what’s actually running. If you can kill a process via Activity Monitor or Task Manager, the developer may not see a problem, but what the user sees is an unkillable process, because you’ve chosen to lie to them about how this stuff works. It’s like how web developers have gradually broken the concept of the Back button, by implementing “better” naviagtion but failing to consider what happens when their “better” solution breaks.

    1. This started 20 years ago when they hid the log out button in a drop down menu. But if your service was slow or spotty it took forever to get the drop down menu to happen. It was awful.

    2. As a web dev since before Google existed, especially one doing web apps that don’t navigate (SPA is the term now), I totally feel this. Hopefully 3rd time will be a charm with the web navigation api or whatever it’s going to be called.

      People didn’t even want to make it possible to affect the history, back/forward or url bar. There’s definitely cases where I agree (sites that can’t implement it properly or never let you go back to the previous origin) but also I’m glad that didn’t happen as many web apps would have been difficult or impossible.

      However that doesn’t mean everyone should be doing React-based SPA sites everywhere everytime with off the shelf navigation libraries knowing SFA about it and breaking my back button.

    3. I have this with the news feed on my phone’s home screen (android). The news feed is normally good (it is how I found this article) and you click on an article and then do the back command/gesture and it closes the article, but some don’t do that, instead trying to go back takes you to a full page of adverts and you need to go back again to get out of it. That shouldn’t be allowed, if I want to go back it should take me back, not forward onto a page full of adverts.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.