Eric Allard – Chief Technology Officer at SOOS

Eric Allard is on a mission to make software safer for everyone. As Chief Technology Officer at SOOS, Eric and his team are breaking down barriers and making it easy and affordable to identify and remediate software vulnerabilities early in the software development life-cycle. In a field crowded with convoluted pricing and cumbersome solutions, SOOS offers a straightforward pricing model and easy workflow integration.

Eric brings more than fifteen years of tech and entrepreneurial leadership to the SOOS team. Trained as a software engineer, he soon realized his true passion is anticipating customer needs and bringing solutions to market. He loves building and leading teams, and is known for both his big-picture strategic skills and his eye for detail. Eric’s previous roles include start-up founder, V.P. of Research and Development for MyWebGrocer, and stay-at-home dad.

Eric is Champlain College alumnus and a lifelong Vermonter. He is married and has two young children. In his freetime, he enjoys hiking, jack jumping, and photographing Vermont’s landscape.

John Kinsella

Co-founder & CTO at Cysense

Mike Shema

Security Partner at Square

John Kinsella

Co-founder & CTO at Cysense

1. Security’s lifecycle isn’t the developers lifecycle –
2. How security complexity is being weaponized –
3. 15 year old bug found in PHP’s PEAR –
4. Zyxel(!) releases patches for firewalls – This looks very much like a vulnerability that was just patched in Sophos and Sonicwall devices… ????

Mike Shema

Security Partner at Square

1. FORCEDENTRY: Sandbox Escape – The biggest takeaway of this article is how attackers leveraged a series of logic bugs to avoid the security boundaries and controls created by Apple’s “BlastDoor” sandbox for iMessage. This doesn’t mean that sandbox and hardening was ineffective — that design addressed many previous attack techniques. What it does show is that even sandboxes will fail against clever misuse of language capabilities.

   If you’re really into iOS security, check out the deep dive on Objective-C linked to in the article: https://blog.chichou.me/2021/01/16/see-no-eval-runtime-code-execution-objc/

   Check out our discussion of BlastDoor and links to additional resources from episode 166 at https://securityweekly.com/asw166/

2. Spring Framework RCE, Early Announcement – It’s a Java flaw, but not a log4j level of Java flaw. For once, it seems that a default config seems secure. The whole Java ecosystem still has its challenges, though. One of the workarounds includes downgrading to Java 8, which seems like the most unfortunate path to have to go with if that’s the only viable option for your application.
3. Zlib data compressor fixes 17-year-old security bug – patch, errrm, now – We mentioned this briefly last week. Now the flaw has an official CVE — from 2018! An interesting angle on this is the lifetime of a flaw, its discovery, and seeing processes fail such that a patch never makes it into the project. Maybe we should appreciate the impact that CVEs have on tracking and patching security issues.
4. On the Naturalness of Fuzzer-Generated Code – A deep dive into programs most useful to fuzzers for eliciting errors with their targets. It’s not something you’re likely to need in your day-to-day appsec program, but if you’ve been interested in fuzzers and strategies for producing test cases, this paper has some neat ideas, observations about the difference between human-generated programs (chaotic!) and machine-generated ones (predictable!?), and how that makes a difference to successful fuzzing runs.
5. Early Security for Startups – We touch on this topic quite often — where do you start with appsec and what should an early hire or investment focus on.

   Ransomware is good to mention, although I’d characterize it differently. A common outcome may be ransomware, but the attacks typically come from social engineering attacks that then take advantage of over-permissive access to production systems. So instead of focusing on a particular threat (ransomware), focus on deploying FIDO keys to 100% of your company and employing least-privilege access to production systems. That will make social engineering attacks significantly more difficult and minimize the ability of a malicious actor to execute ransomware on a system of consequence.

6. The Kani Rust Verifier – Pushing for memory-safe languages is a great way to address an entire class of flaws. But that doesn’t mean a language or the application that uses such as language is secure — there are plenty of other classes of flaws beyond buffer and heap overflows. It’s cool to see Rust have another security analysis tool available for it (albeit one still in early days).

   The write-up explains what a model check is and why it’s different from other approaches like fuzzing. Be sure to check out the comparison to other approaches for additional tools or techniques you may wish to adopt, or even just to understand what types of issues those other approaches are geared towards identifying: https://model-checking.github.io/kani/tool-comparison.html

7. HTML parser bug triggers Chromium XSS security flaw – Here’s a subtle flaw that comes from a slight mismatch between two HTML parsers within Chromium. In one parser, an iframe’s srcdoc attribute passes through an HTML sanitizer, where the other parser doesn’t send srcdoc through the same parsing workflow. This leads to a flaw that looks like it could become a universal XSS, which is bad news for browsers.

   Read more discussion about the flaw in the Chromium issue tracker at https://bugs.chromium.org/p/chromium/issues/detail?id=1231037

8. PHP bug allows attackers to bypass domain filters, stage DoS attacks against servers – We don’t cover PHP vulns too often. This one stems from PHP’s underlying implementation – C. It’s a classic signed/unsigned integer mismatch from a strlen() function whose input can be influenced by an attacker. It looks like the kind of flaw that code reviews, whether human or automated, should at least be suspicious of. It’s also the type of flaw that requires a 2GB+ payload, which probably makes it much less conducive to unit tests, but probably still the type of situation of integer size boundaries for fuzzers to target.