[HN Gopher] Ask HN: Why does Zoom Desktop examine all processes ...
___________________________________________________________________
Ask HN: Why does Zoom Desktop examine all processes and arguments?
Looking at syscalls, I see Zoom desktop reads all processes and
arguments. [pid 3844872] stat("/proc/1",
{st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 [pid 3844872]
openat(AT_FDCWD, "/proc/1/stat", O_RDONLY) = 4 [pid
3844872] openat(AT_FDCWD, "/proc/1/cmdline", O_RDONLY) = 4
[pid 3844872] readlink("/proc/1/exe", 0x20c0520, 1024) = -1 EACCES
(Permission denied) [pid 3844872] stat("/proc/2",
{st_mode=S_IFDIR|0555, st_size=0, ...}) = 0 [pid 3844872]
openat(AT_FDCWD, "/proc/2/stat", O_RDONLY) = 4 [pid
3844872] openat(AT_FDCWD, "/proc/2/cmdline", O_RDONLY) = 4
[pid 3844872] stat("/proc/3", {st_mode=S_IFDIR|0555, st_size=0,
...}) = 0 [pid 3844872] openat(AT_FDCWD, "/proc/3/stat",
O_RDONLY) = 4 [pid 3844872] openat(AT_FDCWD,
"/proc/3/cmdline", O_RDONLY) = 4 ... Why would it
do that? Is there any way to prevent it?
Author : neolog
Score : 247 points
Date : 2021-08-17 18:38 UTC (4 hours ago)
| the8472 wrote:
| > Is there any way to prevent it?
|
| Firejail[0] allows cobbling together various linux sandboxing
| features, including namespaces which should result in an isolated
| proc filesystem which doesn't see the other processes. But I
| don't know if the default profile for zoom does that, you have to
| test it or write your own.
|
| [0] https://github.com/netblue30/firejail
| als0 wrote:
| Just checked the default profile and it looks sufficiently
| isolated
| guerrilla wrote:
| SELinux being another. Smack too, if people still use that.
| reilly3000 wrote:
| Zoom has a popular feature which allows for screen sharing a
| single application window instead of the entire desktop. I assume
| this is how its discovering running applications with GUI windows
| open in a cross-platform manner. Perhaps there is a better API
| for this? Its not a common use-case that an app would need to
| know all of the other open windows, but it seems like a perfectly
| valid use case, and frankly handy for sharing a PPT without fear
| of an embarrassing email showing up in during a meeting.
| yakubin wrote:
| _> handy for sharing a PPT without fear of an embarrassing
| email showing up in during a meeting._
|
| When you share a single window in Zoom, notifications are still
| visible to others in the meeting when they overlap with the
| window you're sharing. That's the case for e.g. Slack
| notifications.
| TameAntelope wrote:
| I literally quit all messaging apps when presenting to people
| for any period of time more than ~10s.
| aetherspawn wrote:
| They are grayed out for everyone else, so they can't actually
| read the contents.
|
| Caveat being if you move the window around really fast
| sometimes it's possible to catch a glimpse.
| sails wrote:
| Does Teams do this in the same way? They offer the same feature
| sniperjzp wrote:
| Not sure about Teams, but Google Meet allow you to share a
| specific browser tab, I don't know how to implement it
| without reading all the opened tabs.
| meibo wrote:
| There is a JavaScript API that abstracts this, so Google
| Meet/whatever asked can only read the "final" video stream
| of what you selected and not everything that's going on,
| which stays in your local browser.
| twic wrote:
| I run Zoom from flatpak, which runs it in a container, and
| sandboxes it to some extent [1]
|
| This probably explains why, when i try to screenshare a single
| application window, not every application shows up! I can share
| my browser, file manager, and various other things, but not
| windows for games started by Steam.
|
| [1] I followed these instructions
| https://www.mayrhofer.eu.org/post/zoom-flatpak-sandboxing/
| cranekam wrote:
| There's nothing in /proc/PID/cmdline etc that would definitely
| confirm an app has a GUI. The two concepts are at very
| different layers of the stack -- to the OS the GUI is just
| another app on top of the kernel. Mayyyyyybe Zoom could be
| doing some crude pattern matching on process name or
| environment variables of a given process (though it'd only be
| able to read data of processes running as the same user) but
| it's a long shot.
|
| Personally I'd guess it is either some other library Zoom uses
| or some kind of debug info capturing system. But I don't know
| work at Zoom so who knows.
| woodruffw wrote:
| This is an unlikely stretch, but it looks like they're also
| attempting to read `/proc/PID/exe` -- they could be doing
| something (extremely) cursed like attempting to parse the
| program linkages and filtering by programs that link to
| `libX11`. But that's me straining to explain this in the
| context of the GP's hypothesis.
| thrower123 wrote:
| Never attribute to malice what is adequately exlained by
| laziness.
|
| I can easily believe somebody just wrote a chunk of naive
| code that grabbed all the running processes, and it worked,
| and they moved on.
| propogandist wrote:
| or it's spyware, maybe not as bad as a keylogger, but it
| can be mining your active usage behavior
| reilly3000 wrote:
| This could be verified by inspecting their analytics
| requests. If I have time I may take a peek at those
| later.
| propogandist wrote:
| whoever does the analysis may also become a
| whistleblower.
| gmueckl wrote:
| Nah, the readlink on exe looks like it's simply to query
| the real name of the executable, so that's pretty benign.
| woodruffw wrote:
| Based on OP's snippet they're probably doing this on Linux.
| Assuming the presence of X11 and an EWMH-compatible window
| manager, they could query X11 directly and ask the root window
| for its `_NET_CLIENT_LIST` attribute. That, in turn, would list
| every "semantic" (i.e., non-decorative) window currently open
| on the current display.
|
| But that doesn't work for non-X11 or if the WM is non-EWMH
| compliant. Presumably Wayland has a similar API, and non-EWMH
| is probably a minuscule group that considers this a desirable
| feature.
| sp1rit wrote:
| One of the selling points of Wayland is, that they have no
| such API. An Application is supposed to be unable to access
| windows (and their corresponding keyboard/mouse input).
|
| One of the downsides this has is the described issue of
| "screensharing beeing impossible on wayland". This is solved
| by the XDG Desktop Portal, which provides a unified dbus
| interface across the different compositor implementations for
| requesting a pipewire file descriptor (which can be used with
| gstreamer to get a live video stream of the deskop, in a way
| far superior to x11 framegrab). However the implementation
| differs for each compositor, GNOME for example asks you if
| you what to share the whole screen or just a specific
| application but wlroots (swaywm, wayfire, etc.) AFAIK
| automatically accepts and shares the whole screen. I don't
| know what KDE Plasma does.
| kelnos wrote:
| > _I assume this is how its discovering running applications
| with GUI windows open in a cross-platform manner._
|
| That's definitely not a cross-platform way of doing it (and I
| doubt there is one, even).
|
| On Linux you'd use libX11 and just enumerate all windows (using
| XQueryTree()). Walking the contents of /proc is not only
| unnecessary, but is more difficult to do, as looking at
| executable names won't tell you if a program has a GUI, or if
| it has any open windows. It won't give you window titles, or
| how many windows are open, or how to grab their contents.
|
| Pretty sure Zoom is snooping on us and is gathering telemetry.
| mwcampbell wrote:
| > Pretty sure Zoom is snooping on us and is gathering
| telemetry.
|
| Don't forget Hanlon's razor, as someone else in the thread
| pointed out.
| dng88 wrote:
| Would it be better if run in a vm?
| andrewlevi wrote:
| Does Teams or Discord do anything similar?
| P9TXJYG0TENG wrote:
| Discord does. It makes some sense, since Discord has a feature
| to broadcast what game you're currently playing (or anything
| you want), but I found it was scanning /proc even when I turned
| this off.
|
| I didn't like that, and I spent a lot of time and effort
| working out various ways to keep it out of /proc (or anywhere
| else while I was at it- mostly with AppArmor) and ultimately
| ended up running it in a container with systemd-nspawn. This is
| still a little bit fiddly, but seems to work reliably and
| without any issues.
| lathiat wrote:
| The discord snap blocks this with apparmor by default unless
| you connect process-control. But it also fills your kernel
| log with audit denials.
| P9TXJYG0TENG wrote:
| I think I tried one of those alternative app distribute-y
| things at the time, but I don't remember which, and I came
| away disappointed. If memory serves, I couldn't establish
| whether it actually did any sandboxing, or what it did by
| default (like intentionally opening up this exact hole),
| and certainly not how to configure it, and gave up shortly
| in favor of something I'd at least seen before.
|
| It _might_ have been Snap. I don 't like Snap.
| GekkePrutser wrote:
| I know a really good way to prevent it. Don't use zoom :)
| Seriously they've done so many things that show they don't care
| about privacy. Like that backdoor on Macs.
|
| But if you really must, use the web version only.
|
| If you can avoid it, jitsi is a great alternative. Much smoother
| video than teams and much lighter
| fsflover wrote:
| > Is there any way to prevent it?
|
| I prevent it by running Zoom in a VM on Qubes OS.
| ezekg wrote:
| Or just run it in a browser...
| 99mans wrote:
| Because they can get away with it and use it to make more money
| from your "experience".
| ianlevesque wrote:
| Zoom is basically malware with video chat.
| barbazoo wrote:
| Elaborate please
| miles wrote:
| 'Zoom is malware': why experts worry about the video
| conferencing platform
| https://www.theguardian.com/technology/2020/apr/02/zoom-
| tech...
|
| Zoom banned from New York City schools due to privacy and
| security flaws https://www.fastcompany.com/90486586/zoom-
| banned-from-new-yo...
|
| Google Told Its Workers That They Can't Use Zoom On Their
| Laptops Anymore
| https://www.buzzfeednews.com/article/pranavdixit/google-
| bans...
|
| Elon Musk's SpaceX bans Zoom over privacy concerns
| https://www.reuters.com/article/us-spacex-zoom-video-
| commn/e...
|
| Zoom lied to users about end-to-end encryption for years, FTC
| says https://arstechnica.com/tech-policy/2020/11/zoom-lied-
| to-use...
|
| Zoom security issues: Here's everything that's gone wrong (so
| far) https://www.tomsguide.com/news/zoom-security-privacy-
| woes
|
| Maybe we shouldn't use Zoom after all
| https://techcrunch.com/2020/03/31/zoom-at-your-own-risk/
|
| Attackers can use Zoom to steal users' Windows credentials
| with no warning https://arstechnica.com/information-
| technology/2020/04/unpat...
| notwhereyouare wrote:
| and on the front page currently:
| https://news.ycombinator.com/item?id=28210076
| monocasa wrote:
| I can't believe I'm saying this, but I'm not sure that last
| one is zoom's fault. It sounds like Zoom is just calling
| ShellExecute("open", link), and is getting blamed for the
| fact that Windows will then connect to random server on
| public internet and can be convinced to send a hash of the
| password that can be used to forge a different connection
| from a different host/client pair with the same
| credentials.
| movedx wrote:
| I'm really, really annoyed that you're being downvoted for
| providing citations: as f-ing requested!
|
| Thank you. These will make for some interesting reading.
| [deleted]
| humaniania wrote:
| https://citizenlab.ca/2020/04/move-fast-roll-your-own-
| crypto...
| infamouscow wrote:
| This really should be self-evident
| jagged-chisel wrote:
| > Is there any way to prevent it?
|
| Hook the stat, openat, readlink functions within the zoom
| process, experiment with blocking (returning failure) based on
| arguments.
| [deleted]
| MichaelGroves wrote:
| > _Is there any way to prevent it?_
|
| Do what I do: Run it on a burner computer connected to your guest
| network.
| dllthomas wrote:
| > Why would it do that?
|
| We can answer part of that with just a little more reading.
| What's pid 3844872?
|
| For me, the series of queries against /proc happen from a process
| that, just a bit earlier, called exec. So it's not really zoom
| reading "all processes and arguments" but ... `pidof gnome-
| session`, so I guess zoom is looking for the pid of gnome-
| session.
|
| To what nefarious purpose zoom intends to put this knowledge of
| gnome-session's pid, I can't say; but at least for me, for that
| particular run, zoom itself doesn't actually see the contents of
| all of those files.
| MattGaiser wrote:
| And for people giving ways to prevent it, can you please provide
| some context for those of us who aren't OS experts?
| dsr_ wrote:
| If you must use zoom, use it in a browser; uninstall their app.
| MattGaiser wrote:
| I didn't know that Zoom allowed that. Thank you.
| elliekelly wrote:
| I must have uninstalled their app on my Macbook ten times now
| but somehow it keeps coming back. I'll click a link to join a
| meeting and the app launches.
| agustif wrote:
| > https://news.ycombinator.com/item?id=28210076
|
| They recover the app from your backups if available when
| launching. Try appCleaner or something like that, and you
| might need to delete it from any TimeMachine backups too,
| lol
| jraph wrote:
| "Zoom does not work on my computer*, can we try X instead?"
|
| With X = something the other end does not need to install, like
| Jitsi Meet for instance
|
| *no need to explain that's because you uninstalled it and
| blocked its domain on your computer.
| slownews45 wrote:
| Be careful with this. In some orgs you can get a bit of a bad
| reputation for being technically incompetent if you can't get
| zoom to run.
|
| Zoom is very invasive / flexible - so it's actually somewhat
| hard to have it NOT work. People will suggest you try
| connecting on your phone or dialing in if you really can't
| figure it out (note that it has a fallback to browser option
| if you get stuck trying to start meeting as well).
|
| I know of at least one job interview where they claimed they
| couldn't get zoom to run / couldn't connect - and that was
| basically decisive.
| travoc wrote:
| You can avoid this reputation by saying "our security
| analysts block Zoom because they think it might be
| untrustworthy spyware."
| slownews45 wrote:
| That's def a better response then I can't figure out how
| to call into the zoom call!
|
| That said, a fair number of folks don't credibly have
| "security analysts". Unless you are interviewing /
| working for some sort of high security / security analyst
| type job the world may move on pretty quickly without
| you.
| MattGaiser wrote:
| A bit difficult when your org has decided to use Zoom for
| large meetings.
|
| Although I nearly universally would be happy to skip those
| meetings, so...
| pjc50 wrote:
| Use the work laptop. Its security is then their problem,
| not yours. Do I care if the Chinese government know that
| I've got Visual Studio open?
| jazzyjackson wrote:
| You can call in by phone
| MattGaiser wrote:
| They are picky about making sure everyone uses a camera.
| jraph wrote:
| Then I guess your IT department or your management is
| happy to share your work computer's content with Zoom. I
| see three paths:
|
| - Resort to use Zoom in a browser, maybe from a separate
| profile
|
| - If this does not work for you, use Zoom from a virtual
| machine (it should be possible by exporting the camera
| likely connected by USB to the VM)
|
| - If you'd like to avoid a VM because it's heavy /
| annoying, I'm not sure there's an easy solution without
| learning how to use namespaces and unshare.
|
| Additionally, and optionally:
|
| - Gently campaign against Zoom or for a better solution
| internally.
| 908B64B197 wrote:
| If you care about protecting your IP or your company from state
| sponsored actors it's better to avoid Zoom due to it's ties
| with the CCP [0]
|
| [0] https://techcrunch.com/2020/06/11/zoom-admits-to-shutting-
| do...
| kevmo wrote:
| Zoom is pursuing surveillance profits.
|
| Shoshanna Zuboff has an excellent book on "surveillance
| capitalism", if you want to read more on the trend.
| wins32767 wrote:
| If I had to guess it's for screen sharing.
| sithadmin wrote:
| This. It enables single-app share, instead of just capturing
| entire displays.
| akira2501 wrote:
| Unless I'm missing something.. all of the required
| information is available through the X11 protocol. Reading
| the command lines of the processes is unnecessary and
| provides data that isn't useful in the window sharing
| context.
| jraph wrote:
| This would not work on Wayland, though.
| bonzini wrote:
| Wayland is even more strict, you ask it for screen
| sharing and it gives you the stream. If the compositor
| doesn't support screen sharing you're out of luck,
| there's just no way to read the contents of a window.
|
| With X11 if the window manager doesn't have the relevant
| support you can always ask the server.
| yjftsjthsd-h wrote:
| How would that work? I would expect it to enumerate X
| clients, not PIDs
| [deleted]
| _sgianelli wrote:
| If so that seems like a great place for someone like Apple or
| Microsoft to offer an API to bolster security and privacy
| thephyber wrote:
| OS X already requires that the user open Settings and give
| the app elevated permissions to be able to share the screen.
|
| One can argue about the granularity, but you can't argue that
| Apple hasn't already done something.
| uoaei wrote:
| "Doing something" seems like a really low bar when that
| "something" is basically useless for the intended use case.
| olyjohn wrote:
| Honestly, I kind of agree with this downvoted post. The
| MacOS permissions prompts are starting to drive me
| apeshit. Average user is going to start ignoring them and
| just click yes to everything anyways. Just like everybody
| already does on their phones. Reminds me of when Windows
| Vista came out and they started prompting for permissions
| like crazy. Everybody hated it. Maybe it was just ahead
| of its time.
|
| I already granted this permission to Teams on my Mac.
| It's not malicious now, but when an update comes out in
| the future, it could be, and I've already allowed it. So
| this whole thing feels kinda dumb. Nobody wants to manage
| all this shit, and nobody understands it.
| Wowfunhappy wrote:
| They drove me so insane that I abandoned modern macOS
| entirely.
| thephyber wrote:
| I don't understand your threat model.
|
| The user chose to install an application, then had to use
| admin permissions to choose to give that application more
| access after installation.
|
| How much additional nanny protection should a user get?
| puttycat wrote:
| How come the OS doesn't provide the list instead of each app
| enumerating all the proecesses itself?
| formerly_proven wrote:
| You're looking at the API.
|
| Also, screen-sharing can't be the reason, because X windows
| don't have anything to do with processes on the machine.
| tyingq wrote:
| Enumerating window handles and titles would be more suited to
| that. It will need that anyway to share the window. On a multi-
| user system, it could see processes attached to displays it has
| no access to.
| jlgaddis wrote:
| > Is there any way to prevent it?
|
| Mounting /proc with " _hidepid=2_ " should prevent it from seeing
| processes owned by other users, although it would still be able
| to see your processes.
|
| Alternatively, it shouldn't be too hard to create an AppArmor
| profile that blocks access to /proc.
|
| Other options might include things like SELinux, seccomp-bpf,
| namespaces, cgroups, etc., depending on what's available on your
| host.
|
| Or you could just, you know, obliterate it from your system
| altogether. That's almost certainly the best option.
| minitech wrote:
| > Mounting /proc with "hidepid=2" should prevent it from seeing
| processes owned by other users
|
| Note that this isn't a supported configuration for systemd and
| will totally break it. (Which is too bad, because it's a
| sensible default.)
| _Algernon_ wrote:
| Wouldn't using it through the browser prevent this?
| hdjjhhvvhga wrote:
| I don't understand why anyone who is forced to use it doesn't
| use it in a browser (I have a separate Firefox container for
| that, same for Teams).
| zippergz wrote:
| The people here who are saying "Teams and Meet are just as
| good" are the people who use Zoom in a browser. The audio and
| video quality, and resilience to poor connections, is much
| better in the desktop app.
| avel wrote:
| The browser edition of zoom lacks a _lot_ of features and
| also lacks in performance.
|
| It's not like BlueJeans which has a web version pretty much
| aligned with the desktop client.
| maxk42 wrote:
| That's what they're counting on.
| christophilus wrote:
| Unless you're using Zoom all day, the browser version is
| just fine. Folks can see and hear me; I can see and hear
| them; I can share my screen. It's good enough.
|
| Also, we're trialing big blue button (self hosted) as an
| alternative, and it's honestly pretty decent from what I
| can tell.
| GekkePrutser wrote:
| Does teams work for your in a FF container? For me it always
| ends up in a redirect loop :( but my work uses MCAS for
| external computers so that may have to do with it. It's a
| proxy service from MS that adds some supposed security to
| their services and makes them even slower.
| nsomaru wrote:
| With containers, subdomains and redirects I've found
| switching off network and forcing each subdomain to open in
| a particular container 1-by-1 to work well.
| vbernat wrote:
| For me: more CPU usage (and more battery usage), not able to
| see other participants when sharing screen.
|
| But I am running Zoom in a Flatpak to avoid the kind of
| issues reported here. BTW, the same happens with Discord and
| it's not possible to disable it.
| [deleted]
| laurensr wrote:
| Also note the news and discussion at
| https://news.ycombinator.com/item?id=28210076
| gigatexal wrote:
| Im on a Mac so I can't issue the same ... did you use strace on
| Linux?
|
| This is enough for me to remove the app and just use it in the
| browser.
| saurik wrote:
| > Im on a Mac so I can't issue the same...
|
| dtruss
| lsllc wrote:
| Sadly running dtruss on (modern) macOS requires disabling
| system integrity protection.
| tryauuum wrote:
| (incompetence here) Maybe it's like discord, it does the same to
| display messages like "$username is playing terraria right now"
| wwweston wrote:
| Discord leaks which apps you're using to other people?
| nrabulinski wrote:
| It "leaks" which apps you're using if the developer
| explicitly talks to the discord client. Discord provides an
| SDK for game developers etc which can talk to discord client
| and show the game you're playing and optionally let you
| invite people to your lobby straight from the discord chat.
| It doesn't scan anything or open any processes, it just opens
| an IPC socket.
| voxic11 wrote:
| I think it does scan your processes. If I go to "User
| Settings " => "Activity Status" => "Not seeing your game?
| Add it!" => "Select" then I see many processes that almost
| certainly have no explicit discord integration. I believe
| they do this to allow the user to opt into showing their
| status based on running processes so that any application
| can be supported.
| vbernat wrote:
| It also scans processes. Easy to check: run opensnoop.
| 908B64B197 wrote:
| There's even an Emacs mode for that!
|
| https://github.com/simmsb/discord-emacs.el
| Osiris wrote:
| It's a feature.
| dcdc123 wrote:
| Yeah, I highly recommend disabling it.
| egypturnash wrote:
| So does Steam. It's... a little creepier when it's taken
| beyond "advertise which games you're playing so your friends
| can potentially join you", though.
| delusional wrote:
| Are you sure? I think steam only does it for programs
| launched through it.
| spockz wrote:
| Steam only does this when you launch an app through steam
| and only when it is enabled though.
|
| That is quite a difference from broadcasting the name of
| any binary it recognises.
| LegitShady wrote:
| by default, even.
| humaniania wrote:
| That was the part that bothered me.
| akira2501 wrote:
| > Is there any way to prevent it?
|
| Put it into it's own namespace, and only allow it to connect to
| your X11 session over TCP.
| zzo38computer wrote:
| If you want to prevent programs from accessing other windows,
| then (in addition to using its own namespace and file access)
| you would also need to proxy the X server, or run it in a
| nested X server (which does not have access to the one
| outside).
| yjftsjthsd-h wrote:
| Specifically, Xephyr is generally the go-to option, although
| there are others.
| mishafb wrote:
| I think only Wayland has real security, X11 lets you do
| anything
| phendrenad2 wrote:
| Does that prevent it from reading from `/proc`?
| jraph wrote:
| In a PID namespace [1], it will be able to read /proc, but
| will see nothing interesting other than a strangely empty
| system. The process is isolated from the rest of the system
| as far as processes and PIDs are concerned.
|
| [1] https://www.redhat.com/sysadmin/pid-namespace
| luke2m wrote:
| > Is there any way to prevent it?
|
| Use a flatpak
| 3r8Oltr0ziouVDM wrote:
| When you run proprietary software, you basically give full
| control over your computer to a third party. For the best
| security use a separate physical machine for stuff like this. Or
| a separate operating system (in such case your primary system
| should be encrypted and have a protected boot loader). Or at
| least a VM.
| amelius wrote:
| I've used the method of scanning the environment variables of
| other processes to find the PID of certain applications which
| advertised themselves using their environment variables. This
| could be similar?
| phendrenad2 wrote:
| > Is there any way to prevent it?
|
| Maybe run it in a chroot?
___________________________________________________________________
(page generated 2021-08-17 23:00 UTC)