First Officer’s log, Terrestrial date, 20220926. Officer of the Deck reporting.
We have been getting steady mission updates from the team on [REDACTED] and they are making admirable progress. However, it has not been without complications. I may have to put Lieutenant [REDACTED] in for a commendation for her not taking a Phaser to some of the vendor representatives the crew has been forced to work with.
For example, while the world’s defenses should be acting in concert, each of the components in the [REDACTED]’s planetary defense system acts as if it is the only thing defending the world from attack, and each of the vendors is quite insistent that any problem is not theirs.
Case in point.
As mentioned, the planetary shield purchased from the [REDACTED] and the point defense purchased from the [REDACTED] don’t talk to each other. Almost at all. Unsurprisingly, the [REDACTED] insist that the problem is not with their shield but instead lies with the point defense system’s inability to follow the logic the shield uses when identifying ships that it will allow through.
On the other side, the [REDACTED] insist they make the best point defense and are furious they are being blamed for the issue, which they consider an affront to their honor and have insisted that the matter be settled by ritual combat. Something our crew has, understandably, been trying to avoid.
Meanwhile, the Traffic Control system has been routing ships either through both the shield and point defense system’s restricted spaces, or sending them into an arbitrary parking orbit where they remain on station until someone can manually guide them in.
When our Engineer asked them directly what was happening, the response went something like this.
Rep #1: “Our system is good.”
Rep #2: “Yes. Our system is good.”
Us: “But there is a problem with <extensive explanation of said problem>.”
Rep #1: “We do not understand the problem.”
Rep #2: “Yes. We do not understand the problem.”
We have instructed Lieutenant [REDACTED] to avoid escalation between the vendors as we help them sort it out. But added that if it does escalate, phasers are to be set to stun. Heavy stun. But still just to stun.
Some security love for K8s
What happened
A new AI-driven tool has been developed by Cast Security to help bring clarity to the Kubernetes space.
Why it matters
Kubernetes security has some specific security challenges and any tool that can help teams address the issues is welcome. While this tool is specific to its developer’s ecosystem, it would be easy to add the data it generates to the Vulcan Cyber risk management platform using our ConnectX tools. So a win/win for organizations that use both.
What they said
It’s not just the bad news that gets people talking. There’s been plenty of chatter about this positive development.
New life for CVE-2007-4559?
What happened
In a recent blog post, Trellix pointed out that a vulnerability discussed in CVE-2007-4559 is still technically in play. While mitigations and compensating controls have been available since the issue was first revealed 15 years ago, the underlying functionality still exists within Python’s tar handling code.
Why it matters
This is an unusual case. CVE-2007-4559 is derived from the “creative abuse of intended functionality” and not buggy code. Discussions at the time from major Linux vendors, including Red Hat and Debian, concluded that it was working as intended and “fixing” it would remove some useful functionality. While it wasn’t especially difficult to exploit the flaw, it required some specific circumstances, and a combination of best practices and compensating controls would mitigate it.
That’s what justified the original CVSS score of 6.8 (Medium) in the first place. While the Trellix post revives the discussion about CVE-2007-4559, it’s unclear at the moment whether anything has actually changed to justify altering the CVSS score.
What they said
Whether or not there’s cause for concern, CVE-2007-4559 is getting some renewed attention.
This could have been really bad
What happened
Researchers discovered an “isolation vulnerability” in Oracle Cloud Infrastructure (OCI) that could have allowed users to attach to other users’ storage volumes without authentication. Oracle patched the vulnerability within 24 hours of being told about it, and no additional actions were required by OCI users.
Why it matters
Cloud security is a complex beast, but one of the factors we, as cloud users, rely on, is the cloud vendors doing their part to keep us safe. The security and configuration of our applications is OUR responsibility but keeping the infrastructure itself safe falls to the cloud vendors themselves. Whether it’s AWS, Azure, GCP, Alibaba, or anyone else, they’re the ones who have to keep the basic platform secure.
Here, Amazon acted to fix an issue quickly and effectively. In doing so, they managed to keep an issue from moving from A Bad Thing™ to a headline-generating event. Hopefully, some additional lessons will come out of this about keeping “attacker-useful” data out of the public eye. Here, it was volume IDs. But it’s hard to tell when a creative attacker will find a new way to abuse information you didn’t really think was important.
What they said
Close calls still warrant some discussion. See what people are saying.
___________________________________________________________________________________________________________________________
Want to get ahead of the stories? Join the conversations as they happen with the Vulcan Cyber community Slack channel
