Podcast Detail

SANS Stormcast Monday, December 22nd, 2025: TLS Callbacks; FreeBSD RCE; NIST Time Server Issues

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

previous
Podcast Logo
TLS Callbacks; FreeBSD RCE; NIST Time Server Issues
00:00

DLLs & TLS Callbacks
As a follow-up to last week's diary about DLL Entrypoints, Didier is looking at TLS (“Thread Local Storage”) and how it can be abused.
https://isc.sans.edu/diary/DLLs%20%26%20TLS%20Callbacks/32580

FreeBSD Remote code execution via ND6 Router Advertisements
A critical vulnerability in FreeBSD allows for remote code execution. But an attacker must be on the same network.
https://www.freebsd.org/security/advisories/FreeBSD-SA-25:12.rtsold.asc

NIST Time Server Problems
The atomic ensemble time scale at the NIST Boulder campus has failed due to a prolonged utility power outage. One impact is that the Boulder Internet Time Services no longer have an accurate time reference.
https://tf.nist.gov/tf-cgi/servers.cgi
https://groups.google.com/a/list.nist.gov/g/internet-time-service/c/o0dDDcr1a8I

Podcast Transcript

 Hello and welcome to the Monday, December 22nd, 2025
 edition of the SANS United Storm Center's Stormcast. My
 name is Johannes Ulrich and today I'm recording from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Gratis Certificate Program in
 Cybersecurity Leadership. In diaries this weekend, we had
 one by Didier. That's a follow -up to one last week from
 Xavier. Xavier wrote about the DLL entry points. Now what the
 Didier is writing here about is TLS. When I saw it first I
 thought well must be something encryption related. No, TLS
 here stands for Threat Local Storage and that's essentially
 some environment variables and such that can be passed to the
 particular executable that are kept locally for that
 executable. Didier explains how usually this is used for like
 no full-blown executables but Didier did in some tests with
 DLLs and since DLLs are really just PE files, well it works
 there as well and can be used to execute code before the
 main function actually executes. So that is easily
 then overlooked when you're doing some static analysis of
 malicious code. Interesting post and again if you're doing
 reverse analysis of Windows malware definitely worth the
 read. And then we do have what I would probably consider a
 critical vulnerability in FreeBSD. The problem here is
 that an attacker who is connected to the same network
 as the victim may be able to accomplish arbitrary code
 execution. The problem here are IPv6 router advertisements
 and your system, your FreeBSD system as other operating
 systems will likely listen for these router advertisements
 even if you have not implemented IPv6. So you may
 be vulnerable even if IPv6 is not implemented on your
 network. Router advertisements, well in their
 simplest form are just used to tell you who is the router,
 can then be used also to assign addresses, can also be
 used to assign DNS information. So it's kind of
 like in its full form like sort of a DHCP light. Well the
 problem here is that as part of the DNS information you
 also get a list of domains that you can search and well
 these are then used without any input validation since
 that data is being passed to a shell script in order to
 update the network configs. So if you have a configuration on
 the system you can achieve arbitrary code execution by
 sending crafted domain names. So a relatively
 straightforward exploit in that sense. Patches are
 available for FreeBSD. I bet that the people who are most
 worried about this are the ones that run FreeBSD based
 firewalls. The two probably most popular examples here are
 OpenSense and PFSense. OpenSense has released an
 update to its firmware. There is a patch available for
 PFSense or at least of a configuration change that you
 can make. We'll refer to their announcement for any details.
 This is something that I call it critical but you may not
 consider it critical. It really depends on how secure
 you consider sort of your local network. There's also
 some other things that you can do on the network layer like
 some switches for example have router advertisement guard
 which allows you to limit router advertisements to
 routers. So in that case well an attacker would first have
 to compromise the router in order to then send these
 router advertisements which of course you probably have other
 problems if the attacker already has that kind of
 access to your router. Well then we have a little bit of
 an odd curious thing happening with the NIST time service. It
 turns out that the Colorado Boulder Colorado area has had
 some high winds last week and the facility in Boulder has
 had no utility power since Wednesday. As it can happen
 with generators if they are running for a few days like
 this. Well some of the generators did develop
 problems and had to be shut down and as a result they are
 worried that they may not be able to maintain the time
 servers in the Boulder facility with an accurate
 time. So they are considering now blocking access to these
 time servers. Last I checked they were still up and running
 and they still were sort of working within tolerances. But
 this is again one of those little weak points of the
 internet. Now luckily Boulder Colorado isn't the only
 facility they have. They also have one in Fort Collins and
 then in Gatorsburg Maryland at the NIST headquarters. So
 shouldn't really have any sort of permanent impact or time is
 not lost. But definitely something to keep in mind you
 should never really sync directly with the NIST time
 servers but also always with some other public time servers
 like the NTP pool. Well and that's it for today so thanks
 again for listening. This will likely be the only podcast for
 this week unless some exciting new story that's worth
 covering sort of is developing then I may do a quick one. But
 the next podcast will likely happen a week from today.
 Thanks and talk to you well in a week. Bye.
 Bye.