“This effectively disables code signature verification for its dynamic libraries and enables a code injection attack that Wardle calls "dylib proxying". It's not clear why Zoom uses this exception since its own libraries appear to be properly signed.”
You should write this up in some more detail maybe and then just post a link to your writeup. It seems you are saying something about a thing reported two years ago and it'd make more sense if you explained why you think 'it's back', why it's important, etc. That way you also don't have the problem of links not working in a text-only post. Although keep in mind a minor already-covered Zoom thing (if that's what you happen to have, not if not, of course) right after a big Zoom thread on a current Zoom thing is still within the greater Dupe Metropolitan Area.
I wrote this up, here, not in a blog. The post and the first comment together. Less is more. But the comment was moved by dang to another thread, and got separated from this. I honestly do not see the sense of any of this happening, given the thread had already 100+ votes.
(I'm afraid the comments that were here before are now a little hard to un-merge—but IIRC they were mostly pretty generic about Zoom etc., and thus ok to live in the other thread.)
The linked one is different thing, imho: “giving the updater any file with the same name as Zoom’s signing certificate would be enough to pass the test”
This is about entitlement allowing “dylib proxying”.
“The appeal of injection a library into Zoom, revolves around its (user-granted) access to the mic and camera. Once our malicious library is loaded into Zoom’s process/address space, the library will automatically inherit any/all of Zooms access rights/permissions!
This means that if the user as given Zoom access to the mic and camera (a more than likely scenario), our injected library can equally access those devices.”
There's an even more ubiquitous app that also usually has mic and camera permissions and suffers from a similar (but technically unrelated) local code injection issue: Chrome. The bug is described here [0] and was closed as WontFix because "if your machine is compromised, it's beyond the scope of anything Chrome can do about it".
Even if you don't use Chrome, you probably have at least a few Electron apps installed; they all suffer from the same issue.
The only logical conclusion is the macOS privacy model, TCC, is doomed. There's always an app that has non-default TCC permissions and is vulnerable to some type of local code injection, and at that point any malicious app can also access those TCC-protected features.
“This effectively disables code signature verification for its dynamic libraries and enables a code injection attack that Wardle calls "dylib proxying". It's not clear why Zoom uses this exception since its own libraries appear to be properly signed.”
https://www.csoonline.com/article/3535789/weakness-in-zoom-f...
Check latest pkg with Suspicious Package [0] analyzer.
[0] https://www.mothersruin.com/software/SuspiciousPackage/
Big thread the other day:
https://news.ycombinator.com/item?id=32447339
Comments moved thither. Thanks!
would you, please, un-dupe it? This is different thing
You should write this up in some more detail maybe and then just post a link to your writeup. It seems you are saying something about a thing reported two years ago and it'd make more sense if you explained why you think 'it's back', why it's important, etc. That way you also don't have the problem of links not working in a text-only post. Although keep in mind a minor already-covered Zoom thing (if that's what you happen to have, not if not, of course) right after a big Zoom thread on a current Zoom thing is still within the greater Dupe Metropolitan Area.
I wrote this up, here, not in a blog. The post and the first comment together. Less is more. But the comment was moved by dang to another thread, and got separated from this. I honestly do not see the sense of any of this happening, given the thread had already 100+ votes.
Oops - sorry! I've un-duped it now.
(I'm afraid the comments that were here before are now a little hard to un-merge—but IIRC they were mostly pretty generic about Zoom etc., and thus ok to live in the other thread.)
The linked one is different thing, imho: “giving the updater any file with the same name as Zoom’s signing certificate would be enough to pass the test”
This is about entitlement allowing “dylib proxying”.
Based on a link to the slides for that thread this appears to be a different vulnerability.
https://speakerdeck.com/patrickwardle/youre-muted-rooted
Looks like Zoom is just having a bad week.
Copying back the removed comment:
“The appeal of injection a library into Zoom, revolves around its (user-granted) access to the mic and camera. Once our malicious library is loaded into Zoom’s process/address space, the library will automatically inherit any/all of Zooms access rights/permissions!
This means that if the user as given Zoom access to the mic and camera (a more than likely scenario), our injected library can equally access those devices.”
https://objective-see.org/blog/blog_0x56.html
There's an even more ubiquitous app that also usually has mic and camera permissions and suffers from a similar (but technically unrelated) local code injection issue: Chrome. The bug is described here [0] and was closed as WontFix because "if your machine is compromised, it's beyond the scope of anything Chrome can do about it".
Even if you don't use Chrome, you probably have at least a few Electron apps installed; they all suffer from the same issue.
The only logical conclusion is the macOS privacy model, TCC, is doomed. There's always an app that has non-default TCC permissions and is vulnerable to some type of local code injection, and at that point any malicious app can also access those TCC-protected features.
[0] https://crbug.com/1300121