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.
Vulnerability in the Mac Zoom client allows malicious websites to enable camera
361–370 of 473 posts
Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera
#362Earlier 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…
Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera
#363Earlier 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).…
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
#364Earlier 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.
Re: Vulnerability in the Mac Zoom client allows malicious websites to enable camera
#365Furthermore, 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
#366Earlier 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…
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
#367Earlier 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
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
#368Earlier 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…
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
#369Earlier 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…