Live data from Hacker News

Vulnerability in the Mac Zoom client allows malicious websites to enable camera

medium.com

361–370 of 473 posts

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#361

Earlier quoted context omitted.

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.

I don't see how it solves the selfpwn problem - that is, for any capability I can explicitly grant if I know what I'm doing, someone else can grant it because a malicious actor nicely asked them to do it. If you take away the ability to grant the capability, you're reducing usability.

Yeah, that's really an unsolvable problem I guess. But you could at least make it clear to the user what some app is requesting. If it's requesting the root capability / ambient authority (basically access to everything) then that should be a big red flag.

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#362
post #255

Earlier quoted context omitted.

For the non bash users among us?

There's nothing specifically bash about it, but here's what the components mean: "kill" = kill running process "-9" = kill as forcefully as possible "$(...)" = command substitution: run the stuff inside the brackets and replace this term with the results (it will be the processes to kill in this case). "lsof" = list open files (other things like ports and devices count as files on Unix systems) "-i" = search for inte…

Is lsof part of the default install of OSX? It isn't usually part of the base install on Linux (though obviously very easy to install)

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#363

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).…

Thanks for the info!

I still don't fully understand _why_ they had to do this hack if they own the localhost server. They could just set CORS to be '*' and lax their CSP. Then they would be able to get data with JS.

For example this website can see any localserver on your network with open CORS since it appears they laxed their CSP.

http://http.jameshfisher.com/2019/05/26/i-can-see-your-local...

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#364
post #331
post #325

Earlier quoted context omitted.

Any program can do anything in modern Windows too, only special places like C:\Windows\System[32] are protected. I'm not against such protections since they can be easily overridden if needed and in day-to-day use they do not harm anyone nor affect negatively the usability of the system. I'm not saying that we should go back to 90s entirely, we have a lot of good improvements over the years. I'm just hoping we'll ton…

I agree that less connectivity is better for security, which is why I think rushing to IoT-everything is premature. However unless a computer cannot be physically connected to the internet, it must implement all of the protections it can. Just not having wifi enabled or cable disconnected is a false sense of security.

The question is about the "all the protections it can" part - what does that imply? Because "all the protections" can include user hostile (not just in terms of usability) misfeatures that give control to OS vendors in the name of security even though the real purpose is controlling what the users can do with their own devices (for a variety of reasons, with stuff like market segregation and forced obsolescence being among the more benign ones).

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#365
This is even crazier, because a webpage could load the iframe or img tag lazily, long after the page has been opened and is in the background because the user left the tab open, and the user would have no way of knowing which page is responsible for opening Zoom.

Furthermore, in Chrome, the webpage can set a timeout which brings the browser window back into focus. So for example, if Zoom usually takes about 1 second to open, then the browser could set the timeout for 1100ms, so that zoom is only visible to the user for a split second before it's backgrounded with their camera enabled. Either of the following will bring Chrome back to the foreground:

    setTimeout( function() { alert("Hi") }, 1100)

    setTimeout( function() { var win = window.open("https://www.google.com", '_blank'); win.focus(); window.close() }, 1100)
The latter is a little less of an alert to the user that something has happened, since it could be used to reload the current page without the offending image or iframe tag, which would look to the user like the page just randomly reloaded itself.

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#366
post #328

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…

My comment isn't an ideal solution, it is what i consider a better solution considering how things are treated nowadays.

Ideally users would be wary of what they do with their computers, but considering how the world devolved from "you should never use your real name and address online" to modern social media, this is yet another case where i do not see such an ideal happening.

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#367
post #335

Earlier quoted context omitted.

Could you further explain the CORS bypass? Why do they have to do the image hack if CORS if they open up CORS on the local server? At that point couldn't they retrieve data via JS instead?

CORS isn't supported to localhost, aka you can't do that; hence the image-size hack

It appears CORS _is_ supported to localhost according to this website.

If you have an open local server running this will detect it.

http://http.jameshfisher.com/2019/05/26/i-can-see-your-local...

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#368
post #328

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…

This is what things like https://sandstorm.io and Google's Fuchsia OS are trying to solve. Of course it requires a huge shift in how you design applications, but it does not impose any burden on the user's side really. They just allow $APP access to some data or resource, and then it has access to only what it needs going forward, with no need to allow it every time (unless you revoke it). This can be done when the a…

My original comment was about having computers be less connected because a large reason for security issues and their implications today arise from their connectivity, so i do not see what sandstorm.io is solving there.

I'm not familiar with Google's Fuchsia OS to judge, though i do remember reading some months (year?) ago about a clash between their developers and Google's advertising team that ended up with the developers compromising Fuchsia's design. Which brings me back to "let's not rely too much on connected stuff and prefer stuff we have control over, shall we?"

Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera

#369
post #364
post #331

Earlier quoted context omitted.

I agree that less connectivity is better for security, which is why I think rushing to IoT-everything is premature. However unless a computer cannot be physically connected to the internet, it must implement all of the protections it can. Just not having wifi enabled or cable disconnected is a false sense of security.

The question is about the "all the protections it can" part - what does that imply? Because "all the protections" can include user hostile (not just in terms of usability) misfeatures that give control to OS vendors in the name of security even though the real purpose is controlling what the users can do with their own devices (for a variety of reasons, with stuff like market segregation and forced obsolescence being…

All the protections that help the machine survive in non-compromised state in a hostile environment. I think of stuff like not giving random users permission to write over system files or give processes access to peripherals (camera, microphone) without explicit user consent.
Post reply on HN