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

SANS Internet StormCast

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

SANS Internet StormCastDec 22, 2025

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 string ACCEPT_RTADV is 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:

  1. rtsold is not running – you confirmed this. The vulnerable code path is in rtsold parsing the DNSSL (Domain Search List) option from RAs and passing it unsanitized to resolvconf(8).

  2. Manual IPv6 configuration – you don’t need rtsold at all.

  3. ACCEPT_RTADV flag – indicates the kernel will accept RAs for basic SLAAC, but without rtsold running the dangerous DNSSL‑to‑resolvconf shell‑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 rtsold daemon is not running.

Breakdown:

  • Vulnerability location: rtsold (and rtsol) fail to validate DNS Search List options inside IPv6 Router Advertisements before passing them to the resolvconf script, 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 rtsold is not running and you do not manually invoke rtsol, 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...