ClamAV

2 Articles

This Week In Security: Filename Not Sanitized, MonikerLink, And Snap Attack!

February 16, 2024 by 7 Comments

Reading through a vulnerability report about ClamAV, I came across a phrase that filled me with dread: “The file name is not sanitized”. It’s a feature, VirusEvent, that can be enabled in the ClamnAV config. And that configuration includes a string formatting function, where the string includes %v and %s, which gets replaced with a detected virus name and the file name from the email. And now you see the problem, I hope: The filename is attacker supplied input.

Where this really gets out of hand is what ClamAV does with this string. execle("/bin/sh", "sh", "-c", buffer_cmd, NULL, env). So let’s talk defensive program design for a minute. When it comes to running a secondary command, there are two general options, system() and the exec*() family of system calls. system() is very simple to use. It pauses execution of the main process and asks the operating system to run a string, just as if the user had typed that command into the shell. While this is very convenient to use, there is a security problem if any of that command string is user-supplied. All it takes is a semicolon or ampersand to break assumptions and inject a command.

To the rescue comes exec(). It’s a bit more complicated to use, requiring the programmer to manually call fork() and wait(). But it’s not running the command via the shell. exec() executes a program directly, totally eliminating the potential for command injection! Except… oops.

Yeah, exec() and related calls don’t offer any security protections when you use them to execute /bin/sh. I suspect the code was written this way to allow running a script without specifying /bin/sh in the config. The official fix was to disable the filename format character, and instead supply it as an environment variable. That certainly works, and that fix is available in 1.0.5, 1.2.2, and 1.3.0.

The real danger here is that we have another case where some hardware appliance manufacturer has used ClamAV for email filtering, and uses this configuration by default. That’s how we get orders from CISA to unplug your hardware, because it’s already compromised. Continue reading “This Week In Security: Filename Not Sanitized, MonikerLink, And Snap Attack!” →

This Week In Security: GoDaddy, Joomla, And ClamAV

February 24, 2023 by 1 Comment

We’ve seen some rough security fails over the years, and GoDaddy’s recent news about a breach leading to rogue website redirects might make the highlight reel. The real juicy part is buried on page 30 of a PDF filing to the SEC.

Based on our investigation, we believe these incidents are part of a multi-year campaign by a sophisticated threat actor group that, among other things, installed malware on our systems and obtained pieces of code related to some services within GoDaddy.

That multi-year campaign appears to goes back to at least October 2019, when an SSH file was accessed and altered, leading to 28,000 customer SSH usernames and passwords being exposed. There was also a 2021 breach of the GoDaddy WordPress environment, that has been linked to the same group.

Reading between the lines, there may be an implication here that the attackers had an ongoing presence in GoDaddy’s internal network for that entire multi-year period — note that the quote above refers to a single campaign, and not multiple campaigns from the same actor. That would be decidedly bad.

Joomla’s Force Persuasion

Joomla has a critical vulnerability, CVE-2023-23752, which is a trivial information leak from a web endpoint. This flaw is present in all of the 4.x releases, up to 4.2.8, which contains the fix. The issue is the Rest API, which gives access to pretty much everything about a given site. It has an authentication component, of course. The bypass is to simply append ?public=true. Yes, it’s a good old “You don’t need to see his identification” force suggestion.

There’s even a PoC script that runs the request and spits out the most interesting data: the username, password, and user id contained in the data. It’s not quite as disastrous as that sounds — the API isn’t actually leaking the administrative username and password, or even password hash. It’s leaking the SQL database information. Though if your database is accessible from the Internet, then that’s pretty much as bad as it could be. Continue reading “This Week In Security: GoDaddy, Joomla, And ClamAV” →