If you have full trust, then you can do anything, so don’t be surprised that you can do bad things, too

This is another example of the dubious security vulnerability known as wrapping a simple idea inside layers of obfuscation and then thinking that somehow the obfuscation is the source of the problem.

First of all, consider this: Suppose a program calls one of its own functions but gets the calling convention wrong and ends up corrupting its stack. Is that a security vulnerability in the operating system? No, it's a bug in the program. Now, maybe a bad guy can try to exploit this bug in the program, but if such an exploit could be found, it's naturally a vulnerability in the program, not in the operating system.

Okay, now we add the layers of obfuscation.

First, instead of calling the function incorrectly, we filter it through another function that takes a callback function. For example, let's use EnumFonts, which is a function that takes a callback function which is called once for each font. If you pass a callback function that has the wrong calling convention, that's your problem. The EnumFonts function doesn't know what calling convention your callback function uses; it's your responsibility to pass a correctly-formed function.

Okay, let's add another layer of obfuscation. Instead of passing an incorrect callback function from unmanaged code, let's use DllImport to call the EnumFonts function from a VB.NET program. We're still passing an invalid callback function, but now it's being done from a VB.NET program instead of an unmanaged program.

At this point, you announce that you have found a security vulnerability in VB. And since a lot of scripts are written in VB, you add that this vulnerability affects Word, Excel, Web pages, anything that supports script.

But if you take away all the layers of obfuscation, you see that all that is really going on is that the program called a function with the wrong calling convention. Hardly an earth-shattering vulnerability.

Now let's look to see if the layers of obfuscation made the original problem broader in scope. First of all, the caller and the crash take place in the same process, so we haven't crossed a security boundary from, say, one process to another, or from user mode to kernel mode. Furthermore, in order to call a DllImported function, the program needs to have full trust, in which case it already can do bad things to your computer without having to enlist the assistance of the EnumFont function. It could just start passing totally bogus parameters to Marshal.Copy and corrupt memory all it wants. The only interesting thing would be if a trusted program could somehow be tricked into passing a bogus function pointer to EnumFonts or otherwise be tricked into calling a bogus function, but even in that case, it would be a bug in that trusted program, not in VB itself.

