Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zoom RCE from Pwn2Own 2021

sector7.computest.nl

Post reply on HN
Print view View original

51–60 of 126 posts

Re: Zoom RCE from Pwn2Own 2021

#51

Post by UncleMeat »

titzer wrote: post #43

> This meant that by sending a ResponseKey message with an AES-encrypted element of more than 1024 bytes, it was possible to overflow a heap buffer. 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.

Yup. I wouldn't hate it if it were illegal to write new applications that processed untrusted input in memory-unsafe languages, at least in the not too distant future. The fact that the industry doesn't see this as an urgent need is just embarrassing.

Re: Zoom RCE from Pwn2Own 2021

#52

Post by Silhouette »

PeterisP wrote: post #48
fn-mote wrote: post #45

Earlier quoted context omitted.

Isn't certificate pinning what keeps my employer from MITM'ing my personal email session on their network?

Basic TLS is sufficient to stop your employer from MITM'ing your personal email session as long as you control what certificates your machine trust. Certificate pinning is what protects the main sites (who use pinning) from an advanced attacker or a rogue government who are able get a proper CA to issue fake certificates.

Basic TLS is sufficient to stop your employer from MITM'ing your personal email session as long as you control what certificates your machine trust.

Which, on almost any employer-issued device on a large corporate network today, you won't.

Personal stuff goes on personal devices with personal connectivity and uses personal accounts with personal security. Work stuff goes on work devices with work connectivity and uses work accounts with work security. Contaminating either with the other is just a recipe for bad things happening, often for both the employer and the employee.

Re: Zoom RCE from Pwn2Own 2021

#53

Post by junon »

UncleMeat wrote: post #51
titzer wrote: post #43

> This meant that by sending a ResponseKey message with an AES-encrypted element of more than 1024 bytes, it was possible to overflow a heap buffer. 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.

Yup. I wouldn't hate it if it were illegal to write new applications that processed untrusted input in memory-unsafe languages, at least in the not too distant future. The fact that the industry doesn't see this as an urgent need is just embarrassing.

Imagine thinking we should, literally, police language.

Re: Zoom RCE from Pwn2Own 2021

#54

Post by junon »

mvanaltvorst wrote: post #39

It blows my mind that there are people who manage to find exploit chains like these, amazing job!

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.

Re: Zoom RCE from Pwn2Own 2021

#55

Post by dvt »

titzer wrote: post #43

> This meant that by sending a ResponseKey message with an AES-encrypted element of more than 1024 bytes, it was possible to overflow a heap buffer. 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.

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

Re: Zoom RCE from Pwn2Own 2021

#57

Post by PeterisP »

mvanaltvorst wrote: post #39

It blows my mind that there are people who manage to find exploit chains like these, amazing job!

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.

Re: Zoom RCE from Pwn2Own 2021

#58

Post by UncleMeat »

junon wrote: post #53
UncleMeat wrote: post #51

Earlier quoted context omitted.

Yup. I wouldn't hate it if it were illegal to write new applications that processed untrusted input in memory-unsafe languages, at least in the not too distant future. The fact that the industry doesn't see this as an urgent need is just embarrassing.

Imagine thinking we should, literally, police language.

Imagine thinking we should, literally, police engineering techniques.

If you build a bridge then you are expected to use techniques and systems that provide at least some degree of planned safety for the users of that bridge. It is virtually impossible to write a C++ program of any meaningful complexity that processes untrusted data in an unsandboxed environment that does not expose the owner of the device running that program to harm. To say otherwise is to ignore decades of observation.

Every single person who starts writing a new application in a memory-unsafe language that will deal with untrusted inputs is declaring up front that they are willing to tolerate the inevitable vulnerabilities and exploits caused by that decision.

I think it is very important that our industry develops a path to getting all such programs off of unsafe languages, since it is very clear that techniques like testing, fuzzing, and audits are not sufficient to actually produce safe programs.

Re: Zoom RCE from Pwn2Own 2021

#59

Post by virtue3 »

UncleMeat wrote: post #58
junon wrote: post #53

Earlier quoted context omitted.

Imagine thinking we should, literally, police language.

Imagine thinking we should, literally, police engineering techniques. If you build a bridge then you are expected to use techniques and systems that provide at least some degree of planned safety for the users of that bridge. It is virtually impossible to write a C++ program of any meaningful complexity that processes untrusted data in an unsandboxed environment that does not expose the owner of the device running th…

I initially disagreed with your viewpoint and after reading your response you've actually changed my mind.

My only real gripe is I would prefer it came from the IEEE or something and not really from some government agency; or worse -> oracle or someone trying to get everyone to use java/their stuff.

Re: Zoom RCE from Pwn2Own 2021

#60

Post by asdfasgasdgasdg »

dvt wrote: post #55
titzer wrote: post #43

> This meant that by sending a ResponseKey message with an AES-encrypted element of more than 1024 bytes, it was possible to overflow a heap buffer. 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.

> 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 zill…

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.
Post reply on HN