timecrime errata

Author: hackerhouse-opensource

timecrime.c

@@ -11,12 +11,9 @@
  * and incorrectly reported as vulnerable without proper verification. In some
  * systems, hosts can leak information of value to attackers.
  *
- * Hosts with randomized timestamps are protected from such attacks, while others
- * may expose detailed system uptime and time information that attackers can use in
- * subsequent attacks. Attack scenarios could include hosts that use system time to seed
- * random generators to generate passwords as an example, testing when a system rebooted
- * to understand maintenance cycles, automated patching, testing if a kernel panic DoS
- * was successful and lastly fingerprinting with systems exposed behind NAT.
+ * Hosts with *true* per-packet randomized timestamps are protected. Linux
+ * with net.ipv4.tcp_timestamps=1 is *not* — it applies a random offset per
+ * connection, but the counter remains strictly monotonic at ~1000 Hz.
  *
  * The tool sends TCP SYN packets with timestamp options to target hosts and
  * analyzes the returned timestamp values to determine:
@@ -42,20 +39,30 @@
  * Environment Variables:
  * DEBUG=1 Enable packet-level hex dump tracing
  *
- * Linux Kernel TIMECRIME attack
- * =============================
- * Linux sysctl can be 0 - disable, 1 - randomized, 2 - insecure.
- * e.g. "sudo sysctl -w net.ipv4.tcp_timestamps=2" to test PoC.
+ * LINUX TIMECRIME KERNEL VULNERABILITY (net.ipv4.tcp_timestamps=1)
+ * ================================================================
+ * Linux sysctl values:
+ *  0 = disabled (secure, no leak)
+ *  1 = "randomized" (default) BROKEN
+ *  2 = monotonic (insecure)
  *
- * We have noticed that on some Linux distributions net.ipv4.tcp_timestamps=1
- * (the "randomized" default) DOES NOT RANDOMIZE PER-CONNECTION on real kernels.
- * Tested on DigitalOcean using kernel 6.12.48, Debian 13, 2025-11-07. Identical
- * monotonic 1000 Hz curve is seen with both 1 or 2 set. RFC 7323 §3.2 requires
- * per-connection jitter — Linux appears to ignore it.
+ * Contrary to documentation and RFC 7323 §3.2, mode 1 does *not* prevent
+ * uptime disclosure. A random offset is added per connection, but:
+ *  * The base counter is jiffies-based and monotonic
+ *  * Increment = ~1000 ticks/sec (HZ)
+ *  * Uptime = (last_TSval - first_TSval) / 1000 → accurate
  *
- * Impact: Any Internet-facing Linux box leaks exact boot time and OS fingerprint to
- * an unauthenticated attacker despite intending to randomize the data.
- * CVSS 5.3  (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N)
+ * Tested on kernel 6.12.48 (Debian 13, DigitalOcean, 2025-11-07):
+ *   Even with =1, PoC reports precise uptime and 1000 Hz clock.
+ *
+ * Impact:
+ *  * Remote, unauthenticated uptime/boot-time disclosure
+ *  * OS fingerprinting (1000 Hz → modern Linux)
+ *  * Patch cycle tracking, DoS validation, VM reuse detection
+ *
+ * CVSS: 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N)
+ *
+ * Reported to [email protected] 07/11/2025. Only fix: set =0.
  *
  * Author: hackerfantastic
  * Website: https://hacker.house/