SANS Stormcast Thursday, October 30th, 2025: Memory Only Filesystems Forensics; Azure Outage; docker-compose patch

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9678.mp3

previous

Memory Only Filesystems Forensics; Azure Outage; docker-compose patch

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Referring to today's episode on Microsoft outage, there was definitely some DNS issues going on at MS yesterday. My home "apt update" script suddenly complained about "packages.microsoft.com", and my troubleshooting showed that the authoritative DNS servers for some Azure domains where unavailable on IPv6, while they seem to respond on IPv4. The .8 Google DNS had the same problem as my local resolver, my the .1 Cloudflare resolver seemed to work. So it could be a combined DNS and IPv6 issue? Great podcast as always, a good way to start the day and be a little prepared for what the day may bring.

Posted by [email protected] on Thu Oct 30 2025, 07:32

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Thursday, October 30th, 2025
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, 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 occasion. Sometimes you have also
 temporary file systems, even slash 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 no 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 like 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. And 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 and news that was DNS related. 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. 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 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 we have
 an interesting vulnerability in Docker Compose. If you're
 not familiar with Docker Compose, it's a way how you
 can script essentially creating systems networks of
 multiple Docker containers. Now one of the option 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 director, 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, this is 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. Bye.