Summary3 min read

SANS Stormcast (Oct 30, 2025) – Summary

Host: Johannes B. Ullrich
Main Topics: Memory-Only Filesystems Forensics, Azure Outage, Docker Compose Vulnerability

Episode Overview

This episode centers on three current cybersecurity developments: forensic challenges of memory-only (RAM-disk) filesystems in Linux, a significant authentication outage with Microsoft Azure’s Front Door service, and a newly patched vulnerability in Docker Compose that could allow writes outside the expected directory. Johannes B. Ullrich provides practical insight and context to each topic, referencing listener feedback and industry news.

Key Discussion Points & Insights

1. Memory-Only (RAM-disk) Filesystems and Forensics

[00:22]

Overview:
Jim’s diary discusses forensic challenges when dealing with memory-only filesystems in Linux, such as DEFSHM and RAM-mounted /tmp.
Technical Difficulty:
Unlike disk-based filesystems, these have no associated block device—so traditional disk imaging tools like dd won’t work.
Jim’s Shell Script:
- Suggests collecting metadata with stat and copying individual files.
- Admits it’s not forensically perfect (“doesn’t… create a bit by bit copy” [00:47]), but it’s practical.
Potential Issues:
Cautions regarding “odd file names… as you’re passing them to the command line” [01:07].
- Recommends checking file names before copying.
- Listener asked for a follow-up diary to address more edge cases.
Engagement:
Johannes invites further suggestions:

“If anybody has any other better ideas, please let me know.” (01:24)

2. Microsoft Azure Outage (Front Door Authentication)

[01:31]

Incident Details:
- Microsoft Azure’s authentication service (“Front Door”) experienced an outage, making some services inaccessible to users.
- Direct impact on SANS systems, including exam access.
Scope & Recovery:
- “A little bit more limited... one specific system that failed… authentication part” [01:35].
- Outage was being resolved as Johannes recorded the episode.
DNS Rumors:
- Public speculation pointed to DNS; “I somewhat doubt that this was DNS related.” (02:06)
- Microsoft’s own notes don’t mention DNS as a cause.
Comparison to AWS Outage:
- People conflated this with a recent AWS outage:
  
  “It was only Azure that was affected, not AWS.” (02:26)
- Down Detector spike for AWS likely due to social media chatter, not actual AWS service problems.
Clarification:
Johannes emphasizes only Azure was affected.

3. Docker Compose Vulnerability and Patch

[02:42]

Nature of the Vulnerability:
- Docker Compose could include remote “OCI artifacts” that result in files being created outside the designated project directory—violating containment expectations.
Affected Tools:
- Docker Compose is also used by Docker Desktop and similar tools.
Risk & Patch:
- “A patch was released. Exploitation is certainly likely…” [03:06]
- Especially risky since Compose is often used to build from third-party sources.
- Exploitation “pretty straightforward.” (03:19)
Recommendation:
Immediate patching is advised for anyone using Docker Compose.

Notable Quotes & Memorable Moments

On memory-only forensics:

“The problem now is that dd, your standard tool that you’re using to make sort of forensically sound copies of data… don’t work on these memory only file systems.” – Johannes B. Ullrich [00:37]
On Azure outage rumors:

“I don’t see anything related to DNS in Microsoft’s notes here about this particular incident, so I somewhat doubt that this was DNS related.” – Johannes B. Ullrich [02:06]
On Docker Compose vulnerability:

“This is certainly something that’s somewhat exploitable and should be patched. Also, exploitation at this point is pretty straightforward.” – Johannes B. Ullrich [03:17]

Timestamps for Major Segments

[00:22] Memory-only filesystems forensics problem and Jim’s workaround
[01:31] Azure “Front Door” authentication outage overview and industry context
[02:42] Details and impact of the Docker Compose OCI artifact vulnerability

Episode Tone & Style

Practical and succinct: Delivers up-to-date news with enough technical context for professionals.
Listener-focused: Frequently references listener feedback, inviting further participation.
Balanced: Avoids speculation, corrects misinformation (e.g., DNS rumors), and distinguishes facts from public perception.

