Vulns in Smart Locks, FCC labels for IoT, ZAP’s New Home – ASW #277

A big part of this is a matter of transparency and design. There are use cases for a lock to support "manager" codes. However, the presence of such codes needs to be disclosed to users so those who don't need that support can disable it. This also means that a lock should support disabling such codes or, for a better default, require it to be explicitly enabled by the user.

Pushing for this type of transparency and secure defaults would be something we'd hope to see in the Cyber Trust Mark effort.

Here's a second smart lock article for this week. The other was more about failures in transparency and secure defaults, while this one looks more like failures in secure design.

The list of vulns reads like basic flaws that should have been discussed and addressed in its design. Why is an unencrypted connection possible? Why is downgrading the encryption of a connection possible? Why aren't keys deleted from the client and the lock?

Again, I'm curious how this situation would play with a Cyber Trust Mark. I wouldn't advocate revoking a label because a vuln exists, but when a vuln points to an underlying weak design (as opposed to an implementation error) I'd hope the mark would be revoked.

You probably know my stance by now on these kinds of articles -- big company spends lots of money on finding bugs. I would love to see how much money they spent on fixing the bugs, including changing processes and tooling to find not only the reported bug, but any similar ones.

However! There's a nice point in here about how the recent release of MiraclePtr in Chrome has both raised the difficulty of use-after-free exploits and reduced the rewards for bugs mitigated by it. (There are still hefty rewards for bypassing it.) That kind of secure design is what bug bounty programs should be driving.

We talked more about MiraclePtr back in episode 271.

This also linked to a Bughuners Blog that's worth following if you're interested in keeping up secure design concepts. That's much more interesting than how much money they spent.

Last year ZAP shifted from being an OWASP project to one within the OpenSSF. But...that OpenSSF funding dried up. Luckily, it's found a new home at Crash Override. What's notable about this is the funding model that Crash Override is using and their criteria for finding projects to support.

Be sure to check out episode 254, where we spoke with Simon Bennetts about how he came to create ZAP and his vision for its future.

The FCC initially announced this IoT mark back in August 2023. Now they've adopted it, along with a preview of its logo. You can find the press release and more details of the program here.

As an aside, one thing I disliked about the press release was its emphasis on number of attacks when the underlying problem is the amount of vulns in these devices from insecure designs and insecure default configurations. The attacks are a byproduct of that and, of course, successful exploitation has a lot of negative impact to user's privacy and safety. I would have liked to see stronger language about vendor failures, but I suppose there needs to be a balance in the framing when an effort like this is purely voluntary.

This article is more of a reminder about how orgs are compromised and that enterprise security needs to mature to what's essentially a zero-trust model, such as token-based authentication, identification and access boundaries at the device layer, and pervasive observability.

It seems to be more optimistic about the state of appsec than I am. But the major point is that protecting an org (or even protecting a product and its ecosystem within an org) is more about familiar basics of asset inventory and strong authentication than it is any top ten list.

OpenSSF is running a survey about secure software development education. This is a topic we talk about quite a bit, which also means we should reach out to the organizers and have them on the show to talk about the results. Go fill out the survey so we have something to talk about!

Vusec performed speculative execution research against the "common" synchronizations primitives such as mutexes and spinlocks, and found that on Linux these are implemented through conditional branch logic. This means that these primitives are vulnerable to spectre-style speculative execution attacks no matter the CPU architecture.

Since Spectre first came out, lots of research has also been done on more efficient ways to mitigate this class of attack. See https://www.comp.nus.edu.sg/~tcarlson/pdfs/pashrashid2023hemocsathr.pdf or https://ittc.ku.edu/~heechul/papers/spectreguard-dac2019-camera.pdf as two examples.

Interesting piece in The Next Platform: When we compute at Scale nowdays, we're looking at 1000+ node clusters with terrrabytes of memory and disk. Really, this is not something most modern operating systems were build to handle tracking state and scheduling tasks for. Kubernetes and other do it at a higher level...but what if instead of putting a database on top of the OS, we replace the OS with the db?

What does that mean for security?