Punycode in OpenSSL, Authn in Cosmos DB Notebooks, Documenting Security, IoT Labels – ASW #219

Originally described as critical, the recent OpenSSL vuln seems to have mostly fizzled into a high-risk vuln that requires patching (pretty much like any other vuln), but didn't turn into a Heartbleed-style meltdown. Of course, I don't think anyone's actually complaining about that outcome...

Here's the OpenSSL advisory and, if you're interested in digging into the fix, here's the relevant commit.

This past year we've covered several disclosures from the teams at Wiz.io and Orca.security picking at security boundaries and capabilities within Azure. This week it's Orca with a takeover and RCE in Azure's hosted Jupyter notebooks (their Cosmos DB Notebooks).

In general, using cloud-based virtual desktops like Jupyter is a good security choice that helps maintain a secure, consistent, and observable environment for interacting with sensitive data. It's a positive step in reducing an attack surface -- it's just important that the implementation's security meet its design intentions.

Here's a very different issue that touches on our past discussions about cybersecurity education at the university level. Some students got funding, launched an app, and made claims about the anonymity and security of users. Some other students did some security research, discovered many basic authentication and authorization weaknesses, disclosed their findings to the company and then...received a decidedly unfriendly and threatening response from the company's legal team. It was very modern appsec bug bounty behavior met with very 90s corporate belligerence.

We always like to highlight well-written articles about discovering and exploiting vulns -- they're great examples of communication skills and education. We also like to highlight the importance of communication skills when collaborating with developers or presenting security concepts to various audiences. Here's an article that reinforces those ideas and offers some suggestions on how to approach this for security teams.

This is also an area where appsec teams can learn from developers. I've seen a few great API style guides that developers use to document their APIs for others. After all, such code is written to be used by others -- what better way to aid that adoption than by clear, concise documentation. Share some of your favorite API documentation with us!

I even curate a personal style guide for the podcast.

This is a good companion to the security documentation article. Google explains their approach to documenting security for IoT devices. It also lays out the consideration for what is necessary to make labeling effective and useful. Notably, it points out that labeling is dynamic -- the status of security changes over time and a labeling solution must support that. It also notes the importance of incentives so that labels become something informative and available to consumers as opposed to a cynical checklist exercise from the infosec community.

The recorded sessions from this year's USENIX Security conference are now available. For those of you who dive into Linux kernel details, there are two appealing talks on ARM pointer authentication and TOCTOU protection.

If you're looking for a Trust & Safety angle or better understanding threat models for different user populations, check out the "At-Risk Users" sessions.

There are also several sessions on fuzzing and an interesting one about the lifetime of vulns that touches on the span of time between the introduction of a vuln and when patching is mostly done. That session also talks a little about the age of code and how that influences the age of vulns. While that session is looking at Open Source projects, one takeaway from this kind of measurement is how well your own teams can identify, fix, and rollout security patches for their own code, whether in response to bug bounty reports or from tools like fuzzers.

This is also older news, but still worth highlighting videos now available from this year's DEF CON. Two that stand out are

• DEF CON 30 - Minh Duong - The Big Rick - How I Rickrolled My High School District, Got Away With It -- we covered this and his blog earlier this year.
• DEF CON 30 - Cesare Pizzi - Old Malware, New tools: Ghidra and Commodore 64 -- a fun combination of new (Ghidra) and old (C64)

It's the anniversary of one of the most famous articles in appsec history. It popularized techniques for finding buffer overflows and served as an excellent primer for the nascent security community.

"On many C implementations it is possible to corrupt the execution stack by writing past the end of an array declared auto in a routine. Code that does this is said to smash the stack, and can cause return from the routine to jump to a random address."

Cisco has published a security advisory for a vulnerability in the web-based management interface of Cisco Identity Services Engine (ISE) that could allow an authenticated, remote attacker to read and delete files on an affected device. The bug, with a CVSS score of 7.1 has no patch and no workaround. Cisco plans to provide a fixed release for version 3.1 in November, and a fixed release for version 3.2 in January, 2023. Release 3.0 and earlier are not vulnerable.

Bleeping Computer reports that a recently uncovered (but somewhat old) bug has been unearthed which helps people with bad intentions to leapfrog MOTW alerts. This has, apparently, already been observed in ransomware attacks.

This article highlights the human cost of cybercrime. Join us in this visceral journey through several people's experiences of being held captive and forced to enact cyberscams or face the dire consequences.

As software engineering teams think about writing up vulnerability disclosures - particularly in software considered "critical infrastructure" - questions arise about who to report the issue to first. Interesting to consider after the openssl vuln announcement last week...

Interesting - surprising - hack in the linux kernel: Due to X11 not playing nice with video modesetting in the kernel, and apparently few folks interested in maintaining X11, some code was inserted into the linux kernel to treat processes from commands starting with X differently.

I've been on a kernel kick recently - the source is open, usually it's quite clean and well documented. Even there, though, things aren't always perfect...

Interesting to think about how a hack like this could have been used in a malicious way.