then the conclusion is that the marketplace does not value security highly when choosing an operating system.

When it comes to launching online attacks, criminals are getting more organised and branching out from the Windows operating system, says eBay's security chief.

eBay recently did an in-depth analysis of its threat situation, and while the company is not releasing the results of this analysis, it did uncover a huge number of hacked, botnet computers, said Dave Cullinane, eBay's chief information and security officer, speaking at a Microsoft-sponsored security symposium at Santa Clara University. ...

Last week eBay said data on 1,200 eBay members had probably been stolen via an phishing scam.  The members' data was posted to the company's Trust & Safety discussion forum.

Cullinane's experience with phishing goes back to his previous employer, Washington Mutual, which has been one of the top phishing targets in the US.

While there, he noticed an unusual trend when taking down phishing sites.

"The vast majority of the threats we saw were rootkitted Linux boxes, which was rather startling.  We expected Microsoft boxes," he said.

Rootkit software covers the tracks of the attackers and can be extremely difficult to detect.  According to Cullinane, none of the Linux operators whose machines had been compromised were even aware they'd been infected. ...

"We see a lot of Linux machines used in phishing," said Alfred Huger, vice president for Symantec Security Response.  "We see them as part of the command and control networks for botnets, but we rarely see them be the actual bots.  Botnets are almost uniformly Windows-based."

Since Linux machines can be used to more easily create specially crafted networking packets, they can be used in highly sophisticated online attacks, said Iftach Amit, director of security research with Finjan's malicious code research centre.

Capabilities like this make Linux machines highly coveted by online attackers, and they fetch a premium in the underground marketplace for compromised machines, Amit said.

Past analyses have been criticized saying that you don’t count issues that Microsoft finds internally and “silently” fixes, so comparisons are invalid. This is an interesting line of thinking to me. It is true that I don’t know if any vendors’ product updates address more security issues than is documented. There’s no way to know things that haven’t been discussed publicly.

For example, I have no idea how many security vulnerabilities were found by the Apple Quality Assurance team during the release of Leopard and were simply fixed. Further, I don’t know how many “bugs” were found and fixed without anyone, even on their team, knowing their might have been security implications if it had not been found. This is equally true for Linux distributions. I don’t know how many “bugs” fixed during the development process for rhel4 Update 5 might have had a security implication.

In terms of enumerating vulnerabilities though, there are specific examples that I can point to that indicate that silent fixes sometimes happen. Take CVE-2007-5959, for example. It is a single vulnerability identifier, but the description says “multiple unspecified vulnerabilities”. I would count that only a single time in my analyses though, since there is only a single CVE identifier. Similarly, CVE-2004-1057, says that “multiple drivers in Linux kernel” do not properly mark memory and enable a denial of service. I would only count this as a single issue in any analysis, though technically there are an additional number of vulnerabilities silently fixed. These products are getting the “benefit” of the issues that are not detailed in any analysis.

On the other hand, I can say that in Microsoft security updates, the MSRC policy is to document any internally found vulnerabilities that change the risk assessment or severity of an externally found vulnerability, or ones where the mitigations and workarounds listed don’t apply. So, by counting the issues that get publicly disclosed for products I’m using an identifiable set of vulnerabilities that have an increased risk for customers.

More generally, if a theoretical “silent fix” (in any product) actually is easily rediscoverable and is proven to be so for any vendor’s product, then it will join the publicly disclosed set of vulnerabilities in due course and can be measured as well.

Ultimately, I see the so-called “silent fixes” criticism to be a bit of a Red Herring that distracts readers from the core results of the analysis of publicly disclosed vulnerabilities.

Any thread Pleo joins is likely to see 5 pages