BlackBerry’s BadAlloc, Glibc’s NULL, Backtick Command Injection, & ProxyLogon Details – ASW #163

It's no surprise that an operating system with decades of backwards compatibility has a huge attack surface. Microsoft developed the AppContainer as a sandbox for legacy apps. It requires explicit allow lists of resources for a process to access. The folks at Google's Project Zero identified a weakness in the AppContainer rule sets that would allow for elevation of privilege (EoP). However, the risk associated with the flaw was such that Microsoft initially chose not to address it and followup from Project Zero notes that the flaw requires very specific scenarios. What's good to see in this kind of vuln analysis is a deep dive into the technology that highlights the basics of the technology and where more fundamental issues might be in its architecture. Check out this background at https://googleprojectzero.blogspot.com/2021/08/understanding-network-access-windows-app.html

This is the kind of throw-back vuln that has an underlying design pattern that needs to be thrown out. The exploit works by smuggling backticks into a "Name" field of a SAML configuration page, which get passed to an snprintf() function for some command-line concatenation. Since backticks have a special semantic meaning in a command shell, it gives an attacker command execution. Ultimately, the vulnerable function was trying to copy a file from one destination to another -- something that could be more securely handled with functions dedicated to copying files than building up a command line for "cp".

The ProxyLogon technical details are out now! We first covered this back in episode 142. This write-up goes into nice detail about the attack surface of Exchange Server and some of the thought process in searching for vulns. If you enjoy technical write-ups you'll like it. If you enjoy running your own mail server, maybe think again about doing so -- mail is a critical service with all sorts of threats that the modern choice is to just go with a SaaS provider. Check out episode 142 at https://securityweekly.com/asw142

Most of the technical write-ups we come across are taking apart C code or reverse engineering a binary, so it's extra fun to come across a blog post like this that goes deep into some of the JavaScript implementation behind iCloud authentication in the browser. It touches on Apple's particular implementation of OAuth, cleverly using the PostMessage interface, and bypassing a URL-based security check with the tried-and-true attacker-owned domain in the authority -- in other words, something like https://[email protected]rget/.

Here's the CISA alert for BlackBerry's RTOS that accompanies the article John highlighted for this week. We first noted BadAlloc back in May and how it demonstrated some nice fuzzing at scale coming out of Microsoft. It may not be a surprise that these C-based SDKs and operating systems have memory safety issues, but these are also the kinds of issues that compilers, linters, and the fuzzing techniques used by Microsoft should be finding early on in the development process before these builds go to production. Of course, it'll also be nice to see the day when the implementations shift to different programming languages in order to avoid this class of vulns. Check out episode 149 at https://securityweekly.com/asw149.

Golang already has a popular open source security scanner: Gosec. Even so, it's nice to see a project that expands on static analysis for Go programs. In this case, GoKart improves on taint analysis in order better track input validation issues and therefore reduce false positives while also hoping to find more exploitable vulns, thus reducing false negatives. We're curious what your experience has been with gosec and how you've adopted static analysis into your Go projects. Let us know! Check out the repo at https://github.com/praetorian-inc/gokart

I got a message from a 3d printing monitoring service that I use - The Spaghetti Detective. Almost the very first words? "I screwed up." We all make mistakes - I love the transparency. Hoping to see less marketing in the disclosures, more of this.

Every few years I try to run a CA for internal purposes. I always dislike it. Java is usually involved. Looking forward to giving this offering from GCP a try in the near future. We often need an internal/private CA, but it shouldn't be hard to setup/use.

I'm just going to quote the opening paragraph on this story: "Taiwanese chip designer Realtek is warning of four security vulnerabilities in three software development kits (SDKs) accompanying its WiFi modules, which are used in almost 200 IoT devices made by at least 65 vendors."

When we look at https://blog.tuxcare.com/cve/tuxcare-team-identifies-cve-2021-38604-a-new-vulnerability-in-glibc, we see "While the free() call is immune to NULL pointers being passed to it, pthread_attr_destroy() is not." Also no, not every linux thing needs glibc. mlibc is awesome and should get more use. As an aside - if every time an article reports a CVSS score then has to say what that score means, perhaps there's a problem with CVSS, or how we as an industry describe vulnerabilities?