Limited users still exploitable

Discussion in 'other security issues & news' started by StevieO, Sep 25, 2009.

Thread Status:
Not open for further replies.
  1. StevieO

    StevieO Registered Member

    Feb 2, 2006
    Regarding limited users and their abilty, or not, to block Malware, i rediscovered this today which you might find of interest !

    He mentions WMF, but i presume it applies to other files too.

    Quote -

    Kevin McAleavey former Vice President of technology at PSC and coder of BOClean.

    Privacy Software Corporation Newsletter Archives

    PSC Newsletter-Windows WMF Vulnerability for the Non-Technical

    " In situations like this, where the program being exploited is part of the operating system itself, it doesn't matter if it's a "limited user" or other security undertakings since it's part of the "operating system itself" which has all necessary rights. And as far as firewalls, or process integrity monitors or even BOClean, it's LEGITIMATE because the operating system component itself is legitimate and has more "rights to execute" than an "administrator" will ever see. "SYSTEM rights!" THIS is why "exploits" are so valuable to "malware people" ... it uses the operating system against itself and there's really nothing anyone can really do, except for Microsoft. IF they think it's important enough. "
  2. Windchild

    Windchild Registered Member

    Jun 16, 2009
    Oh dear. Where do I even start?

    Well, first things first: generally, it would be wise to research before speaking, but that obviously can't always be expected since we all have limited time resources. In that case, though, we should at least avoid very bold declarations about things which we don't really understand. The quote is so wrong it would be funny, if it wasn't made to look like an expert wrote it.

    With that out of the way...

    First, consider what one even means by "Limited users still exploitable"? Does this mean that the technology itself has some kind of vulnerabilities that can be exploited? If so, then the answer is obviously that yes, most likely there are vulnerabilities that have not been discovered yet, and this is the case with any complex software including and perhaps especially complex security software that uses undocumented methods to do unusual things. On the other hand, vulnerabilities are patched as they are discovered, as is the case usually, in supported products. Therefore it is important to know whether there are currently unpatched and known vulnerabilities, in which case the answer is different. If we're not talking of vulnerabilities in the technology, but the idea that something can be exploited to evil ends, then everything is exploitable, especially humans, and the statement becomes so obvious that it is nearly pointless to mention.

    As for that quote, though, it's talking about an exploit that is literally years old and has been patched a long time ago, and not only that, it also reveals either a lack of understanding of how Windows works or a desire to lie about it for some unknown, perhaps marketing, purpose. The quote is full of complete and utter falsehood (to use a very nice word). And here's why:

    Whoever wrote this obviously understands very little about how Windows NT works. First of all, the WMF vulnerability was not even a problem in the SHIMGVW.DLL, it was a problem in gdi32.dll, so they even got that wrong. That, and it's also not a buffer overflow at all. It's just a very stupid legacy function that should have been deleted but wasn't, and got exploited. They also fail to realize that just because this is a vulnerability in a component that's included in the OS does not mean that this component is always executed by the OS with administrator privileges. Many components are executed always with the privileges of whichever user is logged in currently, such as explorer.exe for example. And guess what. That's the case with gdi32.dll. In other words, it very much matters whether you're a limited user or admin if this particular ancient exploit strikes. If you're admin, it gains admin privileges and can instantly own the system, but not so if you're a limited user, in which case it can only do harm to the user account and not the entire system. Even though the vulnerable component is a "part of the OS", it has no special rights: it has the rights that the user has.

    However, in some cases, it can be more complicated than that. Some users may have an indexing software like Google Desktop or Windows' own indexing service running, and if that runs with higher privileges and loads the vulnerable component, then the system can get owned even if the actual human user is logged in as a limited user only. So, that's a good reason not to run such software with SYSTEM or similar privileges - it's just not safe in a case where some vulnerability is discovered in components used by the software.

    Wrong. The vulnerable component does NOT have "SYSTEM rights". It has the rights the currently logged-in user has. If that user is a limited user, the vulnerable component will have limited user privileges and rights, and nothing anywhere near administrator. IOW, whoever wrote this doesn't have the slightest clue of what they're talking about. :) Given even an ounce of common sense, the whole quote becomes outright silly. Consider this: all vulnerabilities in Windows are vulnerabilities in the operating system (duh, Windows is the operating system). Why is it, then, that a vast majority of Windows vulnerabilities are such that their effect is limited if the user is logged in as a limited user instead of admin? Why, if we're foolish enough to believe that any and all "parts of the OS" always have "SYSTEM rights"? It's because the makers of the OS of course were smart enough to not make everything run as admin or SYSTEM if it wasn't needed. That's why many things run only with the privileges of whoever is logged in. That's how it works in all modern multi-user operating systems. Anything else would be retarded.

    What? :D This is a funny statement, considering that when this vulnerability was a big thing, it was a third party, not Microsoft, who first published a "kind of" patch that would prevent exploiting this vulnerability. Then later of course Microsoft patched the component properly.

    But in summary, the quoted article is pretty much wrong about anything that matters as far as the technical details of the WMF vulnerability are concerned. Let's put it this way: if back when this vulnerability was not yet patched, you were running a default configuration of Windows XP SP 2 without any additional applications, even security applications, but were using a limited user account, your system could not be owned by this vulnerability without user interaction. At most, the limited user account could be infected with something. Usually, the payload was such that it, too, required admin privileges and in most cases nothing at all would happen to those limited users who ran into this exploit. There were, however, some cases where the entire system could be infected even if the user ran into the exploit originally when logged in as a limited user. One case was when there was an indexing software installed that was running with higher privileges, and it tried to index the exploit WMF file and thus got the exploit code running with higher privileges. Another case was one where the user had to log in as admin, and then browse to a folder where the exploit WMF file had been dropped with Windows Explorer. Since Explorer would try to load metadata for display to the user, it would also trigger the exploit, and now it would have admin privileges. But I've never heard of anyone managing to actually get infected with the latter method. F-Secure managed to accidentally infect one of their testing machines they were using to research the exploit because they had Google Desktop indexing everything - but in that case, limited user accounts were not involved as far as I know.

    ... Also, I get the feeling that I've said all this before on this same topic.
  3. StevieO

    StevieO Registered Member

    Feb 2, 2006
    Too right, we can't all be experts, and i'm certainly not !

    Well i have to say i'm quite shocked at the things you've said about KM, as i imagine others will be too. I'm not in a position to dispute one way or the other some of the claims you've made.

    I hope someone can enlighten us further.

    But i do know he ain't no fool, and a serious long time Windows coder of various products. In fact he's been invited to join the Comodo group, and now has a very senior position with them -
  4. Windchild

    Windchild Registered Member

    Jun 16, 2009
    I suspect at least we won't ever see whoever wrote that stuff coming back to try to defend it, at least not with facts. Because it can't be defended with facts, because it's just so completely and utterly wrong about most everything. Of course, it could be defended with desperate cop-outs like "was just trying to warn non-technical people about the danger without getting into the impossible-to-understand technical details" or something like that. But facts? No. And you don't have to trust me. There are tons of security experts that have analyzed that WMF vulnerability and attempts to exploit it, and know full well what it does and doesn't do.

    As I said: it's not necessarily that the writer doesn't know what he's talking about. It could also be that he's intentionally lying, or misleading, for some reason, such as marketing. Sometimes experts as well as "experts" lie because they want to sell you something. Selling security software is about scaring people as much as it is about informing people about real threats. If people aren't scared, they're not buying your stuff. Therefore, it can be useful to sometimes say things that aren't true to make them more scared, and even the more ethical vendors often skillfully avoid mentioning any cheaper ways that could be used to provide protection against a given attack so that people are more likely to buy their software. Sad, but that's how things sometimes are.
  5. Rmus

    Rmus Exploit Analyst

    Mar 16, 2005
    From day two of the WMF exploit in December, 2005, I called it a fiasco. Never in my life have I seen so much confusion and misunderstanding about an exploit develop!

    Since this has come up again, I decided to dig out my notes.

    It turns out that there was more than one code seen in these wmf files. cleared it up in a bulletin:

    Note the two DLLs that are referenced.

    I happened to be on line when the site was published in a diary:

    Windows WMF 0-day exploit in the wild
    I went to the site on my Win2K system using Opera, and nothing happened. I fired up my trusty unpatched IE6, and nothing happened. I turned out that my Win2k SP4 did not know the file extension .wmf, as I later tested. Note the generic icon Windows assigns to WMF -- it's not associated with any program, so clicking on the icon brings up the Open With dialog:


    So, I used my WinXP Laptop and had to use IE6 to get the exploit to run:

    Just another drive-by attack that attempts to download an executable.

    This is the bulletin for this exploit:

    Win2000 because we learned that other image file extensions could be used.

    Whether or not this technically is a buffer overflow was of no interest to me, but there didn't seem to be a consensus in the various advisories. Some security companies were providing buffer overflow protection:

    Microsoft Shared DLL WMF graphics Rendering Code Execution
    December 28, 2005

    Regarding the DLLs: Technically, the exploit targeted gdi32.dll, however, shimgvw.dll starts the attack:

    WMF FAQ: What you need to know

    Because the picture viewer is the shimgvw.dll, many people began to reference only that DLL in their discussions, creating a technical mistake in the description of the attack.

    Another problem is that other image applications were found to be vulnerable. Again from
    Microsoft added to the confusion in its Advisory of January 6, with this workaround:

    Microsoft Security Bulletin MS06-001

    But using other image file types might trigger another viewer, as mentioned above. Ifranview was one. This led to more misunderstandings. For example, people on the forums said that a WMF file could be renamed as JPG and you would be automatically infected. However, not all image viewers were susceptible. JPG is associated on my computer with Adobe Photoshop and it did not recognize a WMF file renamed to JPG.


    Meanwhile, people were scared that the WMF file could do something besides function as a downloader, and all sorts of test files were constructed that launched the calculator. Here, Kevin posted in another forum essentially what he wrote in the article cited by StevieO, regarding the small space for payload code, meaning that functioning as a downloader was about as much as it could do, which makes sense also if you are a malware guy: you don't want to trash the system, you want to get malware installed.

    How is all of this relevant today? From my point of view, exploiting WMF was no different than earlier exploits of CHM and ANI files, and is no different than exploiting today's PDF and SWF files: they all function as triggers to download malware and are easily prevented from doing that!

    At least three solutions to my knowledge were tested against the WMF exploit in 2005 and successfully blocked the malware from installing: ProcessGuard, Anti-executable, Software Restriction Policies. Those three solutions, and many others, offer the same protection against today's PDF and SWF exploits.

    Last edited: Sep 25, 2009
  6. Trespasser

    Trespasser Registered Member

    Mar 1, 2005
    Virginia - Appalachian Mtns
    Nice explanation. Thanks, Rmus.
  7. Windchild

    Windchild Registered Member

    Jun 16, 2009
    Yeah, people tend to get stuff like this wrong, because it is indeed complicated. The exploit targets a vulnerability that is present in gdi32.dll. There was no such vulnerability in shimgvw.dll. The only reason shimgvw.dll is involved in this is because it's the default picture viewer, and uses gdi32.dll to render WMFs. You can completely remove shimgvw.dll from a system, and associate images with some other program that uses gdi32.dll like, say, Irfanview as you mentioned, and you will still be vulnerable to the exploit. Which should be pretty sufficient proof the vulnerability is not in shimgvw.dll, which no longer exists on the system. :D

    So, shimgvw.dll is not required at all to start the attack and succeed in the attack. That dll only comes in at the point where it's the default picture viewer for WMF files, and the user tries to open such a file. Microsoft, as they do, published a workaround that suggests disabling shimgvw.dll to provide some protection against the attack. And that indeed provides some protection, but only some, as shimgvw.dll is not required to exploit the vulnerability. As you can see in the advisory you linked to, Microsoft says the workaround will not correct the vulnerability, and will only block some known attack vectors. They couldn't suggest disabling gdi32.dll, for obvious reason - it would break stuff so completely that the workaround would be almost worse than the malware. :D If shimgvw.dll has been unregistered or even removed, this vulnerability can still be exploited by attacking other software that uses gdi32.dll - email clients, many other image viewers and editors, office software and so on.

    Yeah. People got confused because they saw shimgvw.dll in articles, and thought the vulnerability existed in that dll. But it didn't. And other image applications were vulnerable because they used gdi32.dll, the actual vulnerable component.

    People were rather confused about the whole thing, since there have been multiple vulnerabilities in gdi32.dll involving metafile processing. Some of them were buffer overflows and some allowed for privilege escalation. But, the most famous one, the so called SETABORTPROC vulnerability, that was even exploitable in Wine and got some people accusing Microsoft of deliberately creating the vulnerability as a backdoor, the one that was discovered in December 2005 and patched in January 2006 in MS06-001 ( ) was not a buffer overflow, it was just stoopid design, and this is the WMF exploit people are usually referring to and I'm talking about in this thread, and also the exploit that the quote posted by StevieO was referring to. How do I know? Consider the dates, and consider the fact that the previously known vulnerabilities in the graphics rendering engine were already patched. Those had not been exploited on a large scale, and there was no zero day attack scare, but with the MS06-001 vulnerability, it was exactly that, since there were loads of attacks exploiting the vulnerability. Consider also, that the article links to the unofficial third party patch that fixes the MS06-001 vulnerability in gdi32.dll. :D The article StevieO quoted says this:
    That already would prove it. That is the date the MS06-001 vulnerability was discovered (although some say it was actually 26th, but close enough to be irrelevant since no similar vulnerability was discovered during that time). And that is the vulnerability that caused all the big noise, since it was being exploited widely before there was any official patch out, although an unofficial third party patch was created. Other wmf related vulnerabilities had existed before it, but those were patched before large scale attacks could happen. Not so with this one, hence the big zero day scare.

    Apparently, some folks confused this new vulnerability with older ones, and failed to understand the vulnerability. As can be seen in many, many advisories and proved in testing, the MS06-001 WMF vulnerability that got so famous has limited impact on systems where the user is logged in as a limited user instead of admin:

    - "An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights."
    - "If a file with the .wmf extension is viewed with a vulnerable version of the DLL, the remote attacker would be
    granted the same privilege level as the user viewing the image"
    - "Also, do not run as an administrator level users for every day work. However, this will only limit the impact of the exploit, and not prevent it."

    And so on. So, as I said, exploiting the vulnerability causes the malware to run with the privileges of whoever is logged in. If that's a limited user, the damage will be limited to that account, which is, obviously, pretty good, as compared to a system-wide infection. But again, there were some things that could happen that would give the malware admin privileges in special circumstances, like Google Desktop indexing the exploit file while running with higher privileges, or an admin logging in and then viewing the folder where the exploit file was contained. That aside, it remains a fact that most certainly the vulnerable gdi32.dll component does not mystically have "SYSTEM rights" even when the user is a limited user instead of admin.

    Yeah. It was not difficult to avoid getting owned by this particular exploit, but unfortunately of course, most computer users don't know of these things and had nothing more than an AV to protect them against these attacks. It's up to people who know more to provide useful, correct information to "most computer users." That's why I get rather annoyed when I see people who claim to be experts make clearly incorrect statements that only serve to scare users while providing incorrect information - such as the absurd "it doesn't matter if it's a "limited user" or other security undertakings since it's part of the "operating system itself" which has all necessary rights" claim.
    Last edited: Sep 26, 2009
  8. wat0114

    wat0114 Guest

    Thank you to both Rich and Windchild for setting the record straight by providing factual statements, debunking myths so to speak, on these over-hyped exploits.
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.