Note that the sophos-discussed technic is in factvery powerful: you can build some code that is apparently inoccuousbecauseit doesnot contain any dangerous code, or call to dangerous OS APIs.
However, if this code can be installed so that it will be able to silently scan any download image or file, just waiting for the file that will contain some valid and encrypted signature, then this code may recognize that signature and choose to extract the relevant attack code from the data, and then run it, even if you have enabled the NX-bit that prevents data to be executed (notably the CPU stack or heap which is commonly targetted by buffer overflows).
Even though the stack or heap remains protected, the "sleeping" background listener may already have enough code to allocate an executable memory block, put the extracted data in it, and then run it. What was apparently a non dangerous image (and that may appear with some minor or nearly invisible garbage noise in the image, comparable to white noise commonly found in photographs or in image scans, or in "antialiased" pixels or sound framesmay still hide enough information to contain arbitrary code.)
The solution for this problem is that the OS should not allow writing in any executable memory fragment, should not allow executing a writable memory fragment, and the API call that changes a writable block into an executable one being contantly monitored by an antivirus looking for dangerous codeinthisdata fragment before it gets a chance to be executed. If the antivirus finds malicious code in the data block, the APIthat transforms a writable block into an executable block will return an error,and the block will remain data, possibly still writable, but not executable.
Additionally the antivirus scanner should list the process as possibly infected, and any further call to change the status of a writable block should be slowed, and the antivirus should signal an alert tothe user about the possibly infected process that should be killed (this would kill the sleeping code that infects it, such as a modified system DLL or system hook). This could be part of the heuristic engine. The suspect part of code that calls the memory status change API should be reported, in order to find and detect it.
Note that in most common applications, there are very little valid code that changes a writable memory block into an executable one. This code is typically found in avery small part of "JIT" compilers (on .net or in a JVM), or in debuggers for programmers, or in program loaders (that change the block read from disk and gives it the permission to run). This code isgenerally completely isolated within a single DLL or executable, and should be digitally signed (if not, the antivirus engine should provide its own database of verification signatures for known DLLs or executables, and the antivirus company should permanently monitor updates made available to this code by the OS or VM vendor, the simplest being that the OS or VM vendor releases this code with an embedded strong digital signature, such as Authenticode).
Unfortunately, in Windows, not all executable components are digitally signed: look at the results of the "Digital signature verifier" tool, that reports somefiles provided by Microsoft itself, notably in system drivers. There are others in fixed-size bitmap fonts used today mostly in console apps (they really are DLLs containing a resource and a normally empty code, even though they display a .FON extension, and so they can contain code executed at DLL load and unload time and when the DLL is attached and detached to a process)
Notably, look into the Windows Devices Manager: most of them depend on hardware andarenot present in lots of PC, however some are constantandavailable on almost all of them, notably in the "hidden" (non Plug&Play) devices list that isused for system services: critical ones are "AFD", "HTTP", "TCP/IP protocol", "IpNat", "IpFilterDriver", or other filesystem drivers (NTFS, FAT, CDFS...) but some other are just there for devices rarely used and generally not considered dangerous such as "Serial" that manages serial COM ports, "Beep" that just performs horrible monophonic beeps to the PC speaker without any audio device, or "Null" that implements a silent/sink device (and matches the "NUL" filename). If any of those devices, that are loaded by default and given access to the kernel, are infected, they may perform arbitrary code. Most drivers work by installing system hooks for the Win32 APIs they wish to implement.
All these executable files (and notably the .SYS drivers andthe OS loader, because they are loaded very soon during boot time, before the antivirus loads, and because their files are NOT protected and NOT locked during OS execution) should be digitally signed, and their normal location stored in the registry should be protected (unfortunately, it's easy to remove the ACL protections from the critical parts of the registry: you can do it manually from any administrator account even if those ACLs normally do not include "Administrators" rights, only "SYSTEM" rights, where only Microsoft can authenticate as "SYSTEM" because SYSTEM protects your Windows licence). Unfortunately, they are not... and their location and filename on disk is constant, making them easy to attack if there's noantivirus to protect you from silent additions or changes in the list of system devices (Windows informs you only with PnP devices). |