OpenSSL HollowByte: 11 Bytes to DoS and the Danger of Silent Fixes
Has anyone looked into the 'HollowByte' research released by Okta's Red Team? It's wild that a mere 11-byte TLS handshake fragment can force an OpenSSL server to allocate 131 KB of memory which is subsequently never returned on glibc systems.
The bigger issue here isn't just the DoS potential—it's the methodology. OpenSSL pushed a fix back in June without a CVE, advisory, or changelog. For those of us managing internal build pipelines or compliance checks, 'shadow patching' is a nightmare. If you missed the specific commit, you might think you are compliant when you aren't.
The vulnerability triggers when the server processes a specific TLS message header but the body never arrives, leaving the buffer stranded. On glibc systems, that memory is effectively lost until the process restarts.
Here’s a quick check to see your OpenSSL build date to ensure it includes the June fix:
openssl version -a | grep "built on"
If you are running older builds or relying on distro packages, you need to verify they have backported the fix. This feels like a repeat of the 'Rusty' issues from a few years ago.
How are you guys handling inventory for patches that don't have CVE numbers attached? Are you monitoring commit feeds directly now?
This is exactly why I hate relying solely on CVE feeds for patch management. We actually got bitten by a similar silent patch in OpenSSL last year regarding the padding oracle. We've since started watching the openssl-commits mailing list, but the signal-to-noise ratio is brutal. The 131 KB leak might not sound like much, but on high-traffic load balancers, that adds up to a guaranteed restart cycle within hours.
From a detection standpoint, this is tricky. The packet itself looks like standard TLS junk or a retry, so signature-based IPS might struggle. I'm adding a custom rule to our SIEM to correlate OpenSSL process memory growth (process.memory.usage) with high counts of incomplete TLS handshakes, but that's going to be noisy with scanners on the internet. Anyone found a reliable signature in the packet headers yet?
Interesting angle on the glibc interaction. It really highlights how the allocator behavior creates the 'leak' rather than OpenSSL itself. I tested this on a staging env using a custom Python script, and the memory usage plateaus at max allocation and stays there. It's a slow-burn DoS. Definitely effective against low-resource edge devices like VPN gateways or IoT endpoints running full OpenSSL stacks.
The lack of a CVE creates a massive blind spot for our scanners. To verify if we’re actually patched, I’ve been checking the shared library’s modification date against the June timeline, as version numbers don't always reflect backported security fixes.
You can verify the library date on most Linux distros with:
stat -c %y /usr/lib/x86_64-linux-gnu/libssl.so.1.1
If the date is recent, you’re likely covered. Does anyone have a script to automate this check across heterogeneous environments?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access