PCI Compliance vendor Control Scan is complaining about our InterWorx qmail package.
Summary:
Possible Vulnerability In Qmail
Details:
The vulnerability can be exploited to crash the current SMTP process
and cause denial of service by consuming resources.
It is theoretically possible, though considered unlikely, that an
attacker could execute arbitrary code.
Solution:
On 32-bit platforms, [http://www.qmail.org] upgrade to
[http://www.qmail.org/netqmail/] netqmail 1.05 or later.
netqmail consists of Qmail 1.03 and important patches.
On 64-bit platforms, upgrade to netqmail 1.06 or later,
which will presumably contain a fix, when available.
The InterWorx qmail RPM’s description says:
qmail is a small, fast, secure replacement for the sendmail package, which is the program that actually receives, routes, and delivers electronic mail.
This package is patched to netqmail-1.05 distribution of qmail. It is comprised of qmail-1.03 plus a patch file, some documentation, and a shell script which prepares the files for compilation. More information is available
at netqmail
Why does InterWorx’s qmail still report v1.03? Can the version number be updated?
Why does InterWorx’s qmail still report v1.03? Can the version number be updated?
I’m curious how the pci scan is determining the version. Is it really just looking at the RPM name? Are they actually detecting a problem? Would they prefer a RPM name of qmail-1.05? There’s really no such thing. netqmail is just a series of patches to qmail-1.03, which our build also happens to include. Our build also includes a number of other patches above and beyond what netqmail does, so it would be just as much a misnomer to call it “netqmail.” Perhaps the best thing to do would be to rename our package to iworxqmail, to clearly distinguish it from the base qmail 1.03, or netqmail, etc. I don’t know if that would make PCI scanners any happier or not though.
They don’t have access to RPM, only external scanning. I think they are using service detection, detecting qmail, and assuming v1.03 since that is the newest version. Therefore updating won’t fix anything except for satisfying the requirements for an exception. For example, we could point them to the InterWorx RPM repo and they would see the version they want to see.
Btw, we are very frustrated by this, too. Our other PCI compliance vendor, Security Metrics, simply flags this issue as a possible problem, but Control Scan completely fails our client over this. They wouldn’t accept your detailed RPM description either. :mad: