Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
At the Virus Bulletin conference this year, there was a talk about the limitations and suggested enhancements for the Early Launch Anti-Malware (ELAM) environment. The main observation, complaint if you will, was that there is no way for an anti-malware (AM) engine to perform a deep scan. However, there is a very good reason for why ELAM does not allow that: it is not meant to.
The purpose of ELAM is exactly to perform black- and/or white-listing of drivers until the full AM engine is loaded as part of the boot process. At that point, the full AM engine can take over and perform deep scanning of everything that loads after it, along with everything that loaded before it which the ELAM driver could not classify. The ELAM driver can make a list of the drivers which it did not recognise, and pass this to the full AM engine.
If for some reason any of those drivers can't be found by the AM engine, then that alone is cause for suspicion, and the driver details can be added to the black-list for blocking on the next reboot.
The ELAM driver has a very restricted environment, in terms of memory and time. However, both of these restrictions exist for performance reasons. The small memory requirement means that only hashes can be used for classifying drivers, but this is fine because there are not that many drivers to classify. There was a question about polymorphic drivers, but this is largely irrelevant - the driver would need to be re-signed after modification, meaning that we could simply block the certificate that was used. A variation of this attack would involve using Return-Oriented Programming (ROP), where a clean driver is loaded for no purpose except to cause a sufficient number of "gadgets" to be present in memory for a second driver to use. This second driver would not be malicious as such, but by constructing a chain of gadgets, it would be possible to create a block of code which can perform malicious actions. However, again, this would appear no different from the polymorphic case, since the second driver would need to re-sign itself after creating the list of gadget offsets in the clean driver.
The small time requirement forces the ELAM driver to perform only a hash-based classification, but this is the only form of scanning that is viable at that point anyway. The time restriction is intended to take away the temptation to construct a virtual file system in order to access the file image manually.
So there you have it. ELAM is not intended for deep scanning, and any suggestion that it should be enhanced in such a way that it can be simply misses the point.
Read more about ELAM here.
- Peter Ferrie