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

71–80 of 126 posts

Re: Zoom RCE from Pwn2Own 2021

#71

Post by UncleMeat »

bagels wrote: post #67
UncleMeat wrote: post #58

Earlier quoted context omitted.

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 don't think comparing software to buildings is always apt. If a building collapses, it's likely that people will die. The consequences of failing software can be mere annoyances depending on the context of its use. Obviously certain industries that use software have much more dire consequences of failure though (eg. large machinery, transport, health care). I think one could come up with all sorts of analogies that…

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.

Re: Zoom RCE from Pwn2Own 2021

#72

Post by UncleMeat »

virtue3 wrote: post #59
UncleMeat wrote: post #58

Earlier quoted context omitted.

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.

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.

Re: Zoom RCE from Pwn2Own 2021

#73

Post by UncleMeat »

gwerbret wrote: post #68
UncleMeat wrote: post #58

Earlier quoted context omitted.

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…

You make a very sound argument about the engineering perspective. Unfortunately, many of the folks writing such software aren't (formally-trained) engineers. Would you suggest that they receive training which allows them to think of software as infrastructure? I'm genuinely curious, not being sarcastic.

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

Re: Zoom RCE from Pwn2Own 2021

#74

Post by foerbert »

bagels wrote: post #67
UncleMeat wrote: post #58

Earlier quoted context omitted.

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 don't think comparing software to buildings is always apt. If a building collapses, it's likely that people will die. The consequences of failing software can be mere annoyances depending on the context of its use. Obviously certain industries that use software have much more dire consequences of failure though (eg. large machinery, transport, health care). I think one could come up with all sorts of analogies that…

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.

Re: Zoom RCE from Pwn2Own 2021

#75

Post by UncleMeat »

userbinator wrote: post #70
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.

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?)

I do not believe it is remotely reasonable to say that our software should be deliberately insecure so that people have the ability to root their own devices. That problem can be solved with other means, without exposing all of our devices to anybody else in the world who can send the same payload.

If I can root my device through an exploit then I am not at the mercy of the company that made the device. But I am now at the mercy of every single criminal or oppressive state that wants to use that exploit to harm me. And given that there is no way to confidently determine which pieces of software do not expose this capability, this cannot be an informed decision made by consumers.

Re: Zoom RCE from Pwn2Own 2021

#76

Post by bagels »

UncleMeat wrote: post #71
bagels wrote: post #67

Earlier quoted context omitted.

I don't think comparing software to buildings is always apt. If a building collapses, it's likely that people will die. The consequences of failing software can be mere annoyances depending on the context of its use. Obviously certain industries that use software have much more dire consequences of failure though (eg. large machinery, transport, health care). I think one could come up with all sorts of analogies that…

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

The point of the lock analogy is to point out the absurdity of analogies here.

Re: Zoom RCE from Pwn2Own 2021

#78

Post by chakkepolja »

rvp-x wrote: post #37
makeworld wrote: post #26

This is why I only run Zoom in Firejail.

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

Yep. I run it in web browser in separate user account made for that purpose.

Re: Zoom RCE from Pwn2Own 2021

#79

Post by nitinreddy88 »

xxpor wrote: post #69
1vuio0pswjnm7 wrote: post #49

Earlier quoted context omitted.

As an employer I would prefer employees not to use the corporate network for personal email. The network exists for business use. As an employee I prefer not to use the corporate network for truly personal email. If I am the employer that responsibly monitors the traffic to and from our network, including TLS traffic, an employee that uses our network for personal use with a surveillance "tech" company service such a…

>As an employer I would prefer employees not to use the corporate network for personal email. The network exists for business use. And as an employee that actually exists in 2021, I'd tell you to get a clue. >As an employee I prefer not to use the corporate network for truly personal email. And that's your preference. If you think everyone shares that preference or even realizes the implications you're delusional. >I…

Probably you might need to re-read your employee agreement. Some of these policies are clearly stated and you signed up for them when you are employeed

Re: Zoom RCE from Pwn2Own 2021

#80

Post by notatoad »

EvanAnderson wrote: post #47
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?

No. Your employer can't MITM your personal email session if you don't trust their MITM proxy's CA.

if your employer controls your work computer, they can set it to trust their MITM CA.

cert pinning means they can't do that unless they're also modifying yoru email client binaries.

Post reply on HN