#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 by , 3 years ago
Keywords: | bug vulnerability removed |
---|---|
Milestone: | → undecided |
comment:2 by , 3 years ago
Milestone: | undecided → Release 7.3 |
---|---|
Owner: | set to |
Status: | new → accepted |
comment:3 by , 3 years ago
Summary: | Security Issue on smartmontools - smartd → Code 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 by , 3 years ago
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:
- Disable command escapes globally:
sudo echo unset escape >> /etc/mail.rc
- Disable command escapes for root user only:
sudo echo unset escape >> /root/.mailrc
- Upgrade to GNU mailutils 3.13 or later.
- 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:
- Apply patch r5238 to the local
smartd_warning.sh
script. See-w
option insmartd -h
output for the configured path. The patch is backward compatible to smartmontools since 6.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 ...
- 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 by , 3 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Fixed in r5238. See above comments for details.
comment:6 by , 3 years ago
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.
Detailed problem description received by private mail - thanks!
Description and possible fixes will be published soon. Attack surface is IMO very small.