Hello and welcome to the Thursday, July 3rd, 2025
edition of the SANS Internet Storm Center's Stormcast. My
name is Johannes Ullrich and this episode is brought to you
by the sans.edu Bachelor's Degree Program in Applied
Cyber Security. And it is recorded in Berlin, Germany.
Well, sadly, to start out with, we do have a new
vulnerability in the good old Linux command sudo. This
vulnerability was found by Rich Merch with StrataScale.
It is relatively easy to exploit. Rich, also as part of
his blog post, did provide a proof of concept exploit for
this particular vulnerability. Patches have been made
available for all current Linux distributions. As far as
I can tell, some of the older ones are actually not
vulnerable as this particular vulnerability was introduced
in a more recent version of sudo. The problem with this
vulnerability is the change root option. Now, the root in
change root, of course, has nothing to do with the root
user. It's meant to run the command in a more restricted
environment. The problem is that that may give the person
running the command actually the ability to map some files
that the user may change to files that sudo will then use
and execute. And that's sort of really the problem that has
to be addressed in the patch for this vulnerability. Again,
proof of concept export is available. Exploitation isn't
all that difficult. Not 100% clear which exact version and
distribution is vulnerable or not vulnerable. But in order
to exploit the vulnerability, an attacker would just need to
have access to any account on the system. The attacker does
not need to have access to any account with some kind of
restricted sudo privileges. That has been a common issue
in the past where administrators try to restrict
sudo to certain commands for certain users. But these
restrictions were then bypassed. That's not the case
here. Any user on the system will be able to execute
commands as root no matter what their sudo configuration
looks like as long as the version of sudo is vulnerable.
Well, next we do have a flaw in a very common file format.
ZIP files. ZIP files, compressed files, of course.
It's a fairly old file format. And Hack Arcana in a blog post
noted an interesting ambiguity. The end of central
directory record or the central directory itself has
the number of entries. Basically, different files
contained in a ZIP file. And then they also have a length
of the directory. Now, it turns out some software uses
the number of entries. Other software uses the length to
figure out how many files are contained in a particular ZIP
archive. What this leads to is that if these two entries
don't agree, then different software may actually give you
different results as to what files are contained in a ZIP
archive. If you know a victim uses a particular software, of
course, that could be used to fool the victim into opening a
file that may not have been properly inspected prior
because whatever software used to inspect the file did not
parse the ZIP archive the same way as the victim. There are a
couple other interesting attack possibilities that are
outlined in the blog post. But essentially, you have
inconsistent behavior. Different users, different
software may see different content in a ZIP file. Yeah,
and given that this is sort of part of the standard, there's,
of course, no universal fix for this. Pretty much just be
consistent in your implementations that they all
interpret ZIP files the same way. And maybe if you do run
into files where these two records don't agree, then
don't parse them. Some implementations apparently
give you some warning if that's the case. And we got
critical updates from Cisco, in particular for the Unified
Communication Manager. One of Cisco's favorite
vulnerabilities, static SSH credentials. These static SSH
credentials for root, I guess, were supposed to be reserved
for development but ended up in productions. And with those
credentials, any attacker could just log in. The user is
not able to alter or remove those credentials other than
by applying the latest patch. Well, and that's it for today.
As announced earlier this week or last week, there will be no
podcast tomorrow. The next podcast will be on Monday. So
thanks for listening and talk to you on Monday. Bye.
