-
Notifications
You must be signed in to change notification settings - Fork 662
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework clamd
command protocol (insecure by design)
#1169
Comments
Thanks for that. For the record, some corresponding/related downstreams issues: |
Your proposed solutions (short and long) both seem like valid ideas with one exception:
I agree that remote clients should not be able to scan local files. Unfortunately, Windows lacks the unix/local socket option. Something similar could probably be done with named pipes. That would require some dev work. I also think fd-passing should become the preferred / default way to request file scans when clamd is on the same machine. The Finally, I am not a fan of the current protocol. I recently proposed an extension to allow passing scan options with scan commands in #1165, but it is still limited and difficult to extend. And the scan response lacks the ability to send additional metadata/context about the scan results. I would really overhaul / replace it entirely with something extensible both in the request and the response, while maintaining both the fdpass and streaming capabilities. I vaguely recall some issue with fd-passing on some file systems, however. So if we disabled local-file-scans entirely, that may be problematic. |
Windows does have unix-style sockets for a while now, but TCP clients could also be considered "local" if they connect via localhost, which would allow network clients to connect to the local daemon and still issue commands reserved for local clients. Not sure if Windows supports |
Disclaimer: The described issues are public knowledge since at least 2008 and the Cisco Product Security Incident Response Team (PSIRT) suggested to discuss this openly when I reported the findings as a security issue again in late 2023. So I'll do that now. Yes, this is a duplicate of #922 and #347 but with a wider scope and more details.
Describe the bug
It's not a bug in
clamd
, but a design flaw in the command protocol implemented byclamd
, more specifically a lack of authorization or separation of concerns.Background:
clamd
listens on a local unix socket by default, which is usually world-writeable to allow local users to actually use the daemon and send commands e.g. to scan files.clamd
can also be configured to listen to a TCP socket and provide functionality to network clients (e.g. Mailservers). The protocol is documented here.The problem: Administrative commands (e.g.
SHUTDOWN
,RELOAD
) are not separated from normal user commands (e.g.SCAN
) andclamd
offers no way to restrict administrative commands to authorized users (e.g. just root). Every local user (or network client) can shutdownclamd
, which is not restarted automatically on most Linux distributions, and even if it is, takes a significant amount of time to load signatures and be operable again.Why this is bad: This can obviously be abused by bad actors or malware to disable
clamd
(and on-access scans) before downloading or unpacking malicious payload and avoid detection. To me, this looks like a textbook example of a unprivileged local (or remote) denial-of-service or circumvention-of-security-measures vulnerability with a very low complexity ->CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
(8.6 high). Cisco PSIRT disagreed and closed the report as "works as intended". Twice.More issues:
VERSION
command reveals the exact version string to local users (or network clients) and tells an attacker if known vulnerabilities in the scanning engine could be abused. TheSTATS
command helps an attacker to see if the attack is successful. This information should not be available to unauthorized remote (non-localhost) clients.RELOAD
command causes significant load and also pauses on-demand scanning (not confirmed) for a significant amount of time.clamd
is configured to listen to TCP, a remote attacker could use theSCAN
,CONTSCAN
,MULTISCAN
orALLMATCHSCAN
commands to probe the local file system for existing files or cause high IO and CPU load. There is no reason why a remote (non-localhost) network client should be allowed to issue scans for local files.SHUTDOWN
andRELOAD
commands should not be required at all because both can also be triggered (in a secure way) via signals.How to reproduce
Proposed solution
Short term:
SHUTDOWN
andRELOAD
should be restricted to the local unix socket and root only (or root and the current user of theclamd
process) as already suggested in Check for root user when processing SHUTDOWN command. #347. There is no reason an unprivileged user or even a remote client should be able to issue those commands.SO_PEERCRED
or a similar mechanism to determine the client user context for a local connection (Windows?) should be ignored for now. Implement it for platforms that do support it. Move to a more secure general solution later.SCAN
,CONTSCAN
,MULTISCAN
orALLMATCHSCAN
). I cannot think of any valid use case for this functionality. TheVERSION
command is also risky, but removing that may actually break existing software. Not sure.Long term:
AUTH
command that unlocks administrative commands for the currently connected client (e.g. based on a configurable shared secret and HMAC challenge).The text was updated successfully, but these errors were encountered: