IndexedDB Leak, Linux Kernel Bug, Zoom Security, SSRF & Allow Lists, Security Courses – ASW #181

Browsers perform more and more sensitive functions and are used to access more and more sensitive data. And while their internal security architectures continue to improve with process isolation and (eventual) adoption of memory-safe languages like Rust, they still rely on security models like the Same Origin Policy. Creators of web standards pay attention to the interaction of new features and the browser's origin, for both security and privacy reasons. But as we all know, secure designs don't always mean secure implementations. All that lead up is to say, here's an example of an inference attack against the IndexedDB API in Safari that would enable someone to obtain a user's identity information or correlate a user's identity information that might be stored within the IndexedDB. This kind of cross-origin behavior is exactly what the standards want to avoid. Additional resources - https://github.com/fingerprintjs/blog-indexeddb-safari-leaks-demo -- Example of an attack - https://github.com/WebKit/WebKit/commit/f73005ed826014988f8ee447de23927749fb56e5 -- The fix in WebKit (Safari's browsing engine)

Here's the first Linux kernel bug we've covered this year. (It's only January; there'll be plenty more.) It's in code related to filesystem functions and can be leveraged into a local privilege escalation or container escape. One interesting aspect about the flaw is how the vulnerable code is at once so simple and so subtle. It's in a conditional statement that's doing integer arithmetic: if (len > PAGE_SIZE - 2 - size) With all the code review practices we have and all the integer sanitizers, compiler warnings, and SAST tools, this is still the kind of bug that gets past those solutions and doesn't get noticed for a while -- it looks like over two years in this case. It's also interesting that the fix is so simple; change the calculation to "size + len + 2 > PAGE_SIZE". Which from a style perspective also looks cleaner. I'd prefer to have all the arithmetic on the side with the variables and compare to the constant -- but that would have been purely a stylistic choice based on preference as opposed to insight into potentially vulnerable code. Unfortunately, we can't rely on luck to create secure code. Read the disclosure, which has links to the original insecure commit and the fix, at https://seclists.org/oss-sec/2022/q1/54

Another great write up from Project Zero that looks back on vulns and vuln analysis in Zoom. It highlights a vuln in the Windows client revealed in 2021's Pwn2Own competition as well as referencing analysis with tools like AFL (for fuzzing) and Frida (for reverse engineering). Two items that stood out were (1) a lack of ASLR and (2) having to spend money in order to access and research some of the proprietary formats Zoom uses. The ASLR feels like a simple oversight and, fortunately, looks like it was easily addressed. The closed nature of the protocols in use is a more complex problem. Companies can innovate and choose their architectures, but doing so can impede security research.

While the target of the vuln may not be too common, the nature of the vuln is worth reading about because URL composition and handling is very common. The SSRF in this case stems from how the app builds a URL and compares it against allow lists. An attacker can add a "@" symbol to the path, which turns the origin into an authority section and lets the attacker influence the origin with their own value inside the path itself. It's not a new attack -- we've seen plenty of examples over the years of payloads along the lines of https://[email protected]/rest of path" -- but that doesn't make it less useful or clever. This is a nice write up that shows how even security recommendations like using allow lists to protect against SSRF attacks required careful scrutiny to make sure they're implemented correctly. If there's a recurring theme in this episode's news, it's the unfortunate chasm between secure design and insecure implementation.

Last year we touched on security-oriented courses at the college level with a few guests and a few of the news segments. It's an area we'd love to highlight more, so send us good examples you have of courses and content that we should share. This article is a small one, but it links to a useful book (Security Engineering) and two lectures (so far). If you're on the building or DevOps side of appsec or want to get into that discipline, check it out.

We're covering another article from Phil Venables this week (and likely will again since this is part 1 of a series). The article helps set strategic thinking for setting the vision and execution of a successful security program. A few items that speak directly to appsec are programs that address these areas: - Mitigates whole classes of attacks - Eliminates sets of pain - Reduces risk from configuration errors - Web Proxy Default Deny

One reason to look back on two decades of shifting towards more secure applications, aka trustworthy computing, is to examine what approaches seemed to work and which ones didn't. Microsoft put a lot of effort into developer eduction, added compiler options to harden binaries, and rearchitected software like IIS. If there are mixed results in the Windows ecosystem, it's helpful to try and understand if that's because solutions weren't adopted, couldn't be adopted because of compatibility reasons, or the solutions weren't effective. Another reason to look back is to give us a reference of where to look ahead. We've seen messy security throughout Android's lifetime, Chrome and Safari each have critical 0days every month or so, and cloud service providers have had their own security missteps and insecure defaults.

The HTTP/1.1 spec came out in January 1997. Noting it here more as a curiosity and to mark the occasion. Although, if you're looking into fuzzers or in search of the next HTTP Request Smuggling style of flaw, going back to the protocol's standards and exploring its edge cases and assumptions can often lead to interesting discoveries. Maybe another appsec presentation is just waiting on someone to dive into a dusty corner that's been implemented for ages, but rarely used. Having specs on hand are also useful when you want to go through exhaustive header manipulation for payloads like the JNDI strings for log4j. They can also be fun to read in retrospect. Check out the "Security Considerations" section 15.6, which notes: "HTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords, encryption keys, etc.), and SHOULD be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources. We very strongly recommend that a convenient interface be provided for the user to control dissemination of such information, and that designers and implementers be particularly careful in this area. History shows that errors in this area are often both serious security and/or privacy problems, and often generate highly adverse publicity for the implementer's company." Indeed, even the spec describes why organizations must take security seriously. With luck, that phrase will be used more often in the design and implementation stages as opposed to the familiar opening to far too many breach notifications. The spec is further updated by https://datatracker.ietf.org/doc/html/rfc2616, which in turn has links to additional updates and errata.