SANS Stormcast Thursday, October 23rd, 2025: Blue Angle Software Exploit; Oracle CPU; Rust tar library vulnerability.

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

previous

Blue Angle Software Exploit; Oracle CPU; Rust tar library vulnerability.

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Thursday, October 23rd, 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
 industrial control systems security. Our honeypots,
 again, caught a newish exploit. And this one targets
 URL webcontrol.cgi that's typically associated with the
 Blue Angel software suite. This is embedded software.
 It's often found in customer premise equipment like
 routers, voice over IP equipment and such that often
 uses this software made by 5Vtechnologies. So it's not
 really sort of a household name or you may not
 necessarily know that your particular device runs on this
 software. The problem here is a basic OS command injection
 vulnerability. That's very typical for this kind of
 equipment. A lot of times they do have a debug feature that
 allows you to ping hosts from the device. You, of course,
 need to provide an IP address or a host name that's then
 passed on the command line as part of the ping command.
 Well, if you're not careful, and that apparently is what
 happened here, there is the possibility of injecting
 additional operating system commands. So very classic
 vulnerability. I had a little bit of hard time assigning it
 an exact CVE and I'm actually not sure if I got the right
 one here. Last or this July, there was a new CVE found in
 this particular software suite, CVE 2025-34033. Very
 similar to description to what we are seeing here. However,
 the description of this CVE suggests a GET request and
 also uses a slightly different parameter name for the actual
 warnable parameter. But overall looks sort of like the
 same vulnerability, possibly also in some other equipment.
 All these types of equipment are very similar to each
 other. So it's sometimes really difficult to find the
 perfect match here for the CVE. If someone knows a better
 match, well, please let me know. And Oracle released its
 quarterly critical patch update or CPU for October
 2025. This particular update fixes 374 different
 vulnerabilities across Oracle's entire product
 portfolio. I counted about 135. I think it was affected
 products. Oracle's portfolio is rather large. Of course,
 big attention this month on Oracle eBusiness Suite if
 there's anything new here. Now, the early patches that we
 received over the last couple of weeks are not included in
 this critical patch update. Instead, we got a total of
 nine new vulnerabilities here in Oracle eBusiness Suite. Two
 of them are critical with a CVSS base score of 9.8.
 Overall, there are a number of additional 9.8 vulnerabilities
 here across the different Oracle products. Many of them
 are related to a vulnerability in SQLite. So this is a known
 vulnerability in SQLite that is now being patched in
 Oracle's products who are using this open source
 database. Other than that, nothing really too
 outrageously critical here that I can tell. Like I said,
 there are these 9.8 vulnerabilities. But aside
 from that, yes, a patch, of course. But as always, these
 Oracle patches you want to treat with care and not just
 rush them out, but carefully test them. And we have yet
 another vulnerability in a library that deals with
 Torfiles. The vulnerability itself is actually not really
 that remarkable. We had this in other libraries too. There
 is sort of a fundamental problem with Torfiles. There
 are sort of redundant ways to specify the content of the
 file, either with the U-star or PAX header. The problem is
 if they don't agree, then it's possible to essentially
 smuggle files in and overwrite arbitrary files if the
 software on tar'ing and expanding the tar file isn't
 dealing carefully with this mismatching information. Like
 I said, this has happened in other languages as well. A
 couple of interesting things about this particular case.
 First of all, it's in a Rust library. Now, Rust is
 advertised as a more security -focused language. And it is
 more security-focused when it comes to memory management.
 Any other vulnerabilities like these logic issues we have
 here with parsing these TAR file headers, well, Rust is
 really neutral in that respect and not any worse or better
 than any other language. The other problem here, and it's
 sadly a somewhat common problem, is that the affected
 libraries here are no longer maintained. So, Async TAR is
 no longer maintained. Tokyo TAR is no longer maintained.
 And with that, of course, it becomes really difficult to
 fix these flaws, in particular since these libraries are very
 widely used in various software products. Now, the
 discoverer here did a good job in notifying affected
 software. And then basically it's up to the users to then
 patch the particular library in their particular product. I
 hope that this will also kind of lead to the project being
 revived maybe. The other thing here is also if you are
 creating any kind of open source project, any project
 like this, try to add the contact information where
 someone can reach out in case of a security issue. For
 GitHub, there is like the security.md file that's often
 being used. There is the famous security.txt file on
 websites that I still don't really see as widely used as
 it should be used. So, make sure researchers who find
 these vulnerabilities can find you. Should it have had a
 special name here, Tarmageddon, and the logo?
 Probably not, but still good work here by the researchers,
 in particular when it came to disclosure of this
 vulnerability. Well, and that's it for today. So,
 thanks for listening. Thanks for liking and subscribing to
 this podcast. And talk to you again tomorrow. Bye. Bye.
 Bye.