Comments (30)
  1. benjamin says:

    The headline is as true of real life as it is about authentication. Poetic, really.

  2. Anonymous says:

    When I read the "full trust" in the title, I somehow misread it as "Full Control" (the NTFS ACL thing).

  3. Luke says:

    But isn’t anything running on the local machine (that is, 99% of all programs) fully trusted? Aren’t programs run from a shared folder fully trusted as well? Isn’t this partial trust gizmo only interesting for a small subset of applications? To me it somehow feels cheap of MS to just argue “oh the app shouldn’t have held full trust anyway..”

    [I’m not saying, “Oh, you shouldn’t have given the app full trust.” I’m saying, “If your exploit requires full trust, then where’s your exploit? You didn’t cross a security boundary.” -Raymond]
  4. J says:

    "But isn’t anything running on the local machine (that is, 99% of all programs) fully trusted?"

    Umm, yes, usually.  Which is why when you download something in IE it pops up the dialog that says the program came from the internet and you’d better trust it before running it.  That’s why Firefox greys-out the Run button for a few seconds so you can think before you click.  Just like your system trusts the program, you had better trust it, too before running it.

    Do people forget that even if you’re not running as an admin, an untrusted program can still wipe out your home directory, My Documents folder, ~/precious_stuff_i_dont_want_to_lose?

  5. Joe says:

    is it just me, or is this a deja vu moment?  It feels like articles are being repeated…

  6. frymaster says:

    Joe: It’s not the articles that are repeated, just people’s stupidity ;)

  7. Dan says:

    "But isn’t anything running on the local machine (that is, 99% of all programs) fully trusted?"

    On Windows, traditionally yes.  Starting with Vista (or earlier if you purposefully used Limited Accounts instead of Administrator ones) as well as in Unix and Unix-like OSs (AFAIK, IAMAUnix Expert) users are given restrictions to limit the effect of bad software running on the system; in theory, only that user’s profile should be affected and you could wipe it if something infected it and carry on with life; the system itself would be OK.

  8. Dean Harding says:

    "It’s not the articles that are repeated, just people’s stupidity ;)"

    Heh, so true!

  9. Jerk says:

    Joe:  And tomorrow we’ll get another exhilarating installment of Microspeak!

  10. CDarklock says:

    "Do people forget that even if you’re not running as an admin, an untrusted program can still wipe out your home directory, My Documents folder, ~/precious_stuff_i_dont_want_to_lose?"

    No. They just don’t care, because it’s your own stupid fault you lost it. You should have been more careful; it was almost certainly your own fault that the account was compromised and had to be wiped, so you should have not done whatever you did, and not trusted whoever exploited your trust, and had multiple distributed backups of your precious stuff you didn’t want to lose. And now that you’ve been well and truly punished for your failure, you will never ever ever do it again – right?

    There’s a reason IT staff aren’t very popular. ;)

  11. Joseph Koss says:

    9 out of 10 "viruses" todays arent computer viruses in the classical sense. They are what I call "stupid seeking missiles," which can only hit stupid people. Essentialy the same problem of "trust" that Raymond talks about.

    These Stupid Seeking Missiles scream "Click-on-me!!", "Run me or else!!", and other such stuff. Essentialy, they spread precisely because somebody trusted it when they shouldn’t have.

    Now we have this conficker virus, where I have to wonder why untrustable USB devices are allowed to be plugged into corporate, government, and military systems. This new "trust" problem isnt specific to USB either, as Firewire devices apparently have the ability to read and write to any memory location without any "autorun" feature at all, regardless of the OS.

  12. Stefan Kanthak says:

    Re Joseph Koss:

    How do you tell the difference between a trustable USB/external device and an untrustable one?

    Or whether a Word document for example is trustable?

    The problem with most malware is that lusers are stupid, lazy, don’t care or just don’t know/can’t tell the difference.

    And they want to get their work done.

    So they (tend to) click on the [Yes] button of the "AutoPlay" box which conficker presents when they plug in an USB stick.

    On the other hand a system administrator should know very well how to prevent her/his users and their systems from the malware du jour.

    So the benevolent dict^Wadministrator gives his users no administrative rights, turns on SAFER/software restriction policies and the Automatic Updates, restricts the use of Internet Explorer or at least ActiveX/ActiveScripting in IE, enforces (for example) that Office documents are per default opened with the Office Viewers, turns off AutoPlay and other questionable functions, …

  13. Morten says:

    There’s a reason IT staff aren’t very popular.

    Our job is definitely not to be popuplar. It is to be effective and efficient. Popularity may suffer as a consequence. So there. I think I’ll survive, as long as I get to chew out a few users now and then. ;-)

    Oh, and read TONT. An important part of a balanced diet.

  14. Joseph Koss says:

    Re: Stefan Kanthak

    I only trust a USB device if I trust the source of the device. Its the same as it ever was.

    I don’t trust foobar.exe unless I trust the source I got it from, and I do not trust some guys thumb drive unless I also trust him.

    Do you think that ZIP file is safe as long as you don’t open it? Think again. Some program or OS service may go ahead and open it behind your back, perhaps to index it.

    Image files? Ditto.

    The USB problem isnt an autorun problem at all. Its a problem of trust. There could be any sort of specialy crafted file on that USB device that some program is going to scan, and get the idea that it should automatically parse its contents simply because of its name.

    "Please wait while SomeMediaPlayer scans your system for media files"

  15. Starfish says:

    Re: Joseph Koss

    If the programs that auto-open and parse those files have bugs in, perhaps you should be using different programs. And also to note that if they can do bad things on maliciously crafted input they could do bad things on certain junk input too.

    There is a limit where paranoia stops being helpful and instead restricts you more than necessary. If you really cared that much about your data you would have a strict backup routine in place – viruses can’t infect data they don’t have access to.

  16. Ben Voigt [C++ MVP] says:

    <quote>If the programs that auto-open and parse those files have bugs in, perhaps you should be using different programs.</quote>

    And if the programs were installed with the OS and you might not even know they are there and the OS manufacturer swore up and down in court that those programs are critical inseparable OS components so they have to install by default and can’t provide an uninstall option?  Then what?

    I’d venture to suggest that some (many?) OS install programs fail the trust test.

  17. Stefan Kanthak says:

    Re Joseph Koss:

    So you trust the USB device or Word document your trustworthy neighbor/colleague has handed over to you, not knowing that he picked up that USB device from the parking lot where he found it lying on the ground, or that he received that Word document per mail/download?

    And guess why I explicitly wrote that the savvy administrator turns of AutoRun/AutoPlay as well as indexing service or other questionable functions (like virus scanners.-)?

    Re peterchen: get yourself a name!

    Guess why I wrote "they want to get their work done" and all the following?

    Who cares what a user downloads if s/he cant execute or install the downloaded programs?!

    If you have security requirements or dumb users, then restrict their environment/privileges as mentioned.

  18. peterchen says:

    >> The problem with most malware is that lusers are stupid, lazy, don’t care or just don’t know/can’t tell the difference.

    It goes deeper than that. When people want to achieve something (say "view this document in a *bleep*ing unknown format"), they’ll focus on that thing and devalue all obstacles.

    Imagine you had to navigate the "open with code" to the microsoft file extensions site, actually found the responsible application, had to sign up and specify the size of your underwear to download a "demo" version, had to check your e-mail thrice for the download link, had to find the tiny "if your download doesn’t start autmatically, click here" on a page full of huge "purchase full version" links. Downlaod succeeeded. File found. DOUBLE CLICK. *NOW* you are going to be stopped by that "run me only if you trust me" message?

    There’s a lot of sunk cost in that download, but humans won’t easily let it go. Even if you’d see that message only once in a month, there’s a good chance you skip over it, not missing a beat.  

    It happens to the best. The weakest link is always the user, as soon as his goals conflict with security requirements.

  19. Alexander Grigoriev says:

    AutoPlay has long become a dangerous feature which should have been completely rethought by now. But was not. ANd even got worse. USB drives used not to have autorun. Now AUTORUN.INI is parsed from them. WHy? It’s already too bad for a CD, because you should not be trusting recordable media. While CDs were factory-pressed only, it was acceptable somehow. But with most CDs being recorded by now, autorun from them should be disabled. USB drives are obviously not to be trusted at all.

    I wish Microsoft has become faster in addressing those real problems, rather than finding false problems as an exuse to not to fix them (like: users got used to the stuff running by itself, we can’t take it from them, let’s better invent UAC V2.0).

  20. Joseph Koss says:

    Re: Starfish

    There is no such thing as a bug-free program.

    I point you to exhibit (A) a little program called ‘sendmail’, while a unix program, it illustrates the point nicely.

    Sendmail has recieved hundreds of patches over the -decades- related to serious security issues involving both remote infiltration as well as priviledge escalation. Fix after fix after fix. Year after year after year.

    All of these flaws all stem from the same theme: Carefully crafted input.

    Only the most trivial of programs are safe from carefully crafted input, and only then when extreme counter-measures litter the code to the point of paranoia.

    Using a different program isnt an option in that it doesnt solve the general problem, although it might solve a specific one.

    Software isn’t labeled with what security flaws they have, or even what potential flaws they might have.

  21. Alexander Grigoriev says:

    Joseph Koss,

    Now check number of vulnerabilities in Qmail.

  22. Bryan says:


    If you’re going to complain about a feature, at least complain about the right one.  You’re referring to AutoRun, not AutoPlay.  AutoPlay doesn’t automatically execute anything.  It does scan things, but if a scan is all that’s necessary then you’ve already lost that battle.

  23. Yuhong Bao says:

    Joseph Koss: Yea, the fundamental problem is that the OS don’t know the DPI of the screen, and so the user has to set it manually, or otherwise the default on Windows is 96 DPI.

  24. Starfish says:

    Re: Joseph Koss

    I didn’t imply there was such thing as a bug-free program, however, programs can’t have bugs in things they don’t do. If you take that to its logical conclusion, then you don’t use programs with the features you’re concerned about.

    In other words, if you’re so worried about programs with autoplay functionality and you don’t even want that functionality, disable the program already. Capiche?

  25. 640k says:

    Starfish: Plase read Ben Voigt’s message again.

    1. The OS should make it easier for the app developer to sustain a safe environment.
    2. The OS should make it easier for the user to sustain a safe environment.

    Putting all responsibility on app developers and users are not an advancement in OS design, on the contrary, it’s a degeneration.

  26. Alexander Grigoriev says:


    "if you’re so worried about programs with autoplay functionality and you don’t even want that functionality, disable the program already"

    You mean, uninstall Windows with its autorun functionality?

  27. Joseph Koss says:

    Its not just autorun..

    It also automatically generates thumbnail images, which requires code most certainly far more complex that you would expect until you actualy got around to coding such a monster without the use of 3rd party libraries (which you cannot trust, right?)

    Lets not forget everything that the indexing service does. It traverses ZIP files, peeks into PDF files, even does some stuff with audio files like mp3’s and wma’s, word documents, html files, and on and on and on..

    I think the chance that a future exploit is discovered which involves the current windows indexing service is just about 100%. There has been more than one exploit discovered in past versions.

    Trying not to run programs that do things automatically is tricky business, since programs do not come with a list of all the things they do. ‘Trying’ is not an accepted level of security. It is obviously superior to also avoid getting problem data to begin with.

  28. Alexander Grigoriev says:

    Joseph Koss,

    This is why it’s important not to run as Administrator. By the way, Vista indexing runs the file parsers in a separate process under restricted token.

  29. Xepol says:

    You bring up an interesting point.  

    Perhaps the hand off mechanism needs to be rethought in all these languages and OS design to something more bullet proof.

    Since the fundamental flaw is at the bottom of the stack, it would need a huge ground up rebuild.  We probably will not see this flaw addressed any time soon.

Comments are closed.

Skip to main content