For Listeners

Further Reading/Participation: Listeners are encouraged to check out the SANS Internet Stormcenter diary for more technical details and to suggest further solutions or improvements, particularly concerning forensics on memory-only filesystems.
Action Items: Patch Docker Compose installations; check for Azure service accessibility if affected.

Loading summary

Transcript1 lines

[00:05]
A
Hello and welcome to the Thursday, October 30, 2025 edition of the SANS Internet Storm Center's Stormcast. My name is Johannes Ulrich, recording today from Jacksonville, Florida and this episode is brought to you by the SANS EDU Graduate Certificate Program in Cybersecurity Engineering. In diaries today we have Jim talk about memory only file systems on Linux, sometimes colloquially called RAM disks. Of course they exist on other operating systems as well. The tricky thing about these memory only file systems on Linux is that there is no block device associated with those file systems. Often DEFSHM is a typical location. Sometimes you have also temporary file systems, even temp sometimes being mounted as a memory only file system. The problem now is that dd, your standard tool that you're using to make sort of forensically sound copies of data and similar tools don't work on these memory only file systems. So Jim is going over a little shell script that he's using in order to deal with those file systems. Yes, it's not ideal in the sense that it doesn't sort of create a bit by bit copy of the file system, but instead what Jim is suggesting here is to basically just first use the shell stat command in order to collect basic statistics about the files and then copy individual files. There was a comment on social media that maybe we can do a follow up diary about this. To be careful with odd file names here as you're passing them to the command line as Jim suggests. Of course, typically you would first sort of take a quick glance at the directory that you're copying here to make sure that the file names are valid. Nothing really odd happening here with these file names. But yeah, overall interesting diary here and definitely a valid problem. If anybody has any other better ideas, please let me know. Like I said, we may do a little follow up on some of the problems around memory only file systems. Well, another day and another major failure of a cloud provider. This time it's Microsoft with its Azure system. Now the failure here was a little bit more limited in the sense that it was one specific system that failed. But that system that failed was Azure Front Door, which is the authentication part. So if you're using that to authenticate users for your services, well then they were not able to reach your services. This has also affected a couple of SANS related systems. I heard some issues about the exams. For example, just for that reason you couldn't authenticate, so you weren't able to actually then connect to the system that relied on this particular authentication scheme. Overall, this should be around now as I'm recording this go back to normal. I haven't tested myself yet. There was some reports in news that was DNS related. I don't see anything anything related to DNS in Microsoft's notes here about this particular incident, so I somewhat doubt that this was DNS related. Of course, people compared it to the AWS problem that we had a few days ago. Also, AWS was not affected. The website Down Detector showed some spike in outage reports for AWS as well. Remember that website is often parsing things like social media posts and the like, and with people comparing this outage to the AWS outage. Of course there were also more mentions of AWS outages which may have related or led to that spike of reports in the down detector graph. So it was only Azure that was affected, not aws, and we don't know if it was DNS related or not at this point. And then we have the interesting vulnerability in Docker Compose if you're not familiar with Docker Compose, it's a way how you can script essentially create creating systems networks of multiple Docker containers. Now, one of the options here is that you are including remote resources as you're building these containers, and if these resources do contain Open Container Initiative artifacts or OCI artifacts, then they may lead to the creation of files outside of your Docker Compose directory, which they're not supposed to do. Docker Compose, that tool is also used as a backend for tools like Docker Desktop and the like, so it's not just running it standalone where you're affected. Here a patch was released. Exploitation is certainly likely in the sense that as you're building these Docker containers using Docker Compose, you often do rely on resources that you're downloading from other sites from basically others that have created containers that you're using. And as a result, this is certainly something that's somewhat exploitable and should be patched. Also, exploitation at this point is pretty straightforward. Well, that's it for today, so thanks for listening, thanks for liking this podcast, and as always, thanks for recommending it and talk to you again tomorrow. Bye.