OneCare has solved an infection the easy way -- it has completely trashed my xp pro system so badly even recovery console won't work RRS feed

  • General discussion

  • Thank you, Microsoft

    Thank you for the poor quality of Windows that allows virus infections in the first place

    Thank you for a virus scanner that initially could not repair a virus discovered 7 months ago, then improving OneCare so it reported the same virus cleaned even though it wasn't.

    Thank you for the most recent update, which has just corrupted my XP Pro system so badly upon reboot that I can't even come up in safe mode.  So badly even the recovery console crashes on startup.

    Thank you for destroying a system that took 3 days to rebuild after your last screwup, and will take at least that long again, plus all the 3rd party software I must re-install repatch, and reauthorize.

    All because of OneCare
    Tuesday, December 16, 2008 4:53 AM

All replies

  • how are u writing this ?

    system down ?
    Tuesday, December 16, 2008 9:46 AM
  • I'm sorry to read of the system crash and the time it will take to rebuild.

    However, there has been no update to OneCare other than definition and firewall rules for quite some time now, so I'd be looking at other causes for your system failure. And, if you had not taken the most recent update to the OneCare code, released over a month ago, a failure to install that update would not render the PC inoperable.

    I won't comment on your first statement except to say that all operating systems are prone to hacking and virus infections - Windows is a target due to it being in very wide use. That does not excuse Microsoft from hardening the OS to infection and attack.
    I will agree that OneCare needs to be improved in its ability to detect and remove malware. It is very good, but it needs to be better. When an infection makes it past, being very good isn't good enough.
    Since your PC is inoperable right now and you intend to reinstall Windows and programs, the normal advice to contact support in the event of an infection does not apply.
    I fail to see, however, how you can blame OneCare for the system failure unless that failure was due to an infection missed by OneCare, which does not appear to be your accusation.


    Microsoft MVP Windows Live / Windows Live OneCare Forum Moderator
    Tuesday, December 16, 2008 2:17 PM
  • When OneCare says it's removing an infected system file and asks for a reboot to complete the process, and the system crashes on reboot, then OneCare is the only possible cause.    The file in question is user32.dll.  If you doubt this, remove it from your windows system directory and try to reboot (warning: this will render your system inoperable, don't actually try it unless you want to sit up all night reinstalling Windows).

    OneCare repeatedly identified the file as infected and reported it as cleaned and asked for a reboot.  After doing this at least 4 times with the infection remaining I wised up and started recording the contents of the system folder before and after each reboot.  It turns out that the infected file was never touched by OneCare.  I tried booting in safe mode with a minimal set of drivers and verified the file wasn't being recreated on reboot.  After the 6th or 7th reboot, out of desperation I ran Windows Update to make sure I hadn't missed any security-related patches, and ended up with an updated malicious software removal patch.  Reboot, scan with OneCare, AGAIN it found the user32.dll and reported it infected and cleaned.  Reboot, and a completely dead system.

    I haven't slept in 20 hours, up all night coercing the recovery console to not crash on startup, and did a system repair using my Windows XP CD as recommended by Microsoft.   I've finally succeeded in booting again, applied the latest security updates, and all my work has been rewarded with:  OneCare reporting an infected user32.dll.  

    What do you think will happen if I say "yes" when OneCare asks me if I want to fix this problem?  The very best thing I can hope for, based on past experience, is that the computer will ever boot again after OneCare touches it.

    In all sincerity, are there any infections OneCare can remove?  Microsoft if charging $49 for a local copy of this tool and it cannot remove an infection discovered 7 months ago from a computer system that's disconnected from a network and booted in safe mode?  An infection that it has identified?  An infection with a well known signature and characteristics?  Try scanning the OneCare forums and look at what people are complaining about -- OneCare doesn't seem capable in removing anything it finds.  Unless all of your users are lying, OneCare commonly pops up a message saying it's found a virus it can't clean and recommends buying another scanner/cleaner.  The only thing more infurating is what I'm seeing -- reports of a clean system that really aren't clean.

    Finally, to correct a myth whose full discussion is probably better done elsewhere (and I'd love to debate this publicly)-- All computers are NOT susceptible to viruses.   I've been a systems programmer since 1985 and at one time made a living modifying source code for operating systems like VMS, Unix, and Linux.  The suggestion that any operating system on the planet other than Windows would allow any program running from a non-system account to modify any critical system files is pure fantasy.
    Tuesday, December 16, 2008 3:56 PM
  • Once again, I'll repeat that I'm sorry to read about the problem you encountered.
    You originally noted that the problem was due to an update, which is much different than being caused by an infection that OneCare has apparently been unable to clean. Yes, that file is required by Windows to boot. And, yes, it is protected by Windows, so even if OneCare managed to "alter" it, it would be replaced by the OS before the reboot or at least the OS would try to replace it.

    If you believe that user32.dll is *not* infected, open OneCare, click on Change Settings, virus and spyware tab, exclusions and exclude this file from being scanned.


    However, I think you are facing a full format/reinstall, since I suspect that the user32.dll may well be infected and it probably cannot be cleaned without the total hosed system you encountered.



    Microsoft MVP Windows Live / Windows Live OneCare Forum Moderator
    Tuesday, December 16, 2008 4:28 PM
  • Oh, and, yes, OneCare can detect and remove many infections. However, there are also many that it can't deal with and that frustrates me.

    I don't need to scan the forums, I read them every day. I know that OneCare doesn't always remove an infection that it claims to ahve removed. I have also seen it perform as expected - detecting and removing successfully. it depends on the infection.

    I won't argue the point on other operating systems with you. Suffice it to say that Windows is *not* the only OS susceptible to malware. I may have mis-spoke with "all" other OSes being susceptible - the better word would be *most*

    Microsoft MVP Windows Live / Windows Live OneCare Forum Moderator
    Tuesday, December 16, 2008 4:32 PM
  • The reason OneCare fails so miserably to remove the infection it detects is because:
    (1) it fails to scan the compressed  cached dll folder which holds an infected copy

    (2) it fails to scan the entire system directory and so misses the second infected copy of user32.dll stored in a file named with 8 randomly generated characters.  Sort the files by size, diff the 2nd file with user32.dll to see they're identical, and watch OneCare skip happily by like it isn't there.

    The 2nd file is identical, byte-for-byte, to the infected user32.dll and to not scan for this -- to not actually scan every file in the system folder -- and to not scan the cached dlls, is totally inexcusable.

    (3) user32.dll contains GUI elements required by most Windows software which, according to what we are seeing, guarantees a re-infection the moment OneCare pops up a dialog with the (false) statement that the system has been cleaned, without taking into account it's using an infected dll to do so.

    "You originally noted that the problem was due to an update, which is much different than being caused by an infection that OneCare has apparently been unable to clean."

    No, sorry, this is not what I wrote.  Let's be clear:  OneCare detected an infection of user32.dll then reported it cleaned when it was not.  OneCare specifically instructs users to visit the Windows Update site for the latest security updates.  Run the software, read the instructions.  Unfortunately, I did just that.  My reward was an "upgrade" from OneCare falsely reporting a virus as cleaned, to OneCare mismanaging a simple dll replacement on reboot the next time it decided to "fix" user32.dll for me, based on the recent security update.  These reboots are an annoying fact of life that comes with an upgrade to any Windows system software; Microsoft does them as a matter of routine.

    The really sad thing is that if I accept the premise OneCare didn't botch the update, I have to accept the statement that it was the Windows security Update that blew away my system.  Forgive me if I don't find either of these choices acceptable.

    "However, I think you are facing a full format/reinstall, since I suspect that the user32.dll may well be infected and it probably cannot be cleaned without the total hosed system you encountered."

    That is one approach.  Another would be for Microsoft to update OneCare so that it no longer falsely reports fixes it hasn't done.  Another would be to fix OneCare so it does what every other virus scanner on the market today already does, something Microsoft itself does every time it releases an update -- replace the infected dll's. 

    "full format/reinstall" is exactly the reason the people ridicule Microsoft.   No other operating system in use today will allow this type of infection.  It cannot happen in Unix, Linux, or OS/X.  It cannot happen on a mainframe.  It could not happen under operating systems that died before Windows was even born.

    Tuesday, December 16, 2008 9:37 PM
  • Marc,

    You're only partially correct, since all operating systems that allow a user to install software while logged in as a normal user are susceptible to the installation of malware, including every OS you mentioned within your last paragraph. In fact, the very first worm ever to exist was created on and affected only Unix, and resulted in the near total collapse of the DARPANet (the original Internet).

    You are basically correct that older mainframe operating systems wouldn't have allowed this though, since they generally operated a core 'Executive' process which was the only process with complete 'Adminstrative' priviledge and which managed the running of other user processes with an ability to kill them if required. Unlike this model, most microprocessor based operating systems began life as very simple designs allowing full access to the system by all programs, partially due to the lack of available resources in early hardware designs. The assumption here was that the user would only install programs they wished to have running, so they'd have complete control to remove software that behaved badly.

    What these simple OS designs never took into account was the connection to networks and eventually the entire world via the Internet. Since most existing software assumed it had complete access to the PC, it was virtually impossible to simply change the OS overnight to remove this ability, since this would effectively break all of that pre-existing software. So instead a steady progression toward a more secure model has occured, accelerating recently as the attacks against these insecure designs have increased almost exponentially.

    If you are unaware of the existance of malware written for the Unix/Linux platform it's simply because the greatest amount of 'noise' occurs relating to the Windows OS, since it's so much more popular than any other OS has ever been. And since the entire purpose for the Windows OS was as a development platform, it inherently allows the creation of any software, good or bad, unlike most ofther closed platforms which came before. Unfortunately its own success is really becoming its downfall, with a clear arms race occuring towards a time when general purpose computing is likely to end forever, with the only programming platforms returning to the engineering labs and all user systems being closed platforms with no ability to truly 'program' remaining available to the everyday user.


    Windows OneCare Forum Moderator
    Wednesday, December 17, 2008 1:50 AM
  • OneCareBear said:


    You're only partially correct, since all operating systems that allow a user to install software while logged in as a normal user are susceptible to the installation of malware, including every OS you mentioned

    No operating system other than Windows will allow the overwrite of any system file by an unprivileged user.  Every time Microsoft is challenged on this, they back down or change the subject.  The files that comprise the Microsoft Windows operating systems have no better protection than a basic user file and can (and are) overwritten by the most benign of programs, resulting in the loss of the entire system.  You cannot corrupt a system file on a Mac from a user account.  A user installing software on a Unix or Linux system cannot do anything, ever, that would require the system to be rebuilt.

    More importantly, no operating system in use today, other than Windows, will allow the unintentional installation of software as Windows an Internet Explorer do.  The reason you don't hear about other OS's being infected isn't because of Windows' market share, it's because it doesn't happen.    I can point an iMac or Linux system at any web site you choose and surf it all day long without being infected because, as should be the case.

    Casual users who are interested in this topic should Google for the preferred OS of choice for computer security labs that proactively surf the web looking for hosts that spread infections.  They're NOT using Windows for a reason.

    Wednesday, December 17, 2008 3:57 PM
  • Marc,

    You are wrong that this can not occur with any version of Linux or Unix, since when a vulnerability is discovered within Linux that can be exploited to allow root access it is just as susceptible at that moment as any version of Windows. The key issue at this point would simply be how quickly an update to fix the vulnerability is published and then how quickly an individual user installs it on any vulnerable OS in their care. Many Linux systems have been known to be infected by malware, you simply choose to ignore this fact because the numbers are much smaller.

    Where you are confusing the situation is that the default method of operation for Windows for many years has been to make each user an Administrator. This is a commonly known issue and yes it makes the system files, as well as all others susceptible to modification if malware gains entry. The point here is that the same thing can occur if malware is executed while a Unix/Linux user is logged in as root. The key difference being that the default for Unix is that users have low priviledge unless and until they log in (or su) to root. Again, once malware gains entry to a system authenticated as Administrator or root, it's game over if that malware is aware of the system it has penetrated.

    The fact that Windows defaults to Administrator for systems up to and including Windows XP is well known and another part of the legacy of open access to the operating system by software that existed since the DOS days. Again, this wasn't an issue in the pre-Internet days when the only way a virus could move between systems was via sneaker-net on a floppy disk. Though Microsoft has attempted to educate users to create and use Limited User accounts to remove the risk, only a small percentage understand and perform this simple protection, including myself.

    This issue continues to exist in part because of the laziness and lack of knowledge of both users and some programmers who have ignored this simple solution, requiring that Microsoft begin to enforce this as a default with Vista's User Account Control. However, as usual the 'techies' who think they know better have often chosen to disable this function, resulting in a reduction in security from their own "I know more than MS" stupidity.

    This has always been the thing that techie users have liked about Windows, the ability to 'tweak' and change things to their liking, no matter how stupid the idea might in reality be. To the greatest extent Apple has avoided this with a mostly closed architecture, though the move to a Linux base has begun to open them to more of this 'twiddling' by those less informed than they might think.

    So at the core, Windows isn't really any more or less susceptible at this point than the current Linux distributions, it's simply not configured effectively on many systems. As the user base of Windows XP systems converts to Vista and later OS the percentages will change, though it may take a few years. However, as the number of available easy targets with Windows begins to dry up, it's quite obvious that the interest will move to other platforms and actually already has, since application vulnerabilities are now much more commonly used as an attack vector than the OS itself.

    It's also quite clear that most Phishing attacks are OS agnostic, since they often don't even attempt to directly attack the computer itself, preferring instead to bypass the need to infiltrate the system and to entice a user to provide their private information of their own accord. This has become one of the most prevelent and successful methods, since the weakest link in security is usually the user himself.


    Windows OneCare Forum Moderator
    Thursday, December 18, 2008 5:33 AM

    OneCareBear, you make it sound as if the ability to overwrite or modify system files is an essential part of Windows programming or “tweaking”. In fact, the exact opposite is the case. Effective programming depends upon the integrity of the API at the system core, and also the integrity of the OS’s programmable subsystems. The whole idea behind (the so-called) “Windows File Protection” is to prevent system files from being overwritten by an application because this could break other applications.


    Because Windows File Protection was designed primarily to save us from “dll hell”, rather than malware hell, it took the form of a restoration utility rather than a proactive defense mechanism. This approach arguably does leave the door open to malware, but here I would only like to inquire about the effectiveness of Windows File Protection with respect to system files that are infected with malware: Is the Windows File Checker (sfc /scannow) capable of replacing an infected user32.dll? Some sources claim that this utility checks the “integrity” of system files as well as their version, but I’m not sure what that means. I think this is basically the same thing as the “File Signature Verification Utility” that appears in System Information. If, as Marc suggests, OneCare (or Windows File Protection) is restoring user32.dll with an infected backup copy from the dllcache folder, would it be possible to use the sfc /scanonce or the sfc /scanboot command to rebuild the contents of the dllcache folder, as this KB article purports? http://support.microsoft.com/?kbid=222193


    I really don’t have any experience with the System File Checker, and would appreciate being educated about its usefulness with respect to infected system files. Of course the only alternative to having a write-protected operating system, or one that can effectively repair itself, is to have the ability to overwrite infected system files. So the vice becomes the virtue.



    Friday, December 19, 2008 5:28 PM
  • GreginMich,

    I was only mentioning 'tweaking' as it relates to directly modifying the registry in an attempt to change the operation of the operating system, usually in a mis-guided attempt to improve performance of the PC. I was not referring to the general situation of programming in this context, though I see how this might have been confused.

    I also never mentioned Windows File Protection (WFP) since as you mentioned, it was never really intended as a protection from malware. It's primary purpose was to allow the recovery from damage to the core system files, whatever the cause. However, since WFP has no real secure control over access to these files, the malware can simply come back and remove or change the files again after a manual SFC command is performed.

    Though one of the articles linked from the one you included above gives more information about syntax, I'm really not any more knowledgeable about this utility than you. It might allow the repair of the damaged user32.dll, though if the one found in the dllcache folder is also damaged this may have little value. Remember that a malware designer is also aware of this utility and WFP itself, so they can easily curcumvent it if their application has gained administrative control.

    Description of Windows XP and Windows Server 2003 System File Checker (Sfc.exe)

    This is why my primary discussion was related to Limited (sometimes called Standard) accounts, since these do not have administrative permissions to the filing system. This means that they generally have just read-only access to both the Program Files and other system file folders such as Windows and its sub-folders. This limits the potential for access by the malware application in the first place, removing the ability for it to do any modification unless a priviledge escalation vulnerability is involved.

    Limited User accounts can protect your Windows XP computer when you browse the Web


    Windows OneCare Forum Moderator
    Saturday, December 20, 2008 10:08 PM

    Thanks for your reply OneCareBear. I was ignoring the possibility of a re-infection mechanism based on Marc’s assertion that this was a case of “OneCare mismanaging a simple dll replacement on reboot”, and also his assertion that this mismanagement involved the restoration of a second infected copy of the file in the dllcache folder. I was responding to this hypothetical situation. Of course Marc could be wrong, and this could be a case where a re-infection is being perpetrated by the malware.


    Given the hypothetical situation described by Marc, and OneCare’s (hypothetical) failure to correct it, the SFC is, to the best of my knowledge, the only tool available that is even potentially capable of repopulating the dllcache folder, or replacing a bad system file, so I would personally give it a shot. This utility purportedly can rebuild the cache from the original source, so I thought it might be possible to first overwrite the cache, and then restore the file, but this could get overly complex if it involves slipstreaming a service pack. I still would like to learn whether or not the System File Checker is able to detect an infected system file as a case of “corruption”.


    The point I was trying to make with respect to Windows File Protection, is that if it had taken the form of some kind of write-protection, rather than a replacement utility, it might actually have been able to protect system files from being overwritten by both programmers and malware, and we wouldn’t be left wondering if the SFC will be able to clean up the mess, or whether its work will be undone by a re-infection because it can’t really secure system files. The point is that WFP should have been given the ability to secure system files from being overwritten by any unauthorized source, including malware. The fact that it wasn’t designed to operate proactively, with malware in mind, seems to me to indicate a degree of negligence; given the threat that malware poses to system files, and a system that defaults to administrative privileges. If Windows File Protection had been given a set of real teeth, it would presently be capable of defending system files against malicious overwrites as well as careless programmers.


    I can certainly appreciate your emphasis on limited user accounts, OneCareBear, since they seem to be the only proactive tool that’s available to protect system files from malware in Windows XP. But as you fairly acknowledge, they have their own vulnerabilities, and it seems that people just don’t like them, and refuse to use them because they aren’t able to install programs. So it still seems to me that Windows XP could (and should) have been hardened to the point where it would have been impossible for an administrator account to overwrite (or delete) system files. That’s why I made the point that legitimate programmers don’t need to overwrite system files (excluding runtimes), and in fact need to be prevented from doing so by WFP. If programmers don’t need this privilege, then what’s the justification for including it in administrator accounts (other than the need to overwrite system files that have already been overwritten by something malicious)?


    I think this consideration was essentially acknowledged with the implementation of Mandatory Integrity Controls (MIC) in Vista. According to a somewhat dated article by Steve Riley: “All operating system files are now unlabeled, meaning they default to medium integrity. The files are ACLed such that only the trusted installer has write access; everyone else, including administrators, has only read and execute access.” http://blogs.technet.com/steriley/archive/2006/07/21/442870.aspx


    OneCareBear, I can’t keep up with this stuff anymore, so perhaps you could bring us up to date on the relative effectiveness of Vista’s MIC, and the question of whether system files remain vulnerable to privilege escalation, or other attack vectors, even at the level of trusted installer. Thanks,



    Sunday, December 21, 2008 10:43 PM
  • Greg,

    Though we can discuss the hypothetical situation here all day, neither of us are able to verify the true situation with Marc's system, which could vary from some sort of re-infection all the way to a false positive detection relating to that particular file. I personally question the likelyhood that this is occuring after a re-install, but if it is I'd be looking for the flaw in my re-installation process that was allowing the malware to return (or remain).

    As for Windows File Protection (WFP), though it was designed with the ability to perform automated repairs, by itself it doesn't provide any security or assurance that the files can't be modified, it simply attempts to 'repair' (replace) them if they are. This is why I stated that the use of Limited Accounts is required with Windows XP to provide that protection, since an Administrator account can modify any file. I don't know where you got the idea that Limited accounts "have their own vulnerabilities", as this statement was made in reference to general OS priviledge escalation vulnerabilities that would bypass the security of any OS if they exist.

    My knowledge of the particulars of the operation of both WFP and the Mandatory Integrity Controls (MIC) you have mentioned are quite limited, since I don't currently write programs for any platfom. My involvement with Windows has been primarily as a Network Administrator managing hundreds of desktop/laptop and server systems in business. My interest in malware is a side effect of that background and a career direction that has included the management of network and system vulnerabilities and their remediation.

    However, to state that Microsoft should have included some form of write protection in Windows XP ignores the simple fact that at the time Windows XP was released, the current level of malware problems didn't exist. Since the code base for Windows XP was the existing Windows 2000 OS and the only real significant changes were simplified networking (no domain) and an improved visual interface, it's not surprising that an almost 10 year old OS design is showing its age. Hind sight is 20/20, so it's easy to second guess the original design over 10 years later.

    In any case, since the ability to protect the Windows XP OS currently depends on the use of Limited accounts, it seems to me it makes simple sense to use them. I've been doing this in business since Windows 2000 and with the family Windows XP systems I support since late 2001. It's not really difficult at this point, since virtually all software produced today supports Limited accounts. It's simply a lack of knowledge by users, which is why Vista or the future Windows 7 will be the likely eventual solution for most home users.

    Personally, I've expected that eventually the Windows OS would evolve to something approaching the design of the mainframe and mini-computer operating systems that preceeded it. These included completely separate executive processes that managed the system hardware and core filing facilities, while the applications themselves had to make requests for these resources. However, the evolution to such a secure approach has been slow, primariliy affected by the opposing requirement for backward compatibility with existing applications.


    Windows OneCare Forum Moderator
    Monday, December 22, 2008 6:54 AM
  • In a roundabout way, you’re making a couple of good points here OneCareBear: First, it’s the whole functioning of the operating system, not just the system files, that ultimately needs to be protected from the damage that bad programming or malware can do. Secondly, this protection requires the imposition of strict limitations on how applications interact with the system. I’m sure you’re correct in stating that these limitations on application code are an old idea that predates the NT architecture, but these same restrictions actually do serve as the foundation of the NT architecture. So when you speak of “executive processes” you seem to be referring to an older incarnation of the hyper-privileged (unrestricted) processor mode known as “kernel mode” in NT-based operating systems. Kernel mode, or “kernel space”, is a hardware-enforced protection domain that incorporates all of the critical and security-related components of the operating system and attempts to isolate these components from application code, which runs in its own “user mode”, or “user space”. I’m also quite sure that the “Executive” proper is still a component of kernel mode and functions as the control interface for user mode subsystems, as it did in the original NT architecture. For NT-based operating systems, then, the barrier between applications and the operating system kernel has ostensibly remained in place all along, but the enforcement was quite lax until Microsoft finally decided to start clamping down in 2005. With Windows Server 2003 SP1 and the 64-bit version of Windows XP, user mode access to kernel mode memory was disabled for Device\PhysicalMemory and the ZwSystemDebugControl API. This eliminated two conspicuous vulnerabilities that had previously allowed escalation between the code privilege levels.

    With the implementation of Kernel Patch Protection (KPP, or PatchGuard) in the 64-bit versions of Windows Server 2003 SP1 and Windows XP, all applications were denied direct access to many other kernel mode structures and processes. PatchGuard monitoring was (and still is) limited to the more recently developed 64-bit versions specifically to prevent the backward compatibility problems that you mentioned. But it actually did require a major compatibility adjustment for security software vendors, who for the most part had previously relied on the ability to access and “patch” (modify) the kernel. When several security software vendors complained that they were being unfairly handicapped by the PatchGuard restriction, Microsoft simply responded by developing several new APIs that could serve as an alternative to patching the kernel. A more technical description of kernel patching is presented here: http://www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.mspx

    The most interesting (and troubling) thing about PatchGuard is the way it works: Instead of preventing the kernel from being cracked by malicious modifications, PatchGuard waits for this to happen, and then several minutes later, when it finally opens up its eyes and realizes that the kernel has been compromised, it intentionally crashes the system to prevent any further damage. This is essentially the same reactive strategy we saw in Windows File Protection, with the exception that the “fix” is replaced with a crash. PatchGuard (by itself) thus effectively prevents legitimate programmers from patching the kernel, but doesn’t really prevent malware from using kernel patching as an attack vector. As you might expect, the critics had a field day with this one. McAfee was quick to point out that PatchGuard not only grants access to malware, it also gives the malware plenty of time to play with: “This means that it actually does allow malware—and legitimate applications— to access and modify the kernel, for up to nine minutes and fifty-nine seconds. That is much longer than most malware needs to achieve its purpose.” (Pages 13-14): http://www.mcafee.com/us/local_content/misc/sage_0407.pdf

    That’s simply not the way security is supposed to work, and this type of reactive security strategy is what gives people the impression that the Microsoft system programmers are either intentionally building vulnerability into the system, or else completely ignoring the threat posed by malware. As we’ve seen by looking at the “protection ring” architecture that was adopted by Windows NT, it’s been clear from the beginning that malware poses a serious threat to the operating system kernel, and that the components of kernel mode (files, memory addresses, tables, and services) all need to be protected at the front line by being rendered inaccessible to modification. Giving malware any “window of opportunity” at all seems to be repeating the mistake that was made with Windows File Protection. Of course to anyone who studies these things, the McAfee critique is obviously facetious insofar as it fails to fully acknowledge the host of proactive steps that were later taken in Vista. Vista’s new multilayer security structure should theoretically make it a lot harder for malware to gain access to the kernel, and should also tend to mitigate the damage that malware could potentially do if it does succeed in cracking the kernel.

    The relevant new proactive devices that I’m referring to would specifically include Mandatory Integrity Controls (MIC), Windows Resource Protection (WRP, now based on DACLs and ACLs), Kernel Mode Code Signing (KMCS), Code Integrity (CI), Address Space Layout Randomization (ASLR), Windows Service Hardening (WSH), and last but not least, the User Account Control (UAC). On paper, all of these devices taken together appear to present a rather formidable front-line defense, and some studies suggest that they actually are moderately effective in defending the border between user-land and kernel-land. I certainly hope that’s the case, but I honestly don’t know how well this patchwork of proactive layers coordinates to protect the system.


    Sunday, January 11, 2009 6:40 PM