1. 82
  1.  

  2. 26

    The security issues outlined by this article are clear, so I won’t comment on them. I did want to comment on this peripheral point:

    This same vulnerability also allowed the attacker to DOS any user’s machine. By simply sending repeated GET requests for a bad number, Zoom app would constantly request ‘focus’ from the OS.

    I’ve long thought that OSes (or WMs, whatever) should pretty much never bring a window (or dialogue box, or any such UI element) into view, or take input focus (keyboard or mouse) without explicit user interaction (i.e. key press, mouse click or screen tap). Instead, they should indicate to the user that some application or widget “wants attention”, for example by making an application’s entry in the WM’s task bar blink/flash. Then, the user can choose to take explicit, manual action (e.g. in this example, click on the task bar) to bring the window or other UI element up to z-index 0 and allow it to take input focus.

    Time and again, all through the years, we experience the UX pain of happily and intentionally typing (or clicking) in one UI element, and something pops up, takes input focus, and we unintentionally send keystrokes or mouse clicks into that surprise UI party crasher. How many decades of UI and UX research have come and gone since the earliest GUIs came on the scene? This kind of thing should never happen – yet, it does, and I find that just a little ridiculous.

    I welcome any counterexamples showing a case where it would be a good thing for a new UI element to steal input focus without the user first performing an input.

    1. 14

      If you peruse Raymond Chen’s blog at Microsoft, there are multiple entries about customers who want to make sure that their window is placed front and center and grabs all input. It’s easy for even a non-malicious application developer to convince themselves that their product is so good that this behavior will actually be welcomed by users.

      Chen does not agree, by the way.

        1. 1

          Thanks!

          It does look like both items link to the same post, though.

          1. 3

            Oops, copy/paste failure. Sorry about that! I’ve fixed the second one.

      1. 5

        I recently switched back to a Linux laptop, and a feature I love over OSX is that when an app wants focus, instead of just taking focus, PopOS (probably gnome?) displays a toast saying “NeedyApp is ready”. I can switch to it when I’m ready too.

        1. 3

          When my terminal opens a system dialog to unlock my password manager. I’ve hardcoded that as the only exception to “no stealing focus” in my i3 config.

          1. 3

            What does your “no stealing focus” config entry(-ies?) look like?

            1. 2

              I see your point, and can accept that others have different preferences, but if it were me, I’d let such a thing remain not an exception, and just stay unfocused and flashing in the task bar. But then, I reboot scarcely 5 times a year, so unlocking like this is something I rarely do.

            2. 1

              Indeed – I’ve been thinking lately that UIs should be given much of the same consideration we give to APIs regarding things like race conditions (as in your example) and backwards compatibility. The user, after all, is ultimately another component interacting with other components of the overall system…

              1. 1

                Reminds me of the javascript popup-bombs from the early 2000s. A never ending stream of popup windows and dialogues, close one and three appear.

              2. 14

                Aside from the main vulns in the article, some highlights that I found horrifying:

                Additionally, if you’ve ever installed the Zoom client and then uninstalled it, you still have a localhost web server on your machine that will happily re-install the Zoom client for you, without requiring any user interaction on your behalf besides visiting a webpage. This re-install ‘feature’ continues to work to this day.

                Offered and declined a financial bounty for the report due to policy on not being able to publicly disclose even after the vulnerability was patched.

                Enabling “Participants: On” when setting up a meeting, I discovered that anyone joining my meeting automatically had their video connected.

                1. 8

                  The localhost web server struck me the most. That’s literally what a virus or some malware would do.

                  1. 1

                    This doesn’t neutralize all the major problems with Zoom (the company), but, in fairness, the article points out that the problem about your video being automatically turned on doesn’t happen when you change your preferences to keep your video off when you join calls. That said, I haven’t actually tested the full truth table of all the booleans involved here.

                  2. 7

                    The CVE mentions macOS only, is this also an issue on other platforms?

                    1. 6

                      The POC links did launch a zoom call on my Linux machine but I don’t see the port being used by a server when I run lsof -i :19421.

                    2. 6

                      Running a localhost server on a user’s machine is atrocious.

                      According to the Zoom team, the only reason this localhost server continues to exist is that Apple’s Safari doesn’t support URI handlers.

                      I don’t buy this. Zoom’s use case for this is to launch the Zoom client with parameters when clicking a link from Safari. There has to be other software that has similar requirements. The localhost thing smacks more of jamming webdev into every nook and cranny it could possibly be, regardless of the natural consequences.

                      1. 2

                        Safari certainly does support URI handlers, but they all require a confirmation. Zoom wants to silently launch their client.

                      2. 6

                        How is it that Internet pages are allowed to access private network addresses? There’s a proposal to prevent this, or at least require user permission, but does anyone know why it’s not already implemented?

                        https://wicg.github.io/cors-rfc1918/

                        As far as my imagination can figure, the only reason for doing that is to circumvent something…

                        1. 7

                          There are cases where it’s required. I personally think it should be something that prompts the browser to open a permissions modal just like with notifications, web cam access, etc. That would make the end user aware of what is going on and give them the chance to allow because it’s expected or deny if else.

                          1. 2

                            There’s the OAuth use case if you want a “native app” to obtain an access_token on behalf of the user: https://tools.ietf.org/html/rfc8252#section-7.3

                            edit: on macOS and Windows you can’t do this any other way as applications can’t use “Claimed “https” Scheme URI Redirection” or “Private-Use URI Scheme Redirection” (without publishing them in the app stores).

                          2. 4

                            My zoom.us app doesn’t seem to be affected by this exploit. I can only surmise that since I downloaded it in 2017 and haven’t opened it since then, this whole thing must have been added sometime in the last year.

                            https://i.imgur.com/UUvnZYv.png

                            I’m also able to put the zoom app in the trash without it reinstalling. I’ve confirmed through the command line that:

                            • There are no localhost daemons running on port 19421 (lsof -i :19421)
                            • No ~/.zoomus exists on my machine (ls ~/.zoomus)
                            • There is no process named ZoomOpener running in the background (ps -ef | grep Zoom)

                            According to my evidence, Zoom wasn’t always like this. I wonder what persuaded them to make this decision in the last year…

                            1. 4

                              It’s a somewhat recent update, and allegedly was to “fix” the fact that Safari changed to require explicit user permission. Zoom didn’t want the extra click on join, so they did this to try to get around it.

                              1. 3

                                Can you imagine how many hours were wasted to save a click on not even the most common browser?? Seems like their priorities are in order…

                            2. 2

                              I notice that (on Mac), even if you SIGTERM the localhost process (pid found with lsof -i :19421, but killall ZoomOpener also works), Zoom just restarts it when you join a meeting/call. As described in the article, the executable resides in ~/.zoomus. I mved this away somewhere, thinking I would be taking away the thing Zoom is executing, but, guess what: Zoom literally just recreated the dir and all its contents upon joining a meeting. *facepalm* *wipe face downwards*

                              1. 3

                                The article includes proper patch instructions in the “Patch Yourself” section (the trick they use is to create a new file at ~/.zoomus and chmod 000, so that the app doesn’t mess with it, but future versions of the app could bypass this).

                                1. 2

                                  Yes, but (and I forgot the source, sorry) people who had it installed and since uninstalled it are still affected because the localhost webserver was still running.

                                2. 1

                                  I’m just glad stuff like webex seem to just work without any external binary or plugin. I find it ridiculous after all the flash player crap people are perfectly ok installing some random program to run some telepresence software. This whole issue was inevitable.

                                  1. 2

                                    But WebEx does have a native client afaik?

                                  2. 1

                                    I wonder if RingCentral is vulnerable as well, since they use Zoom underneath.

                                    1. 2

                                      They are.

                                      1. 1

                                        Thanks, I actually found a comment on Hacker News saying so soon after but forgot to update my comment.