Re: PCI vulnerability scan - PHP4 on Sarge
Actually, the problem is the outside party that was hired to
run nessus and then not removing false positives. ( or in rare cases
they use a commercial product but after using a few different companies
to do scans in my experience they use nessus as the commercial products
have licenses that are hard to use as a third party.)
Most of these scans rely on versions of installed products, and
often use the banner provided by the software.
So there are almost always false positives.
This happens with stable versions of debian frequently as fixes are
often added but newer version of software are not backported.
Whomever is doing your scan needs to provide which CVEs that
are the problem and then you can show they have false positives by
looking at the CVEs that have been fixed in the version you are running.
You need to show them that you have policies in place to do routine
updates within 30 days of the Vendor (Debian) announcing a fix.
You also need to show that you actually follow the policies that you
have in place.
On Tue, Dec 18, 2007 at 10:06:03PM +0100, Moritz Muehlenhoff wrote:
> William Chipman wrote:
> > We had a scan of our systems for PCI compliance and received warnings
> > about PHP 4.4.3-10-22.
> > I checked the archives and found that the following CVE reports were not
> > covered by the comments
> > leading up to 4.4.3-10-22:
>
> I verified your list:
> Almost all of these are no security issues by the security policy for
> PHP, see below. For one or two (harmless) issues an update is in preparation.
>
> A similar policy is in place for the other major Linux enterprise distribution;
> Red Hat Enterprise Linux.
>
> If the payment card industry wishes to discuss there requirements with us,
> they can contact us at team@security.debian.org
>
> --
> The Debian stable security team does not provide security support
> for certain configurations known to be inherently insecure. Most
> specifically, the security team will not provide support for flaws in:
>
> - problems which are not flaws in the design of php but can be problematic
> when used by sloppy developers (for example, not checking the contents
> of a tar file before extracting it)
>
> - vulnerabilities involving register_globals being activated, unless
> specifically the vulnerability activates this setting when it was
> configured as deactivated
>
> - vulnerabilities involving any kind of safe_mode or open_basedir
> violation, as these are security models flawed by design and no longer
> have upstream support either
>
> - any "works as expected" vulnerabilities, such as "user can cause php
> to crash by writing a malcious php script", unless such vulnerabilities
> involve some kind of higher-level DoS or privilege escalation that would
> not otherwise be available.
> --
>
> Cheers,
> Moritz
>
>
>
> --
> To UNSUBSCRIBE, email to debian-security-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: