Java’s ECDSA for Nought, Writing a Kernel RCE, Okta’s Conclusion, Log4Shell Hot Patch – ASW #194

A vuln worth covering twice in the show notes! John noted the flaw -- the r and s components of an ECDSA signature should be greater than or equal to one. But there's also an unfortunate aspect of this story about why the flaw came about. Java developers decided to rewrite a C++ implementation of the algorithm into Java, which in theory is a reasonable decision to reduce the attack surface of memory-unsafe code and have Java functions based on Java implementations. Yet the re-implementation committed basic errors and apparently skipped simple test cases that would have caught this flaw. If you're curious about more robust test suites for cryptographic implementations of various algorithms, check out https://github.com/google/wycheproof.

This article goes into the longer-read category, but also the categories of very approachable and well-written overview of creating an RCE for a Linux kernel flaw in TIPC (we covered this briefly back in episode 173 at https://securityweekly.com/asw173). The article walks through the security boundaries that an exploit developer must overcome (hint: kernel ASLR has been relatively effective at increasing attacker cost) and the nuances of shifting from the context of gaining control of an interrupt (think network traffic) to gaining control of a process (think user space). Overall, it's a useful insight into Linux exploitation techniques as well as examples of how kernel hardening and compiler features can (or at least should) make those attacks more difficult.

All the noise and attention on the Okta breach comes down to a brief compromise of a single workstation from which the attacker was able to see some interesting information, but unable to leverage that access into something more consequential. The saga has been a good lesson (or probably a tough lesson from Okta's perspective), about transparency and communicating risk. This final update removes a lot of ambiguity and lays out some actionable steps the company will take -- steps that easily generalize to any appsec team.

"Just apply the patch" is security advice that becomes difficult when the affected software is pervasive, possibly unsupported, and in systems with ambiguous ownership. This confluence of unfortunate events sometimes leads to hot patches -- mitigations that modify a configuration or process execution in a way that addresses a vuln without applying the official patch (or when an official patch isn't available). Here's an example of when that approach introduces more security headaches than it solves.

I'd love to see more details or case studies in this article about strategically going after classes of vulns rather than just fixing vulns as they appear. It also fits into the idea of what a bug bounty's engineering costs might look like and how to demonstrate the impact of that investment.

It's been quite a long time since we covered an article related to appsec and aviation. That drought is over with this article from IOActive that goes into detail on analyzing an avionics system. While the technical detail may be mostly of interest to those wanting to learn about reverse engineering, the white paper has a good structure of analysis and attacker-minded thinking that may appeal to anyone who has to present their findings -- in any domain of expertise -- to a technical audience.

Noting this article very briefly as a chance to talk about the challenges of deprecating APIs, as well as this quote that has sad implications for the appsec future of legacy systems -- "Microsoft will provide an out-of-band, unsupported install package for users that still need to connect to old factory machinery, medical gear, consumer NAS and other equipment that still requires SMB1, however."

This is starting to turn into the year of Java insecurities... In a nutshell, the Java team rewrote some of the crypto code in native Java from it's previous C++. They failed to do a critical check on the signature (r,s): If r and s are set to 0, basically any message signed with that signature is considered valid - for any public key.

...in which Gareth Heyes figures out how to use that little highlight around an active button in your browser for XSS. And the SVG animate example? *chefs kiss*