I have setup wireshark for troubleshooting. That's about it. What's the role of proxies, modified DNS records etc. in this setup? How can I duplicate this?
Thanks.
For stuff using nss(Firefox)/openssl/gnutls - you can usually just ask nicely for a copy:
> The key log file is a text file generated by applications such as Firefox, Chrome and curl when the SSLKEYLOGFILE environment variable is set. To be precise, their underlying library (NSS, OpenSSL or boringssl) writes the required per-session secrets to a file. This file can subsequently be configured in Wireshark
https://wiki.wireshark.org/TLS#TLS_Decryption
https://gnutls.org/manual/html_node/Debugging-and-auditing.h...
sslsplit documentation actually suggests DNS as an alternative to using firewall
Theres a number of easy-to-use UNIX firewalls. Not sure about Windows
Proxies allow easy inspection of HTTP traffic, among other things. Arguably sslsplit is itself a proxy, specifically a forward proxy
There are many ways to monitor HTTP traffic. More than one way to do it
Why doesnt Zoom use certificate pinning
(I avoid using sites/apps that force use of third-party controlled pinned certificates. What are they trying to hide from the user)
> Anything we did differently could influence the heap layout. For example, we noticed that adding network interception could have some effect on how network requests were allocated, changing the heap layout.
This is what I was looking for. Fundamental bug was an overflow of statically-allocated buffer leading to heap corruption.
We gotta get off memory-unsafe languages.
You read this whole post and that's what you got? Just the fact that this includes a heap grooming step should be pretty telling that it's not very reliable and that it can easily be broken (it probably won't work if you try it after the next Win10 update).
I mean, yeah, sure, buffer overflows are bad, but this is an extremely sophisticated attack that relies on like a zillion moving pieces, of which "memory-unsafe languages" are basically a footnote. Props to the dedication and expertise of the security researchers.
Our POC for Sigred required lots of heap grooming but it was extremely reliable. https://www.graplsecurity.com/post/anatomy-of-an-exploit-rce...
The overflow was hardly a footnote either, it's the primary bug being exploited here.
I know the Chromium team was considering switching to Rust too, but who knows if that's ever going to happen. IIRC Chromium has more LOC than the linux kernel.
Insecurity is freedom. (Don't believe me? How is jailbreaking and rooting accomplished?)
[0] https://support.zoom.us/hc/en-us/articles/360027397692-Deskt...
This could just be a coincidence, but I suspect it's not. For all of its faults, Zoom calls are just much better than all of the other mainstream solutions I've tried, particularly with large groups.
Nothing to do with native or not; and pushing everything to a web-browser makes a really complicated bit of software with weird quirks and potential hidden bugs. Yes it’s more tested, but when your code paths are literally infinite- “more eyes” isn’t going to help.
pick your poison
I know that at least X11 is not sandboxed with snap/flatpak/etc., and there is no sandbox for macOS/Windows Zoom client, so using web client is infinitely more isolated.
What is exactly “for this”?
I’d really prefer a world where people don’t have to deeply distrust software, but still adhere to principle of least privilege where it is reasonable to do so. I feel like if I have to install software natively, it better be software with a decent track record from a trustworthy team. However we’re really at a worst of both worlds situation with Zoom. I don’t trust it at all, and it gets a ton of privileges that are only checked in the sense that there might be some scrutiny from researchers.
Not saying I never had issues with the WebRTC solutions, but honestly, at worst I just found myself refreshing the tab and going on my way. Meanwhile I’ve been warned against even trying Zoom for Linux as apparently it makes the old Skype for Linux look like a solid product.