Norman Malware Cleaner 2010.05.29I use the word "malware" to refer to any code, script or software that has effects unintended by or prejudicial to the user; usually where these effects are hidden.
That is indeed broad enough to include certain commercial software (stealth registration, undisclosed adware, spyware, stealth installation of bundled apps) and device drivers (recurrent intrusions into startup axis, e.g. as part of DOS support). From a troubleshooting perspective, the process of cleaning up these commercial/driver issues is similar to cleaning up many worms and trojans, so for both practical and philosophical reasons it's appropriate to include them.
The traditional anti-malware approach is to run an antivirus application as 'underfootware' to recognize known malware via the "mugshot comparison" method. Heuristics (i.e. assessments of behavior) are also used, but as so many hi-level scripting statements are indistinguishable as to intent (every file system write or registry addition is a risk), I don't hold much faith for this.
Instead, I tackle the 4 E's directly. Where possible, I'd rather wall out a hundred or so risks than chase the recognition of thousands of malware, just as I'd rather burglarguard a few windows and doors than allow everyone in and count on recognizing known burglars when I encounter them in the house.
Primary entrance points are where the malware can enter a system, without requiring any pre-existing presence on that system.
Such entrance points are; human operators, removable disks in the boot process, files incoming via diskettes, LAN shares, downloads or email attachments, removable disks where AutoRun.inf is supported, data files (Office and HTML) where scripts are auto-executed, and finally hacking in through networks such as the LAN or Internet.
Entrance may be in a setting where a limited range of behavior is possible, e.g. a script embedded in an HTML email that is running in 'Internet Zone', or a scripting language that places limits on what can be done. Escalation goes about extending the range of possible behaviors from whatever initial beachhead you have established; it is the very essence of hacking, and second nature to malware coders.
Escalation may exploit what I call "secondary entrance points", which are the system startup axis, application startup axes, and extensions of theses axes such as "magic name" and file association intrusion points.
Secondary entrance points are irrelevant within the narrow "Entrance" view, in that they cannot be exploited unless a primary entrance point has already been breached. But it is my opinion that one should never assume the latter will not happen, and look beyond the "can't happen here" view.
Extension is similar to escalation, except that it involves spreading from one system to another - it is the means by which the malware propagates itself. Not all malware do self-propagate; there are plenty of one-off attacks, which defeat both mugshot recognition and any heuristics that focus on spreading-type behavior.
Web sites and spammer's MILLION EMAIL ADDRESSES FOR ONLY!!! CDs allow non-propagating malware to be shotgunned out in a million "one-off" attacks, so the significance of this should not be underestimated.
The defining characteristic of viruses is that they extend by infecting other files or disks. Worms extend by infecting networks, and trojans by masquerading as desirable files so that the user extends them into their own system or allows them to survive on the assumption they are valid parts of the system.
A malware can do any of the above, which is why I no longer use words like "virus", "worm" and "trojan" if I mean malware in general.
Spread can be localized to the LAN, which is why I advise extreme caution in deciding what to share over networks, even if your own LAN is "closed" (no TCP/IP on LAN to expose systems directly to Internet)
The payload, the nature of which may terminate all of the other E's with the functional death of the host. One should place little faith that an environment or language will limit the scope of execution, unless you have made a thorough assessment of escalation possibilities from that environment or language.
Suffice to say, if you can write to the file system (even renames or copies is enough), add to the registry or other settings files, or launch other processes or files, your "sandbox" is leaking.
Microsoft
Microsoft have an abysmal record where understanding these simple concepts are concerned. In terms of what they offer their clients (i.e. disregarding how they interact with investors, competitors, staff, "business partners" etc.) this is the single biggest problem I have with MS; they either don't have a clue or don't care.
The worst examples are the autorunning macros in data files and HTML email, but I am also concerned about escalation risks posed by secondary entrance points. The reason why I have railed against "View as Web Page" so obsessively is that this is one risk that I have yet to be able to conclusively wall out of Win98.
Windows Millennium Edition (ME) removes some secondary entrance points from the system startup axis, i.e. Config.sys and AutoExec.bat, and adds an "auto-repair" facility that could block malware that attempts to trojanise system code files.
But ME's "auto-repair" may be a mixed blessing, where it restores components that have been deliberately removed so as to manage escalation threats, e.g. WScript.exe, CScript.exe, SHSCrap.dll, Attrib.exe, FDisk.exe, Format.com and Debug.exe - however, there are ways around this.
ME has also missed some opportunities to correct stupid defaults; surprising, given the object lesson posed by LoveLetter and Kak. Outlook Express still defaults to sending and replying in HTML, interpreting HTML scripts within email text in 'Internet Zone', and allowing "safe" controls and Java to run within 'Restricted Zone' as it is defined by the default "high security" template.
Finally, the loss of true real mode boot (though this can be fixed) makes management of malware attacks and damage difficult (getting in before the malware code runs, tackling files that are "always in use"), including steps needed to overcome the "auto-repair" obstacle. It also encourages opening up a primary entrance risk that most savvy builders and users have closed for several OS generations; the infected bootable diskette.
Norman Malware Cleaner 2010.05.29Server 1 Brothersoft(CDN for Global) Click to Download
0 komentar:
Posting Komentar