Anyone know what logging/printing library exploit.py is using in that first embedded video?
Zoom RCE from Pwn2Own 2021
101–110 of 126 posts
Re: Zoom RCE from Pwn2Own 2021
#102Earlier quoted context omitted.
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.
Isn't this a bit like saying most software these days isn't manually built, because they use compilers?
its more like you run a fuzzer and hope it breaks something.
Re: Zoom RCE from Pwn2Own 2021
#103Anyone know what logging/printing library exploit.py is using in that first embedded video?
The colored and animated logging parts are from pwntools (https://docs.pwntools.com/en/stable/).
Re: Zoom RCE from Pwn2Own 2021
#104Re: Zoom RCE from Pwn2Own 2021
#105Earlier 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…
> 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.
Meanwhile we banished Java and Flash from browsers, with JavaScript still leading every pwn2Own contest because these "memory safe" languages are ultimately still implemented by humans paid to prioritize new features instead of security. I still haven't seen a website that absolutely needed multi threading, certainly didn't break anything of note when it had to be disabled as specter mitigation.
Re: Zoom RCE from Pwn2Own 2021
#106Earlier 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…
> 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. Meanwhile we banished Java and Flash from browsers, with JavaScript still leading every pwn2Own contest because these "memory safe" languages are ultimately still implemen…
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.
Re: Zoom RCE from Pwn2Own 2021
#107Earlier quoted context omitted.
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.
Then drop the analogy.
If I install software that was written in C++ on a device I own and it processed untrusted content then I put myself as fairly major risk of all sorts of harm. There are only two resolutions for this problem:
1. No more memory-unsafe languages on security boundaries.
2. Extremely effective sandboxing and process isolation.
#2 has proven very hard. But we know how to do #1. We just need to spend the effort.
Re: Zoom RCE from Pwn2Own 2021
#108Earlier 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…
Your point might make sense for web facing software because programs where lives are actually at stake are written in Ada or a subset of C with rigorous static analysis and engineering processes. Now, it can't be denied that C and C++ are weak from a security perspective and that they should be avoided for network software as much as possible. But the problem with your take is the subtle implication that Rust is "saf…
> 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.
Re: Zoom RCE from Pwn2Own 2021
#109Earlier quoted context omitted.
Did they edit their comment? I saw nothing about Rust in it
No, that is why I wrote "subtle implication" there. Unfortunately on online forums, the term "memory-safety" (which is a well-defined term in computer science), is nowadays almost always used in contexts of Rust evangelism. I would be very surprised if the GP's actual intent was that Zoom must have been written in a garbage collected language and not Rust. The wider context of this discussion at all is that whether m…
> 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.
If you don't need the performance characteristics or OS-level interaction offered by systems languages, then please use an interpreted language. Please please please please please. But there aren't a lot of new projects started in C or C++ that fit this, since people have known for decades that using something else will be better if you don't need the specific features offered by systems languages.
> The wider context of this discussion at all is that whether memory-unsafe languages (ie., C/C++) must be made illegal with the implicit suggestion that Rust must be pushed as the alternative.
I never said this and it would be wildly ridiculous for me to suggest this. I mention Rust elsewhere to describe poorly written legislation, not to say that legislation must demand that everybody bow down at the feat of the Rust community and donate their first born child to the borrow checker.
You are reading way too much into my post.
Re: Zoom RCE from Pwn2Own 2021
#110Earlier quoted context omitted.
You sound paranoid.
That is a neat attempt at making it appear like I am somehow deluded and am imagining Rust evangelism. The person I replied to made a comment down thread that literally states that Rust must be given a free pass despite `unsafe` blocks on the face of such legislation against unsafe languages. Sounds completely illogical to me. https://news.ycombinator.com/item?id=28343526
You can disable security features in java as well. Elsewhere, you mention GCed languages as an alternative. Would it be appropriate for me to assume that you are a java evangelist and then criticize you for not considering the harm that can be caused by turning off stack inspection? That's what you are doing to me.
The fact that the default is safe matters. It matters a lot. Heck, if you want to use C++ with a sound static analysis tool then I'd support doing that and I'd hope that legislation would support that too - but I think you'd be working 10x as hard as really necessary.