ASW #228 – Adrian Sanabria

The last 747 draws a picture with its flight path. And, yes, there's a way to (sort of) connect this to appsec.

There's a long history of easter eggs in software, including from well-known Seattle-area companies. Plus an even longer history of ASCII art in command line tools, source code, and zines.

Lots of early hacking groups used ASCII art in their web sites and advisories. You can see some grand examples from the Cult of the Dead Cow. There were similar groups to come out of the 90s like w00w00 and TESO.

SQLMap, which I highlighted in our tool segment last episode, uses ASCII art for its logo.

And for those of you looking for practical applications of ASCII art, you can even turn markdown into diagrams with Mermaid. ASCII diagrams are a big part of many RFCs.

Here we go: Another example of unsafe memory handling (a double-free) in C code. But this can also give us a chance to talk about software design that incorporates sandboxing and reduced privileges to make vulns more difficult to exploit.

We can eradicate these types of issues with memory safe languages (and avoid some of the unsafe ways those languages can dip into memory management). But we can't refactor everything. So we need good controls to make these vulns less worrisome.

Additional resources:

• https://blog.qualys.com/vulnerabilities-threat-research/2023/02/03/cve-2023-25136-pre-auth-double-free-vulnerability-in-openssh-server-9-1
• https://bugzilla.mindrot.org/show_bug.cgi?id=3522
• https://github.com/openssh/openssh-portable/blob/6dfb65de949cdd0a5d198edee9a118f265924f33/sandbox-seccomp-filter.c
• https://github.com/openssh/openssh-portable/blob/6dfb65de949cdd0a5d198edee9a118f265924f33/sandbox-darwin.c
• https://github.com/openssh/openssh-portable/blob/6dfb65de949cdd0a5d198edee9a118f265924f33/sandbox-systrace.c

Here's the counterpoint to the "less worried" stance on OpenSSH's use of C code.

In this case, we have a service that runs as root, has a format-string vuln, and uses a SOAP interface. Of these, running as root seems like the most egregious design mistake, format strings seem like a missed opportunity to pay attention to compiler warnings, and SOAP is...well, just an ancient choice by modern standards.

Additional resources:

• https://cs155.stanford.edu/papers/formatstring-1.2.pdf
• https://www.skullsecurity.org/2015/defcon-quals-babyecho-format-string-vulns-in-gory-detail

A new framework led by OX Security proposes "a comprehensive, systematic and actionable way to understand attacker behaviors and techniques with respect to the software supply chain." It's similar to the MITRE ATT&CK framework, with a focus on bringing shared terms and definitions around supply chains security so organizations can better protect their pipelines.

We continue to look for definitions of what secure code is. Just asking something like, "Should I use a memory safe language?" or stating as a security requirement, "Use a memory safe language" doesn't frame the issue very well. The conversation should be about how the code is written, who's writing it, and what they're designing. This article goes into some of those aspects, skipping an over-simplification like "C is bad."

Socat is necat for more complex communication channels. From the README:

socat is a relay for bidirectional data transfer between two independent data channels. Each of these data channels may be a file, pipe, device (serial line etc. or a pseudo terminal), a socket (UNIX, IP4, IP6 - raw, UDP, TCP), an SSL socket, proxy CONNECT connection, a file descriptor (stdin etc.), the GNU line editor (readline), a program, or a combination of two of these. These modes include generation of "listening" sockets, named pipes, and pseudo terminals.

Bad git commit comments are a pet peeve of mine. Perhaps ChatGPT can help?

An article from friend of the pod, Chris Romeo on how SBOMs aren't the silver bullet of people's dreams...

Looks like this was a limited (ha) event, but google's proxy for go packages was sending gigabits of traffic to some git repos. While fixed, this is an example of how the best intentions can cause harm

Following on my previous story about Mr. Stroustrup's claiming in a PDF that C++'s security is just fine, the C++ direction group has now put out a longer opinion piece that comes down to "here's some things we can do to figure out if we should improve the safety of C++ or no."

It's interesting to see their thoughts related to the US NSA/NIST stating a need to move towards more secure-by-default languages, and seemingly leaning towards a decision of "they don't know what they're talking about" (my intrepertation)

Dashlane - a password safe startup, is attempting to make themselves look better than the other password safes that keep having security issues by publishing their source code on github.

That said, it's not the complete source code, as they don't want users to be able to build their own dashlanes. And they released it under a Creative Commons License (not usually used for software).

So, at least to me, this feels like the source code equivalent of a product having a hacking contest and then saying their product couldn't be hacked.

I'm posting a link here to a Techcrunch story instead of going to the source as an example of the attention some media outside of our security bubble is giving to application security.