In addition to what others have mentioned - you could probably find the session keys in ram - but for a system without debug knobs, injecting your own certificate authority is probably easier.

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

With DNS one can avoid having to use the firewall for redirection

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)

The HTTP and XMPP traffic is encrypted using TLS. The proxies were used to decrypt, log and re-encrypt this traffic in real-time.

Not entirely sure if this I'm understanding this correctly (since it doesn't really make sense to me), but this is what they wrote almost at the end:

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

The article goes into detail on how much trial and error effort it goes into making such an exploit chain - approximately two months work each for two people. Even for other people who have the required skills, making such a time investment - with no certainty of succes or reward - is a big barrier. Perhaps the math works out differently for blackhats as the payoff is larger and perhaps more certain if they do get to a working exploit.

This is generally through the use of (often custom) analyzers. I would wager, though I have little empirical evidence, that most non-trivial zero days of large software like this are not strictly manually discovered.

I just decline Zoom meetings while politely saying “our cyber security division does not allow us to use Zoom.” Then send an alternative invitation. So far it seems to work just fine.

FWIW it's possible to run Zoom in a web browser, but they make it annoying. https://techcrunch.com/2020/03/20/psa-yes-you-can-join-a-zoo...

i run the snap Zoom on Ubuntu

The colored and animated logging parts are from pwntools (https://docs.pwntools.com/en/stable/).

Just because there's heap grooming involved doesn't mean it's unreliable. Exploits that use heap grooming can often be ~100% reliable.

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.

Would the exploit have been possible without this, though? Possibly but it would have been that much harder to accomplish. I think it's a fair if overdone observation that C is a bad language to use if you want to minimize the incidence of RCEs.

Why does it matter how reliable it is? What matters is that it's possible. If it breaks with an update, the technique can be pretty easily adapted to work again.

There is a PR (or whatever they call them) to add the rust toolchain into chromium’s build infrastructure. The link is in my submission history. Didn’t get any traction on here, but fingers crossed!

That's the last thing I want to hear from the authoritarian industry who also writes user-hostile software, embraces DRM, and is deathly scared of users having control over their general-purpose computers.

Insecurity is freedom. (Don't believe me? How is jailbreaking and rooting accomplished?)

Imagine thinking we should, literally, police language.

Last I checked you didn’t have to install anything. I’m not sure about more advanced usage like screen sharing or how many timing options their are, but for generic “see me, see you” it works fine in the browser.

In my personal opinion, open source native app > web app > closed source native app

There's a difference between Android native bugs and forgoing protection provided by browser on desktop instead of relying on Native apps.

That’s why I keep it quarantined to my work computer. If friends/family want to use it, I use it on there.

lol we use Zoom for most of our meetings and I always used the web app, without any issues.

Browser sandboxing is more battle tested, and probably a lot more researched, and with more fuzzing performed on it.

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.

Browser vendors push sandboxing technology and everything else kinda follows behind by years. It's unlikely you'll find a more powerful sandboxing approach than what's in Chrome.

I’d assume teleconferencing. And tbh, I’m not sure I disagree. WebRTC has some issues and certainly isn’t the greatest, but it feels like every teleconferencing solution goes through basically the same problems over and over again. I know some swear up and down that Zoom is better than any WebRTC solution and I am going to have to hard disagree, it has a larger featureset than say, Google Meet, but I don’t know anyone in my current org that isn’t disappointed in Zoom’s reliability or security issues. In my case the security issues I’ve personally heard of are less serious (mostly random people somehow getting into meetings — never witnessed that with Meet or anything else for that matter) but to be honest, I have zero trust in Zoom. If I could run it with less privileges than a browser tab I would.

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.

I personally don't think that the IEEE would have any capability of really shifting the industry. It isn't like IEEE guidance for privacy preserving programs really moved the needle. You needed legislation like GDPR to do that (and even then it remains incomplete). Ultimately, adopting memory-safe languages for systems programming is going to be very expensive. You need more than just recommendations to make that happen.

I do think there is risk with legislation binding developers too much or forcing them into suboptimal approaches if things aren't written well. One could imagine legislation that does not permit the use of Rust because of the presence of `unsafe`, but that would be a terrible misstep.

> Would you suggest that they receive training which allows them to think of software as infrastructure?

I don't know. I don't know enough about detailed practices in fields like civil engineering to have any idea what would translate. I'm not convinced that "teach every software engineer to use model checking for everything they ever write" is going to be a winning approach. This is why memory safe languages are so valuable. You don't need to teach engineers new techniques. You just outright eliminate an entire class of vulnerability that has persisted despite efforts to eliminate it with other means.

I worked on V8 for almost 7 years. It being written in C++ is a cause of a large number of issues. And even larger number of issues is caused by its absolutely massive complexity and the low-level nature of what it does, particularly the object model and the JIT compiler's complex optimizations. Low-level is really dangerous and error prone.

I think every VM should be rewritten in a memory-safe, GC'd language. While there are bugs at the meta-level (i.e. the compiler IR and object representation), making the runtime code itself memory-safe should be table stakes for even talking about a trustworthy implementation.

Memory safety is not a security panacea and you should run far away from anybody who says that it is. What I am arguing is that it is table stakes.

Browsers also have a uniquely difficult security challenge in that they, by design, execute untrusted code and compete based on the performance of their js engines.

Programs written in memory-unsafe languages are riddled with RCE vulns. This is true even for software written by companies that hire the very best security engineers in the world. The consequences of such software that processes untrusted input is more than mere annoyance. This sort of behavior is the root of RATs operated by both criminals and oppressive states. It does not matter if your program is intended for something as seemingly non-critical as text messaging - it will still be used to cause terrible harm.

I do not think that the lock is a reasonable comparison here, because exploitation of software scales so so so much more effectively than picking locks. One exploit easily scales to millions of devices. So the harm caused by vulnerable software has a much higher ceiling than the harm caused by a weak lock.

Part of the problem is that the actual impact of vulnerabilities in the program is often divorced from it's actual purpose. A simple TODO list that allows RCE is one example. It also has a wide variety of impact based on the user - is it just installed on a random personal computer? Or is it on a hospital server?

I don't know that it's particularly possible for a developer to truly understand all the possible impacts of an error in their program.

I'm not sure what the best way to handle that uncertainty is. Assuming all failures are critical would do the job, but certainly isn't free. However doing something like is suggested here - somehow requiring safer languages - might be a decent middle ground. The cost of using languages more built-in safety features is often not very high. Actually often such languages claim that those features make them cheaper to use.

> But the problem with your take is the subtle implication that Rust is "safe" (not just memory-safe) when in fact there is no empirical evidence or track record of Rust being successfully used in anything remotely mission-critical.

An application built from the ground up in a language like Rust is going to have fewer vulnerabilities than the same application built in C++. I say this as a person who loves C++ and is intimately familiar with the state of the art of securing C++ applications. I am not proposing an immediate rewrite of everything, though I do personally believe that the "well a rewrite will just introduce more vulns" concern is overblown. I expect papers in ICSE in the not to distant future to be able to validate one of our views.

Rust is not flawless, not even close. There are other alternatives and there can even be new languages in the future, but it has the most mindshare and it is an alternative today. For many years, people would simply say that there was nothing that could compete with C and C++ for systems programming. Rust very nearly handles all of the common use cases. But... I didn't even really mention Rust in my post so I think it is especially difficult to call me an evangelist for it.

Like it or not, ideas in research languages take ages to filter into real world ecosystems. My PhD is in the intersection of static analysis and security. I love this research. But the honest truth is that waiting for MSR to produce the path forward is not a winning strategy. Languages need ecosystems and I think it is more likely that the future will come from industry than directly from academia.

> the subtle implication that Rust is "safe" (not just memory-safe)

It's not a "subtle implication" it's a fact that Rust is also data race free and thus concurrency safe in the same sense you're attributing to Verona, although for very different reasons - it can't introduce data races. Verona, unlike Rust, is not in fact a production system, it's an academic toy for pondering new ways to approach concurrency. Perhaps ten years from now its findings will influence future Rust development.

It's certainly interesting that we're still at the place where people are going, "This is only better if you can't afford GC", when even Java is markedly less safe than Rust since it doesn't prevent data races. (Yes there is ConcurrentModificationException for this, no Java doesn't promise to raise this Exception, and if it happens that might already be too late).

Did they edit their comment? I saw nothing about Rust in it