I thought I’d blog today because of the interest that some Internet users are showing in a so-called vulnerability in KIS 6.0.
We know that there’s a glitch in the handling of specially crafted HTTP requests. And we’ll be putting out a hotfix to correct it.
However, whether this is really a vulnerability - much less a critical one, as was announced on certain discussion lists on the Internet - is another question. Calling it a critical vulnerability isn’t really accurate - the only malicious action that this vulnerability can be used for is the download of a malicious program. Although this file, when downloaded, bypasses the Web antivirus monitor, the file is detectable by our products, and cannot be activated once downloaded.
Added to this, we know that the most commonly used browsers such as Internet Explorer, Mozilla Firefox and Opera never send requests to servers in this form. A request crafted in this way can only be launched outside the browser by another malicious program, one which we classify as a Trojan-Downloader. Such a combination of circumstances is extremely unlikely. However, even if the malicious file is downloaded successfully, it doesn’t present any serious threat the user as it will be blocked by other KIS 6.0 modules.
It’s great that this loophole has been identified. But I’m a bit surprised at the way in which it was made public. Surprising, because everyone - including the original poster - in the security world should be aware of the unwritten rules of vulnerability disclosure: when a vulnerability is detected, the developers of the affected software should be informed BEFORE details of the vulnerability are made public. The developers then usually have at least 7 days to respond and/or patch the error before the vulnerability is disclosed to the public. The person who posted information about the HTTP handling issue on the internet didn’t contact us first. As I said above, this is surprising, and even a bit depressing.
So, a message to all our blog readers: if you find glitches, vulnerabilities, or anything untoward in any Kaspersky Lab products - contact us! It’ll help us fix the issue quicker, and ensure that you remain protected.
Recently the media has been paying some attention to the 'magic byte' vulnerability disclosed by Andrey Bayora.
The vulnerability advisory basically states that the majority of virus scanners are unable to detect some malware if a fake file header is prepended to the malicious file.
This more or less boils down to script-like malware, such as .bat and .html, going undetected if an MZ header, for instance, is prepended to the file. Most virus scanners seem to assume that such a file is an executable, and will therefore no longer detect the malware.
To circumvent this, you need to do a redundant file check: scan the _entire_ file for file headers/malicious code.
The whole issue gives rise to an interesting discussion: is this actually a vulnerability?
As the (complete) file's hash has been changed, it's no longer exactly the same file. This means that the malicious file is technically a variant, not the same old malware. And this leads to the conclusion that from a technical point of view, this is not a real vulnerability.
Of course, this point of view is open to debate. The question is, does the 'vulnerability' pose a real threat?
I don't think so. Of course, it remains to be seen exactly how this 'vulnerability' will be exploited. But we see repacked malware on a daily basis; this is in some ways a similar case.
As the vast majority of malware these days is in binary form, it would be much more serious if we didn't have unpacking support for the common runtime packers. And naturally, we are working to release a patch for the 'magic byte' vulnerability as I write. Or to look at it from another point of view, we are adding a feature.