Podcast Detail

SANS Stormcast Wednesday, June 24th, 2026: Patching vs. Configurations Updates; libssh2 and ffmpeg vuln;

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/9984.mp3

previous
Podcast Logo
Patching vs. Configurations Updates; libssh2 and ffmpeg vuln;
00:00

My Next Class

Click HERE to learn more about classes Johannes is teaching for SANS

Podcast Transcript

 Hello and welcome to the Wednesday, June 24, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich and today I'm recording from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Graduate Certificate Program in
 Penetration Testing and Ethical Hacking. Yesterday I
 talked about Fortibleed, the attack where someone did
 compromise Fortinet firewalls and then used that access to
 harvest additional credentials. Well, today it's
 SonicWall. Manuel looked at SonicWall firewalls that he
 worked at as part of his job and such and looked not just
 whether or not they were patched. There were in 2024
 some well-publicized vulnerabilities that allowed
 credential theft and, well, the sonicwall had the same thing
 happen that happened with Fortinet that hackers came in,
 used credentials they harvested earlier and re
 -compromised firewalls after they were patched. Well, so
 what Manuel looked at was how many of these firewalls were
 not just patched but also reconfigured after the patch
 was applied. And one of the saddest part of this of the
 statistics here is that almost none, like 86% of the
 firewalls, did not reconcile their credentials with Active
 Directory. So there were still basically legacy credentials
 on the firewall itself that could have been compromised by
 an attacker or maybe even accounts that an attacker
 created. Also, 80% of the firewalls did not rotate their
 passwords. There are a couple of things here that I think
 are, you know, sort of nice to have. Like, for example, some
 additional filtering of which IP address can actually
 connect to the SSLVPN here. I forgive that for you because
 sometimes that's why you have the VPN in the first place
 because then you have people that travel all over the place
 and you need to provide them with a secure access channel
 back to your network. But then you also had, for example, 36
 nets, like the lowest percentage here among the
 issues that Manuel looked at, of firewalls that basically
 didn't terminate stale sessions. So you could be
 connected for more than 24 hours, not transmit any data
 and still retain that connection. There can be some
 use cases where you want this to have happen, like for some
 kind of data center links or things like this. Not
 necessarily sort of for a road warrior scenario necessarily.
 And yeah, and then of course, also reviewing your logs after
 you patch to make sure that you hadn't already been
 compromised. Actually, I'm surprised that, you know,
 about more than half of users actually do it. And only 43%
 here did not actually perform this. No, sample size there
 was not huge. It was basically just the firewalls that Manuel
 looked at. But still, I think those numbers are probably
 pretty good and sort of point you into the right direction
 as, well, people just apply patches, but don't necessarily
 have sort of that vulnerability management
 lifecycle, where they have specific procedures that you
 have to perform after you apply a patch, like for
 example, look for indicators of compromise if it's an
 already exploited vulnerability. And we have yet
 another major vulnerability that affects a very commonly
 used library, libssh2. libssh2 is used to implement SSH
 clients. So not necessarily just a server, but this is a
 vulnerability that likely affects clients more than it
 affects servers. The problem here is a heap based buffer
 overflow that may lead to remote code execution. To
 exploit this vulnerability, an attacker would have to trick a
 victim to connect to a malicious SSH server. But the
 tricky part here is that this also works for a machine in
 the middle scenario. So this works pre-authification before
 the client, make sure that it actually connects to the right
 server. A patch is available for this vulnerability. Keep
 checking with your respective Linux distributions such if a
 patch is being offered. But if it's not out there yet, when
 you're listening to the podcast, it should be. But lib
 is not the only critical library that we need to talk
 about today. The next one is FFmpeg. FFmpeg is, well, a
 library that is used to pretty much do anything when it comes
 to video and audio processing. I use it for this podcast to
 do things like the subtitles for the videos, for example.
 But the problem with FFmpeg is that it is very optimized for
 a speed kind of library. So it has had issues with not doing
 memory checks and such in the past. Also that a lot of the
 image formats and video formats it has to deal with
 are compressed, which always makes things like getting
 sizes right complex and difficult. So what happened
 here is a heap out of bound write that leads to remote
 code execution. This essentially affects any
 software that uses FFmpeg. These are not just video
 players and such, but also a lot of server side software
 that does, for example, video and audio conversion. That's
 sort of a common use case for FFmpeg. So definitely try to
 get this patch. It can be a little bit complex to figure
 out what actually uses FFmpeg. Effective is the magic YUV
 decoder. So basically how colors are being dealt with at
 compile time. You may disable this decoder if you don't need
 it. But I don't know if a lot of people who are sort of
 manually compiling FFmpeg most just take the ready to go
 package that comes with many of these features enabled by
 default. Well, and this is it for today. So thanks for
 listening. Remember, there will be no podcast Thursday,
 Friday due to my travel schedule. So this is the last
 podcast for this week. Well, I'll talk to you again on
 Monday. Bye.