Log4Shell, Mozilla’s BigFix & New Sandbox, Rust in Linux Kernel, Path Traversal in Go – ASW #177

Yep, we have to talk about the log4j flaw and the glorious confluence of design decisions that has made last several days very busy for all the folks in infosec and IT. There are tons of angles to cover on this one. We'll touch on several like: - Mixing data and code: The vuln stems from the log4j Lookups feature that provides "a way to add values to the Log4j configuration at arbitrary places". Slightly rephrased, adding user-influenced values to arbitrary places that control an app's execution basically described arbitrary and remote command execution. - Secure defaults: How many folks were surprised their app supported the macro substitution and JNDI connections from their logging systems? How many needed such a feature? How many would ever need such a feature? - Deprecating features: What are good strategies moving away from insecure designs and features? Windows in particular has been hampered by an adherence to backwards compatibility. - Network controls: How many networks block egress traffic from production systems by default? Or at least proxy them through a controlled, audited centralized server? How many networks block DNS lookups, too? - SBOMs: How much more efficient would a response be if you had details about the dependencies and libraries in the third-party apps and devices on your network? This isn't about the code you build and the SCA tools checking that code's dependency graph; it's about visibility into all the other apps and devices sitting on your network. - Security & surprises: Fixing this and then worrying about the next 0-day isn't a strategy. No one should be trying to create a BugOps team. There are basic practices that can make these kinds of events an audit exercise rather than a forensic scramble. Want to be part of the solution for securing open source software like this? Check out security projects from the OpenSSF (https://openssf.org) and the LXF Platform (https://lfx.linuxfoundation.org). They'll benefit from funding, participation, and support. A few more resources to check out: - https://logging.apache.org/log4j/2.x/manual/lookups.html - https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/ - https://twitter.com/NSA_CSDirector/status/1469305071116636167?s=20 (mostly because it's funny to see all the places where this vuln has appeared) - https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf (an overview of JNDI and LDAP as attack vectors from 2016) - https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/ (resources and information curated by NCC Group)

Sure, it's a title that can apply to just about any vuln we've covered on the show. This writeup talks about how Mozilla implemented a bunch of recommended, effective security practices and yet a bug still slipped through. What's interesting is that a slightly different fuzzing strategy found what's (in retrospect) a relatively straightforward vuln. Even so, good software design meant this particular flaw didn't end up on the "CVSS 10 out of 10" list in news stories. It's a good lesson that maturity in SDLC practices doesn't mean all the bugs and vulns will go away, but it can mean that they're less common and less impactful. Read more about it at - https://www.mozilla.org/en-US/security/advisories/mfsa2021-51/ - https://www.zdnet.com/article/mozilla-properly-fuzzed-nss-and-still-ended-up-with-a-simple-memory-corruption-hole/

This type of flaw seems simple when you look at how it's exploited -- change a user ID or a transaction ID in order to execute actions against another user's account. It's the kind of reminder that as architectures change, security threats remain the same. A key step is not just understanding what can go wrong with default open authorization checks, but in designing APIs so that complex properties like authorization can be represented, enforced, and audited throughout the many microservices that might lay behind an API. We also talked about API security and the need for careful attention to authorization in GraphQL-backed queries in episode 172. Check it out at https://securityweekly.com/asw172 Check out the research at https://salt.security/blog/api-threat-research-graphql-authorization-flaws-in-financial-technology-platform

Fine. Java and log4j get all the attention this week, but I'm not going to let a path traversal go by without a proper mention. This is also a chance to reinforce the theme that, while memory safe languages address an inordinately large attack class, languages like Java (ok, may not too surprising...) and Go may have equally impactful vulns that have nothing to do with memory safety, buffers, stacks, or heaps. That doesn't mean we're in a nihilistic land where we should abandon all programming languages -- it just means we have to continue to work on language primitives that make introducing these types of flaws difficult and language analysis tools that can effectively identify them.

How fortuitous to have an article that's taking a good self-evaluation of the security profession during the same week the security profession is dealing with a flaw across a massive amount of apps and services. When there's time to take a postmortem on log4shell, how would it compare with how orgs reacted to Shellshock and Heartbleed before it? Do we have effective recommendations on basic practices that can minimize the surprise from these kinds of vulns and maximize the response to them? Do we have the practices and tooling to follow through on those recommendations? Plus, the security profession encompasses a varied amount of roles and domains of expertise. This article presents a way to better think about how security could both reflect something that's everyone's responsibility as well as considering paths towards making security practices more grounded in scientific methods and standardized practices.

Taking a guided tour through cryptography analysis and common flaws is a great way to understand these concepts without needing a deep experience in math, programming, crypto, or a good memory for acronyms.

Solana's one of the 10000 distributed finance platforms out there, with US$2.6B total value. A bug was found where a user could deposit n fractional coins, and at the same time withdraw n+1 coins.

A new category of web vulnerabilities, titled "cross-site leaks" leverages an ability to bypass a browser's "Same Origin" policy, designed to prevent this type of thing. Basically by using side-channel (timing) attacks, it's possible to see if a user has, say, used another website or has an account on it.

This is a fairly nerdy link - a source code patch for new functionality in the Linux Kernel. But in particular, this is the patch which would add support for using Rust code in the kernel. This makes it a great example of things to think about, and actions to take, to add Rust to an existing project.