Crash (buffer overflow detected) in processFileDelete: unchecked m_Extensions[FD_Sid] length in memcpy

Offen
#252 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
72/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
c, linux
Bereich
backend, security

Rechercherichtung

Start with processFileDelete() in sysmonforlinux.c around line 707, where the issue identifies the unchecked FD_Sid copy; inspect how the received perf record and extension lengths are represented. Check whether other process* handlers make similar copies, as the report suggests. Done means invalid lengths are rejected safely so a malformed event cannot abort Sysmon; the issue does not name a test.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Summary

sysmon aborts with *** buffer overflow detected *** (SIGABRT) in processFileDelete(). The length passed to memcpy comes straight from the event's m_Extensions[FD_Sid] and is not validated. In the core dump below, that length is 16,779,777 bytes (0x1000a01), while the destination is the 64 KiB stack buffer newData.

Environment

  • SysmonForLinux 1.5.3, sysinternalsebpf 2.2.2 (Microsoft apt packages)
  • Proxmox VE 9.2 (Debian 13 based), kernel 7.0.14-4-pve, x86_64
  • ZFS root, with ZFS replication received regularly (zfs recv, mass file deletions)

Frequency

The crash happened 6 times on one host over ~3 weeks. It never happened on two identical nodes with the same config. The affected node is the one that receives the most ZFS replication traffic, so the trigger looks related to heavy unlink activity.

Config

FileDelete was not logged at all. The config only had an empty group:

<RuleGroup name="" groupRelation="or">
  <FileDelete onmatch="include"/>
</RuleGroup>

Even an empty include group activates the unlink/unlinkat tracing (SetSyscallActive), so processFileDelete() runs for every delete. Removing the FileDelete group completely works around the problem, because FileDelete has no rule default.

Backtrace (systemd-coredump + gdb)

#4  __fortify_fail () from libc.so.6
#5  __chk_fail () from libc.so.6
#6  memcpy (__len=16779777, __src=<optimized out>, __dest=0x7ffcc99d9b08) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#7  processFileDelete (eventHdr=0x7ea31742a3ac) at /__w/1/s/SysmonForLinux/sysmonforlinux.c:707
#8  perf_buffer__process_record (e=<optimized out>, ctx=<optimized out>) at libbpf.c:13999
#9  perf_event_read_simple (mmap_mem=..., mmap_size=67108864, ...) at libbpf.c:13625
#10 perf_buffer__process_records (...) at libbpf.c:14021
#11 perf_buffer__poll (pb=..., timeout_ms=1000) at libbpf.c:14046
#12 telemetryStart (...) at /__w/1/s/sysinternalsEBPF/telemetryLoader.c:1586
#13 main (...) at /__w/1/s/SysmonForLinux/sysmonforlinux.c:1736

Line 707 in the 1.5.3 tag is:

memcpy(newPtr, ptr, event->m_Extensions[FD_Sid]);

Suggested fix

In processFileDelete(), check the extension lengths (FD_Sid, FD_FileName, FD_ImagePath) before copying:

  • their sum must fit into newData minus the header and struct size;
  • it must not exceed the size of the received perf record.

If the check fails, drop the event and log it instead of aborting the whole service. The same pattern may be worth checking in the other process* handlers that copy extension data.

I can provide more details from the core dump if useful.

Vorherrschende Sprache
C
Sterne
2.2k
Forks
224
Ø Merge
4 Std. 50 Min.
Gemergte PRs (30 T.)
3

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus microsoft/Sysmon-Linux

Alle Issues in microsoft/Sysmon-Linux

Ähnliche Issues

Weitere Issues zu C

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.