
SANS Internet StormCast
SANS Stormcast Monday, December 22nd, 2025: TLS Callbacks; FreeBSD RCE; NIST Time Server Issues
AI Summary
The episode covers three security topics: TLS callbacks (Thread Local Storage) used by malware to execute code before a program's main function, a critical FreeBSD remote code execution flaw in the rtsold daemon that parses unsanitized DNS search lists from IPv6 router advertisements, and an outage at NIST's Boulder time server affecting accurate time distribution. Key takeaways include the need to examine TLS callbacks during malware analysis, disabling or patching rtsold (or using RA‑guard) to mitigate the FreeBSD RCE, and relying on multiple NTP sources rather than a single NIST server during infrastructure disruptions. Host Johannes Ullrich emphasizes practical mitigations such as updating firewalls like OPNsense/pfSense and diversifying time synchronization sources.
Episode Description
DLLs & TLS Callbacks
https://isc.sans.edu/diary/DLLs%20%26%20TLS%20Callbacks/32580
https://www.freebsd.org/security/advisories/FreeBSD-SA-25:12.rtsold.asc
https://tf.nist.gov/tf-cgi/servers.cgi https://groups.google.com/a/list.nist.gov/g/internet-time-service/c/o0dDDcr1a8I
Show Notes
SANS Stormcast – Monday, December 22 2025
Title: TLS Callbacks; FreeBSD RCE; NIST Time Server Issues
Handler on Duty: Johannes Ullrich
Published: Mon Dec 22 2025 20:53
DLLs & TLS Callbacks
As a follow‑up to last week’s diary about DLL entry points, Didier looks at TLS (“Thread Local Storage”) and how it can be abused.
Original diary: 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 remote code execution, but an attacker must be on the same network.
Advisory: 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 failed due to a prolonged utility power outage. Consequently, the Boulder Internet Time Services no longer have an accurate time reference.
Details: https://tf.nist.gov/tf-cgi/servers.cgi
Discussion thread: https://groups.google.com/a/list.nist.gov/g/internet-time-service/c/o0dDDcr1a8I
Discussion
Question: With the FreeBSD issue, do you need to be specifically running the user‑land daemon rtsold?
Answer (Claude & Gemini):
The key section is in “IV. Workaround”:
Users not using IPv6, and IPv6 users that do not configure the system to accept router advertisement messages, are not affected. A network interface listed by
ifconfig(8)accepts router advertisement messages if the stringACCEPT_RTADVis present in the nd6 option list.
However, this is slightly misleading in isolation. The vulnerability is specifically in rtsold(8) and rtsol(8)—the user‑land daemons that process router advertisements and pass DNSSL options to resolvconf(8). The kernel’s ACCEPT_RTADV flag only tells the kernel to process RAs for SLAAC address configuration.
Why you’re safe if rtsold isn’t running:
-
rtsoldis not running – you confirmed this. The vulnerable code path is inrtsoldparsing the DNSSL (Domain Search List) option from RAs and passing it unsanitized toresolvconf(8). -
Manual IPv6 configuration – you don’t need
rtsoldat all. -
ACCEPT_RTADVflag – indicates the kernel will accept RAs for basic SLAAC, but withoutrtsoldrunning the dangerous DNSSL‑to‑resolvconfshell‑injection path does not exist.
Gemini’s summary:
Based on FreeBSD‑SA‑25:12.rtsold, the short answer is: No, your system is likely not vulnerable if the
rtsolddaemon is not running.
Breakdown:
-
Vulnerability location:
rtsold(andrtsol) fail to validate DNS Search List options inside IPv6 Router Advertisements before passing them to theresolvconfscript, allowing shell‑command injection. -
Kernel vs. daemon:
-
Kernel (
ACCEPT_RTADV) – only handles address configuration; ignores DNS options. -
Daemon (
rtsold) – processes DNS options and writes to/etc/resolv.conf. Without it, the malicious payload is never executed.
-
-
Conclusion: As long as
rtsoldis not running and you do not manually invokertsol, the RCE vector does not exist on your machine, even if the kernel accepts RA packets.
Recommendation: Verify rtsold is not running:
service rtsold status # should return “rtsold is not running”
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. 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 – a follow‑up to last
week’s entry from Xavier about DLL entry points. Didier writes about
TLS. When I first saw it I thought it must be something encryption
related. No – TLS here stands for Thread Local Storage, essentially
environment variables that can be passed to a particular executable
and kept locally for that executable. Didier shows how this can be
used with DLLs (which are just PE files) to execute code before the
main function runs – a detail easily missed in static analysis of
malware.
Next, a critical vulnerability in FreeBSD: an attacker on the same
network can achieve arbitrary code execution via IPv6 router
advertisements. Even systems without IPv6 enabled may listen for these
advertisements. Router advertisements can convey DNS information,
including a Domain Search List (DNSSL). The DNSSL is passed unsanitized
to a shell script that updates network configuration, allowing an
attacker to inject commands.
Patches are available. The most affected users are likely those
running FreeBSD‑based firewalls such as OPNsense and pfSense. OPNsense
has released a firmware update; pfSense has a configuration change
available.
Mitigations include disabling the `rtsold` daemon (as discussed
above) or using router‑advertisement guard features on switches to
limit RAs to legitimate routers.
Finally, an odd issue with the NIST time service: high winds in
Colorado caused a prolonged power outage at the Boulder facility.
Generators ran for several days and began to fail, raising concerns
that the Boulder time servers might lose accurate time. NIST is
considering blocking access to those servers. The Boulder site is
still up, but the situation highlights a weak point in the Internet
time infrastructure. NIST also operates sites in Fort Collins and
Gainesville, MD, so the impact should be limited. As always, never
sync directly only to NIST servers; use the NTP pool or other public
servers as well.
That’s all for today. Thanks for listening. This will likely be the
only podcast this week unless a new story emerges. The next episode
should be a week from now.
Thanks and talk to you in a week. Bye.
Posted by [protected email] on Mon Dec 22 2025 20:53
Comments
Want to join the conversation?
Loading comments...