Opened 14 months ago

Closed 13 months ago

Last modified 13 months ago

#1535 closed defect (fixed)

Code execution vulnerability if smartd uses 'mail' from GNU mailutils < 3.13

Reported by: ox3l Owned by: Christian Franke
Priority: critical Milestone: Release 7.3
Component: smartd Version:
Keywords: security Cc:

Description

Dear smartmontools,

I'm Leonardo, a security researcher based in Italy, Rome.

I would be able to notify abuot a security issue that i found out on smartmontools software, and before to proceede with details and a secure disclosure i want to ensure that this is the right place where to post about this topic.

Thanks for your time and let me know how to move further,

Best regards,
Leonardo

Change History (6)

comment:1 Changed 14 months ago by Christian Franke

Keywords: bug vulnerability removed
Milestone: undecided

comment:2 Changed 13 months ago by Christian Franke

Milestone: undecidedRelease 7.3
Owner: set to Christian Franke
Status: newaccepted

Detailed problem description received by private mail - thanks!

Description and possible fixes will be published soon. Attack surface is IMO very small.

comment:3 Changed 13 months ago by Christian Franke

Summary: Security Issue on smartmontools - smartdCode execution vulnerability if smartd uses 'mail' from GNU mailutils < 3.13

A mail (or mailx) tool usually supports command escapes like ~! command during input mode. This is required by POSIX and its predecessors. GNU mailutils < 3.13 processes command escapes also if used non-interactively.

Preconditions:

  • Warning emails are enabled in smartd.
  • The default message text is used or $SMARTD_DEVICEINFO is expanded in a custom message.
  • mail from GNU mailutils < 3.13 in its default configuration is used to send mail.

Exploit: A device with modified firmware is connected. The device returns \n~! command as part of its device identify information strings (model, firmware, serial number). The leading linefeed is not needed for ATA and NVMe model names. Various length limitations apply.

When smartd sends a warning email for this device, the mail command executes command in a shell with root privileges.


It is not yet known whether the following RCE would also be possible: If a command which prints the name of the lokal DNS or NIS domain (domainname, dnsdomainname, nisdomainname, hostname -d, hostname -y) uses networking, it may be possible to remotely modify its output accordingly.

comment:4 Changed 13 months ago by Christian Franke

A system is affected if the command below prints ALERT to the standard output instead of sending ~! echo ALERT as the second line of the mail:

printf 'test:\n~! echo ALERT\nbye!\n' | mail admin@domain.local

It is recommended to fix this independently from smartmontools as other tools using mail may also be affected (see for example CVE-2021-32749).

This could be done with any of the following methods:

  1. Disable command escapes globally:
    sudo echo unset escape >> /etc/mail.rc
    
  1. Disable command escapes for root user only:
    sudo echo unset escape >> /root/.mailrc
    
  1. Upgrade to GNU mailutils 3.13 or later.
  1. Install an alternative package providing mail functionality, for example (bsd-)mailx`.

If none of the above is applicable, any of the following methods fixes it for smartmontools only:

  1. Apply patch r5238 to the local smartd_warning.sh script. See -w option in smartd -h output for the configured path. The patch is backward compatible to smartmontools since 6.1.
  1. Add a wrapper script which runs mail with command escapes disabled, for example:
    /path/to/mail-unset_escape:
    #!/bin/sh
    exec /usr/bin/mail -E 'unset escape' "$@"
    
    /etc/smartd.conf:
    DEFAULT ... -m admin@domain.local -M exec /path/to/mail-unset_escape
    ...
    
  1. Install a CI release of smartmontools r5238 or later. See https://builds.smartmontools.org for source tarballs and various binaries. Note that the Windows version of smartmontools is not affected.

comment:5 Changed 13 months ago by Christian Franke

Resolution: fixed
Status: acceptedclosed

Fixed in r5238. See above comments for details.

comment:6 Changed 13 months ago by Christian Franke

Replying to Christian Franke:

It is not yet known whether the following RCE would also be possible: If a command which prints the name of the lokal DNS or NIS domain (domainname, dnsdomainname, nisdomainname, hostname -d, hostname -y) uses networking, it may be possible to remotely modify its output accordingly.

The Debian version of hostname, which is also used on Ubuntu and other Linux distros, works as follows:
The command hostname -d and its alias dnsdomainname print the domain part of the FQDN which is printed by hostname -f. The FQDN is obtained from addrinfo.ai_canonname returned by getaddrinfo(name, ...) with name set from gethostname() result.

If glibc is used, networking is not used if hosts: files ... is configured in /etc/nsswitch.conf and an entry for the own hostname (like 127.0.1.1 hostname.some.domain hostname) exists in /etc/hosts.

Otherwise getaddrinfo() may issue DNS queries for the A and AAAA records of hostname.search.domain for all search.domain entries in the search ... list in /etc/resolv.conf. If a query succeeds, hostname.search.domain is returned as addrinfo.ai_canonname. The hostname -d command prints search.domain then, otherwise nothing is printed. The possibly printed strings could not be changed via forged DNS replies.

If DHCP is used, it is possible to modify /etc/resolv.conf remotely. This would also modify the hostname -d output accordingly. But an exploit via smartd warning emails would require a linefeed an a space (or tab) as part of the domain name. This should be not possible as the /etc/resolv.conf parser does not interpret any quoting for domain name strings.

Note: See TracTickets for help on using tickets.