Zero Day Initiative Blog

Because UNIX security model ¯\_(ツ)_/¯ Pretty much every modern programming environment involves running arbitrary third party code as "you", with access to all of ~/ and whatnot. How would you solve that on a package manager level? Static analysis? It's really difficult to make an analyzer that wouldn't be trivially defeated by obfuscation, and wouldn't at the same time have false positives all the time. Sandboxing at the language runtime (in this case node) level? Theoretically a nice idea, but difficult to implement securely. Java has been trying. Besides the fact that practically no one uses it to isolate third party libraries in server/desktop apps, there were some serious vulnerabilities: https://www.thezdi.com/blog/2018/4/25/when-java-throws-you-a-lemon-mak… An OS level capability-based security model like Capsicum/CloudABI is a better solution, but again — doesn't fit that well with libraries. In Capsicum, you need a process boundary to isolate code, and that implies IPC, which is a thing developers absolutely love to use all the time… (not). Here's an awesome research idea that I sadly do not have the time to work on: make a programming environment where all shared libraries are actually servers built as CloudABI executables, library calls are actually some super-fast RPC (with e.g. Cap'n Proto to avoid spending time on serialization, and of course fd passing for capabilities), and everything is handled as transparently…

This is true, although if I look at my old company - they've migrated to Exchange Online and run onprem Exchange servers to support the hybrid environment. But they don't need to publish those servers to the Internet. Many of these orgs should have learned this after [CVE-2020-0688](https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execut… If it's a hybrid environment, it doesn't need to be exposed. That doesn't solve MS problem of coming up with a better solution though

> The binary TDDP protocol merits further research since it is available on a broad range of TP-Link devices. The tdpServer binary regularly get abused to root TP-link devices for Pwn2Own Tokyo : https://www.thezdi.com/blog/2020/4/6/exploiting-the-tp-link-archer-c7-… Also : - https://mjg59.dreamwidth.org/51672.html - https://www.coresecurity.com/core-labs/advisories/tp-link-tddp-multipl… - https://medium.com/@CoreSecurity/a-story-about-tp-link-device-debug-pr…

IIRC there have been similar issues in the past with other hardware (what comes to mind are "smart" items such as locks, wifi cameras, etc.). As for software, there was an issue earlier this year with Exchange Server failing to generate unique keys [0] (prev. discussion[1]). [0]: https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execut… [1]: https://news.ycombinator.com/item?id=22424260

eBPF has had many exploits, the most recent of which was just a few months ago: https://www.thezdi.com/blog/2020/4/8/cve-2020-8835-linux-kernel-privil… Original BPF was safe by design (no verifier needed) but slow and far more restrictive, and even then there were exploits over the years. When eBPF and then eBPF JIT became a thing it was entirely predictable what would happen.

Not if done correctly and you take security seriously. Most auto manufacturers outsource software development and engineering. Tesla also offer pretty good bounties every year on PWN2OWN: https://www.zdnet.com/article/tesla-car-hacked-at-pwn2own-contest/ https://www.thezdi.com/blog/2020/1/8/pwn2own-returns-to-vancouver-for-…

That seems to be this one: https://www.thezdi.com/blog/2019/2/28/finding-unicorns-when-the-c-comp… It's a straightforward miscompilation. I'm not sure why they even classify it as a vulnerability. From Microsoft, per the article: "The said vulnerability is about downloading and running untrusted code, which has always existed in all releases prior VS2017 Update 9 that supported lambdas. The scenario is not common coding practice and considering we've always had this in all our prior releases and have not seen any evidences of exploit it would not make sense to port the change as hotfix from 15.9 to prior VS releases." In other words, it's never made into a product in an exploitable way. I'd just call this a miscompilation.