351–360 of 473 posts
Have been using Zoom for the last three yeara and I have recommended it to a lot of people. Seeing how they handled this accident I will never recommend them again.
Earlier quoted context omitted.
Finely grained permissions mean bad UX and as Android has shown you gain nothing practical from that since the people will learn to ignore them pretty much like they learn to ignore the UAC warning while on the other hand you lose the flexibility, functionality and openness of the entire system (all significant pillars for ensuring user control). Note that i'm not saying to disconnect computers entirely, i'm saying t…
> we can simply treat the network itself as hostile and try to defend from it (e.g. applications that can access the network cannot access outside of a designated folder - the OpenBSD pledge approach but forced on all applications that access the network) Won't work. Malicious actors (both malware developers and companies with user-hostile business models) will start working around it, by for instance giving you two…
This is exactly the type of problem it solves, usability with security.
Earlier quoted context omitted.
I'm a bit confused, so CORS doesn't apply when trying to load an image? If they set CORS to allow interaction from anywhere, why use an image and not load data with js?
CORS is set up to protect data from being given to a third party, e.g. JS requests obtaining and being able to observe data they shouldn't have access to. Since images are being loaded by the browser (second party), there is no such protection, since a third party should not be able to read them anyway (barring some other vulnerability). It's assumed the first party is correctly doing what it's supposed to, an exampl…
I asked Zoom support about this and they sent me to this page: https://blog.zoom.us/wordpress/2019/07/08/response-to-video-... The key thing here is they think this is a fair trade-off because Safari asks if you want to open Zoom. > This is a workaround to a change introduced in Safari 12 that requires a user to confirm that they want to start the Zoom client prior to joining every meeting. The local web server enabl…
Oh, definitely. I cancelled my subscription because of this, but I wonder if the reason will make it through the corporate fog.
What is worrying is that more and more companies think it is fine to install "helpers", "openers" and other cruft. I recently removed several, and I still have to use software that scares me sometimes (DYMO web printing, Brother web printing). This should not be considered OK.
I really wish physical switches that cut power to mics and cameras were standard on everything. I know that would be change from how hardware works / is designed now but it also seems like the only reliable line of defense.
some computers have this e.g. raspberry pi
For those who aren't familiar with pinebooks, they're $99 arm-based linux laptops.
Earlier quoted context omitted.
I did this: 1. killed by process name, and zoom app will 2. fail to start its opener and 3. fail to reinstall it: killall ZoomOpener chmod -x .zoomus/ZoomOpener.app/Contents/MacOS/ZoomOpener sudo chown -R nobody:nobody .zoomus/ZoomOpener.app
Doing it that way results in a nuisance prompt from Zoom every time you launch it complaining that it can't launch the opener. Here's a modified version that deletes the app, removes the LoginItem if it exists, and makes the ~/.zoomus directory unwritable, which achieves the same thing but avoids the nag: killall ZoomOpener osascript -e 'tell application "System Events" to delete login item "ZoomOpener"' rm -rf ~/.zo…
Zoom’s response to this[1] is a wonderful example of how not to respond to security issues. It includes the classic tropes: * Our users don’t care about security. > Our video-first platform is a key benefit to our users around the world, and our customers have told us that they choose Zoom for our frictionless video communications experience. * We have no way of knowing if this has been exploited in the wild, so it’s…
Is an NDA really "common industry practice" for bug bounty programs? I know NDAs are common for pen-testing but it seems like an odd (and kind of dishonest) requirement for a bug bounty program.
Earlier quoted context omitted.
CORS isn't supported to localhost, aka you can't do that; hence the image-size hack
But the image is being served from localhost no? Do image requests not abide by CORS?
Earlier quoted context omitted.
> we can simply treat the network itself as hostile and try to defend from it (e.g. applications that can access the network cannot access outside of a designated folder - the OpenBSD pledge approach but forced on all applications that access the network) Won't work. Malicious actors (both malware developers and companies with user-hostile business models) will start working around it, by for instance giving you two…
Have you looked into the object capability model of permissions? https://en.wikipedia.org/wiki/Capability-based_security This is exactly the type of problem it solves, usability with security.
Earlier quoted context omitted.
But the image is being served from localhost no? Do image requests not abide by CORS?
They do not. The reason for that is that at the time CORS was designed lots of sites loaded images from other sites and because images where considered static content that didn't change the server this was at worst a information leak. What Zoom has done here is abuse a HTTP GET via a tag (which is not supposed to change anything) as a way to trigger a privileged local process to INSTALL software (among other things).…