Heap buffer underflow and memory corruption in vixie cron used by OpenBSD

cron/entry.c in vixie cron before 9cc8ab1, as used in OpenBSD 7.4 and 7.5, allows a heap-based buffer underflow and memory corruption. NOTE: this issue was introduced during a May 2023 refactoring.

• vixie cron: versions before 9cc8ab1 are identified as affected. Commit 9cc8ab1 is the upstream fix point; the evidence does not map that commit to a specific packaged release.
• OpenBSD 7.4: identified as affected.
• OpenBSD 7.5: identified as affected.
• The advisory limits the described heap underflow condition to 64-bit builds and states that 32-bit builds do not reach the same underflow path. The status of other OpenBSD branches or vixie cron packages is not established by the available evidence.

The flaw is in cron/entry.c, in range and step handling introduced during a May 2023 refactoring. The set_range() function uses an attacker-controlled step value in a loop and passes the resulting index to bit_set(). A very large numeric value can be interpreted as a negative integer by atoi() on 64-bit builds, causing the index to move before the heap-allocated bits region and produce an out-of-bounds write and memory corruption. The advisory states that the condition affects both the cron daemon and the crontab command, while 32-bit builds do not reach the same underflow path. The supplied record assessment describes network reachability with no required privileges or user interaction, but the advisory does not identify a specific network protocol or service path. The practical remote entry path and the reliability of turning the memory corruption into code execution therefore remain deployment-dependent.

• The public advisory contains a proof of concept and exploitation analysis for OpenBSD, and the supplied record marks public exploit material as available.
• The record assessment describes network reachability, low complexity, no required authentication or privileges, and no user interaction. The technical examples, however, focus on processing data through crontab and the cron daemon rather than naming a specific network protocol.
• The advisory states that obtaining root is possible, but describes the issue as potentially exploitable and dependent on heap layout, ASLR, and process conditions. The available evidence does not establish a reliable end-to-end remote exploit or exploitation in the wild.

Memory corruption occurs when an abnormal step causes bit_set() to index before the heap-allocated bit string. The direct result may be a process crash or corruption of nearby heap data; the advisory also describes a memory-write primitive. With a suitable heap layout, the corruption may alter structures used by cron to execute commands and may enable privilege escalation to root. The available evidence limits the demonstrated impact to the affected host and processes; it does not establish automatic spread to other hosts. The final outcome depends on architecture, heap layout, ASLR, and exploit reliability.

• cron may crash or process schedule data incorrectly, disrupting recurring jobs; the advisory notes that OpenBSD does not automatically restart the daemon after a crash.
• If the memory corruption is successfully controlled, an attacker may alter process state and potentially obtain root, affecting scheduled jobs, local configuration, and local data.
• The issue affects both the crontab processing path and the cron daemon, so updating only one component without checking the other may leave exposure.
• The evidence does not show that every trigger results in privilege escalation; reliability depends on architecture, heap layout, and host conditions.

1. Upgrade or rebuild vixie cron from source that includes commit 9cc8ab1. The fix rejects negative results from atoi() in get_number() and handles step <= 1 or step > stop in set_range() before operating on the bit string.
2. For affected OpenBSD deployments, install an OpenBSD update containing the corresponding fix or rebuild the cron component from corrected source. The evidence does not identify an exact fixed OpenBSD release, so do not assume that every later release or parallel branch is covered.
3. If an update is not immediately possible, restrict untrusted writes or inputs to crontab and cron database data and assess temporary reduction of exposure for the affected processing paths. This is risk reduction, not a substitute for the fix.
4. After deployment, verify the actual binary or source tree contains the relevant checks and review package overlays, backports, and internal builds. No separate mitigation equivalent to the code fix was confirmed by an authoritative source.

1. Inventory OpenBSD systems and vixie cron builds, recording the package revision or source commit included in each deployment.
2. Determine whether the cron and crontab binaries are 64-bit; the advisory limits the described underflow condition to 64-bit builds.
3. Inspect the corresponding source or binary to confirm that get_number() rejects negative parsed values and that set_range() safely handles step values less than one or greater than stop.
4. Review crontab files and other schedule inputs for malformed range or step expressions, especially unusually large values. This is a precautionary heuristic, not a confirmed IOC.
5. Review existing telemetry for cron or crontab crashes and failures to restart, along with unexpected changes to scheduled jobs. Absence of these events does not prove that a system is safe.