Last Updated: 2013-10-25 17:41:34 UTC
by Rob VandenBrink (Version: 1)
One of our readers has alerted us to the fact that Kaspersky AV has identified tcpip.sys as malware on his Windows 7 32bit hosts - the file is flagged as "HEUR:Trojan.Win32.Generic"
Fortunately, Microsoft's Windows File Protection feature ( http://support.microsoft.com/kb/222193 ) prevented it from quarantining this critical file, but his end users were all treated to the error message (both from the AV and from the OS I'm guessing)
His version of Kaspersky is the OEM Checkpoint version, but it appears to be a Kaspersky issue, not Checkpoint specific.
Kaspersky has verified ( https://twitter.com/kaspersky/status/393777843341393920 ) that this is resolved in their latest update. If you're seeing this issue, get your AV to "phone home" for the fix!
Last Updated: 2013-10-25 16:04:06 UTC
by Johannes Ullrich (Version: 1)
Yesterday, it was discovered that the php.net website had been compromised. At this point, the php.net team believes the servers were compromised for several days, and at least one file was altered to deliver malware. The current summary suggests that the attacker may have had access to the servers secret SSL key, which suggests the attacker had root access. 
Probably the most valuable asset present on the php.net site and it's mirrors is the PHP source code distribution which is used by sites worldwide. At this point, there is no indication that the attacker modified the file. But I want to focus on the user downloading a file, like the php source code. How to you verify that the file is authentic and didn't get tampered with?
PHP.net publishes MD5 hashes on its site, that a user may use to verify the binary. Never mind that MD5 isn't the strongest hashing algorithm. It is probably good enough for this purpose. But the real problem is that there is no digital signature. An attacker could swap the source code AND the md5 hash if the attacker has access to the server, and as in this case appeareantly is able to alter files. A digital signature would be created using a secret key FAR removed from the server, maybe even kept offline. This way, an attacker would be able to change the signature, but not using the authorized key, and an end user bothering to verify digital signatures would have a fighting chance to detect the compromise. Sadly, too many projects only use hashes (again: Doesn't matter WHAT hash you use. The can all be replaced).