Slashdot Mirror
WINE Still Vulnerable to WMF Exploit
blast3r wrote to mention a ZDNet Blog posting by George Ou, stating that WINE is still vulnerable to the WMF flaw. From the article: "All applications launched inside Wine, Cedega, or Cross-Over Office are technically still exploitable. Wine runs on most x86 platforms, including Linux and the various BSDs. The surprising part about finding this flaw in Wine is that they implemented the entire Meta File API without realizing that this could be a security issue. Exploiting a Windows application running inside Wine depends on that application calling the vulnerable function with malicious data."
I know that you are still exploitable, and that would make anyone whine, i mean, Wine.
We can say now that Linux is truly ready for desktop because it catched up to Windows in these important features aswell!
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
...that wine provided so much of the normal windows user experience. I must start recommending it to my friends
http://michaelsmith.id.au
Should I be worried about my Fake Windows security or am I at no risk as long as I don't run "sol.exe" as root?
How far can someone get by working over WINE with this exploit?
Get your Unix fortune now!
Just ... uhh .. disable it?
So that they can add it to their already lengthy list of known LINUX exploits!
Just a feature, as usual !
On a serious note, I wonder what this means for emulation projects. If you recognize an exploit in the original environment (as possibly someone did when writing a WMF parser for WINE), do you implement the exploit in your emulator or do you introduce a potential incompatibility?
This post is set to run under Linux, but to be vulnelable to Windows bugs. Bug for bug compatability!
Using the Freedom of Speech while I still have it.
Can't you just make a copy of the fixed gdi32.dll from a working windows machine?
So in this situaion, Windows systems updated with the most recent patch are more secure than machines running WINE.
TGIF cause stuff like this makes my head hurt.
"We make our world significant by the courage of our questions and by the depth of our answers." Carl Sagan
I mean, I'd heard the phrase bandied about, but it looks like WINE actually achieved it with its WMF functions!
This reminds me of the initial press release on the Crusoe, one of the clueless reporters in the audience thought that the Crusoe would somehow avoid Windows crashing. One of the Transmeta people pointed out to him that if Windows crashes, the Crusoe will faithfully crash in the same way.
Hello? Anyone awake? All too busy at CSE?
After all, from winehq.org: "Wine has always strived for "bug for bug" compatibility"
Georgia Tech, the leader in Chia(tm) technology.
This shows how great Wine is. It even emulates exploits and being late with the patches! Hurray for Wine!
does anyone use wmf files?
did you forget to take your meds?
How does WINE manage to duplicate a flaw in a function that WINE doesn't even implement?
Lacking <sarcasm> tags,
Wait, but isn't Wine OSS? How can it be that M$ has delivered a patch to a vuln but an OSS that suffers from the same problem is still lagging behind. Why doesn't some intrepid OSS developer just jump in and fix it? Isn't that the promise of OSS. Oh well, thanks to the power of OSS, every single Wine user can just download the latest source, fix the affected code, and rebuild the binaries themselves. Oh and hope that the next release doesn't wipe out what they just did, or that they have the development resources to do the fix correctly and not make things worse.
Considering wine runs on top of Linux, as long as you don't play with knives (AKA run things as root), this shouldn't be a problem.
Well, unless you are worried about you're fake windows...
So all you have to do is run the WINE autoupdater? :-)
John
I suppose this speaks very highly of the WINE developers. After all, they're not out to make something better than Windows: they're out there to duplicate every broken, strange, or inexplicable behaviour Windows exhibits.
Wine is Not an Emulator, but it's purpose is to allow all of us in Linuxland to use software developed for Windows. That means that it must replicate even the broken parts.
Luckily, I assume two things:
1. The WINE devs will plug this as soon as they get around to it.
2. Anyone using WINE successfully is probably canny enough to make due until then without getting themselves compromised.
GeekNights!
Late Night Radio for Geeks!
That's why OpenBSD does not have it working on their platform. :p
Not that lacking kernel threads, or half a dozen other things could be the REAL reason.
Until I can get my Linux box rootkitted by Sony DRM.
Don't tell me I'm the only one who noticed that this site's homepage looks terrible.
No no no, when wine, women and song gets to be too much, stop singing.
The surprising part about finding this flaw in Wine is that they implemented the entire Meta File API without realizing that this could be a security issue.
Remember, the goal of WINE is to duplicate the API as exactly as possible. And up until a few days ago, that *was* part of the API.
WINE isn't supposed to be an improvement, just a duplication of the API so that win32 apps can run on x86 *nix. It should be no surprise to anyone that their implementation of the metafile API is exactly like the one in Windows. That's the point.
Weaselmancer
rediculous.
Virus and malware writers use WMFs all the time :)
or the Darl everyone loves to hate... "Surely WINE contains windows code, how else can it possibly exhabits the exact same flaw? We demand WINE development team to come clean and turn over their first borns as sign of good faith..."
If I got hit with the WMF flaw, I'd go drink some WINE too.
Well, admit however that if WINE didn't have this hole you would post an entirely different story on Slashdot :)
Man, Slashdot looks messed up.
Betcha the Wine team comes out with a fix before Microsoft does.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
Perhaps the ReactOS people should check their code as well, especially since they're starting to implement network support into it for version 0.3.0.
Is this supposed to be an SMS message or are some of the keys on your keyboard missing? Either way, what are you on about???
We're a major financial services/software company, and one of our QA suites uses a WMF file (for what, I'm not sure.) Symantec Antivirus started complaining about this in the wake of the WMF exploit and broke our build, despite the fact that CVS assures us the file hasn't changed in 5 years.
What is this license you speak of and why would I need one for software?
"We make our world significant by the courage of our questions and by the depth of our answers." Carl Sagan
Apparently the exploit method in the GDI DLL is SETABORT (vector 9).4
http://blogs.securiteam.com/index.php/archives/18
-c0d3r-
The surprising part about finding this flaw in Wine is that they implemented the entire Meta File API without realizing that this could be a security issue. ... and your comment:
I suppose this speaks very highly of the WINE developers.
If you ask me, it is more suspicious than anything else. My guess is that someone with access to Microsoft code has (probably on more than one occasion) contributed to the Wine project. That code was probably blindly copied into the project with little-to-no auditing whatsoever.
This takes "bug-for-bug compatibility" to the next level.
Now the king of compatiblity claims is "'sploit-for-'sploit compatible"!
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
Heh.. Actually, in this specific case, I wouldn't. (Though for many other assertions I make, you're spot on ^_~)
I use Wine extensively in my work, typically to allow corporations with archaic, proprietary software developed for Windows to migrate wholly or partially to Linux. I've found that many applications are poorly coded and end up using strange or broken Windows APIs. They'll use a bug as a feature and rely upon it to function.
Simply put, I rely on the Wine guys to implement every "feature" of Windows, no matter how broken it is. Say they'd noticed this and corrected it. They likely would have done it in a slightly different way from Microsoft. Wine would have branched slightly from the Windows API tree, and I would have ripped out more of my hair.
GeekNights!
Late Night Radio for Geeks!
All applications launched inside Wine, Cedega, or Cross-Over Office are technically still exploitable
That's 3 Unix/Linux vulnerabilities to 1 for Windows. Windows is more secure.
Um...is that a joke, or are you unaware that MS already patched this?
If you don't know where you are going, you will wind up somewhere else.
For WINE users, here's a patch.
Wow, I could never imagine this time would come, after all those here's a patch jokes!
Beware: In C++, your friends can see your privates!
Maybe it's an attempt at a troll.
Maybe he's brain damaged.
Maybe the liquid nitrogen has run out and there's not much mentation left.
Maybe he's nine and he's trying to be cool to impress us.
I'm certainly impressed. I didn't know that our canine colleagues had learned how to use computers.
---
ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
I hope the Wine team has a flux capacitor.
This sig intentionally left blank.
It's not that he's a grammar Nazi, it's just that your post was as coherent as Syd Barrett's lyrics.
Why would MS want to supply a patch to WINE? They already patched thier own product.
This just goes to show the WINE project's dedication to accurately reproducing the Windows libraries.
*drum hit*
Thank you, thank you, next show at 10!
Unless the WINE developers have a time machine and are holding out on the rest of us. Incidentally, that would explain why WINE only runs software designed to run on OSes aged 8 yrs. and older.
Well, pay up. What'd I win?
not 9 try 39!!! and i werk for Noble $$$$ winnerz so dont be al hussey mr smarty pants!!! how bout ansering my query insted huh?!?!?1?1?! mabee your the 1 who'se 9!!!!
Chink analyst sez: XBox 360 will fai
I dont lisen to lamea$$ hiphoprapcrap t00! metal r00lZ \m/
Chink analyst sez: XBox 360 will fai
You won the right to post the parent post. Gotta love temporal mechanics ;)
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
run windows... dont see how it could be much simpler
Cedega is not affected by this exploit, as we don't support any META_ESCAPE commands in WMF playback at all.
And Marcus Messier's fix for WineHQ was checked in earlier today. 8-)
-Gav
Doesn't this revelation kinda fly in the face of one of the arguments of OSS that it is more secure because more eyes are seeing it?
Here we've got at least two sets of eyes that missed it, not just the folk(s) who wrote the Wine code, but also the one(s) who wrote the original implementation for Windows... and the only time the flaw was discovered in Wine was AFTER the Windows one was... presumably because someone looked to see if Wine was vulnerable as well.
Help Brendan pay off his student loans
Which changed wine/dlls/gdi/metafile.c from:To:This is first day response.
I am unamerican, and proud of it!
However, I can't quite shake off the creeping suspicion that I've got something terribly, terribly wrong in my model of the world, though, that I feel I have to point out that I told you so. Please, say it isn't just me!!
It's been a while since I've written any WMF software, but if I remember correctly, the problem here is with the general principle of a WMF, not a bug in any libraries, hence windows and wine both being vulnerable.
A wmf is not a graphics format in a traditional sense, but rather a list of API calls to the GDI libraries that when fired off one after another will recreate an image.
For this reason, saying that the WMF insecurity is a bug, is like saying that the fact that you can make a malicious EXE for windows is a bug also.
I'm not saying it shouldn't be fixed, becuase it is a vulnerability, I'm just trying to shine some light on why similar vulnerabilities exist in WINE.
If I have given an incorrect explanation of WMF, please feel free to comment.
Big ones, small ones, some as big as yer 'ead!
Give 'em a twist, a flick o' the wrist...
To answer your question: Yes, Sony should su. Unfortunately they don't have the root password.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Does that mean I have to throw out my stash of these?
Prove it.
...is on Newsforge.
To answer another question I keep seeing:
"Does anyone actually use WMF anyway?"
There are actually some common uses of WMF on windows, but becuase it is a metafile of GDI calls, its not very portable (although it is easy to convert).
Since displaying a WMF is nothing more than enumerating the list into a 'select case' statement (not a very long one either) it is very easy and VERY fast to display on Windows. (Really no processing is required). For this reason, microsoft uses WMF for all the MS Office clipart, and you'll find many other very-microsoft centric applications using it as well.
Big ones, small ones, some as big as yer 'ead!
Give 'em a twist, a flick o' the wrist...
Six days after m$ft learned of the vulnerability, we were all yelling that it shouldn't take that long for a fix and thank heavens that open source projects could always churn out fixes so much quicker. Well, the open source wine has now had 3 days. Does that mean that if wine takes another 3 days, then we've proven that open source isn't always faster with fixes?
Mod parent up!
Thanks for letting us know, Gav! Transgaming rules!
I'm pretty sure a more accurate expansion of WINE is: Wine Is Not a (CPU) Emulator. See the Wine FAQ. As you correctly point out, Wine emulates (implements?) the Windows API, using the native CPU to execute code.
Just: cvs update && make World && sudo make install
Patched, Fixed, Done.
If you RTFA, you'll even see that the very person to report that WINE was flawed the same as Windows submitted a patch to fix the problem along with his notice that it was broken.
THAT is how fast OSS is. The very vulnerability announcement says how to fix it.
I am unamerican, and proud of it!
Alan Paller at SANS keeps calling this a "programming error" which I think is a load of BS. This WINE article only proves it - this is poor design from management folks. The trick is, security needs to be a core part of system design from the initial phases of the software lifecycle, and then at every step of the software lifecycle. This is not something only for Programmers and pure-tech folks. Now your Project Managers, Analysts, and even your upper management needs to understand the COSTS AND ADDITIONAL TIME ASSOCIATED WITH HIGH-SECURITY PROGRAMMING.
Horns are really just a broken halo.
The code is definitely not from Microsoft.
DEFINITELY not from Microsoft.
I am unamerican, and proud of it!
I know that excessive use of Wine usually makes me insecure.
I do believe they have abondoned that project, and moved to OSX86, which would be much easier to code for.
Too bad that leaves us PPC users out in the cold.
---- Booth was a patriot ----
You have dictionairies? Why, back in the day, we had to get our elders drunk then listen to them tell stories in the olden tungues. And they always lied, too, and WE LIKED IT!
This really still could pose a threat to people running office under wine. All of your saved passwords for websites are stored in your home directory somewhere abouts, and your home directory in fake windows is mapped as Y:\ If somebody wrote an exploit for that, they could access personal data, and erase your files, but that would probably be on average the extent of how far the damage would go. I think their is a whole lot of bias going on here towards microsoft. Everybodies first reaction when they find out that WINE has the WMF flaw is to: 1. Bash Microsoft, calling them the author of all "buggy" and "flawed" 2. Praise wine for failing where microsoft failed by calling wine "closer to windows" 3. Bash Microsoft some more 4. Worship linux, the all-mighty bug-free security-flawless operating system. I'm failing to see some real rational thinking going on here.
A formal API is basically published documentation about how it works. Since Microsoft hadn't published the docs about every quirk of their implementation of their APIs, there's a lot of flexibility in how it will be implemented.
WINE takes that a step farther, though.. they're trying to implement the undocumented behaviors too. They do this mostly by running known-working windows software and seeing where it breaks in WINE. Where it breaks, this indicates a place where the WINE implementation of the API either a) doesn't conform to the documented API or b) doesn't conform to the quirks. So WINE does, as you suggested, have to get pretty close to doing exactly what Microsoft does in the implementation.
But even within this restriction there's a lot of wiggle room. No "known-working" software would rely on an exploit; to put it another way, software that made use of the exploit intentionally would not be used to prove WINE's implementation was reliable. Therefore, there's no reason for WINE to implement it that way.
All of this begs the question "where did the exploit come from?" Until I read otherwise, I'm going to assume MS and WINE made use of the same underlying library, in which case WINE is merely sharing a single buggy implementation rather than cloning a new one.
Is that so hard a concept to understand?
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
slashdot design looks strange today
You just want me to commit a felony by refreshing it to see if I see what you see, don't you?
The problem with this argument is that the announcement that Wine also suffered from this vulnerability included a patch to fix it, so that's a 0-day response between discovery and fix.
WMF is not supposed to be any kind of code affecting the display and certainly not arbitrary x86 code. Therefore, this is a bug, but the bug was caused by the format design omission to allow the specific escape code used.
but afaict wine is not a jail and there is nothing stopping code running from it making linux syscalls directly bypassing wine and its set of virtual drives.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
If the exploit works, does that mean MS protection will work... in other words ....any one ever try that?
What about MS AntiSpyware on Wine?
I've always assumed that they were making the first wife / second wife distinction.
Your second wife may provide all the services that you first wife did ("Please pass the salt" gets the salt handed to you just as before) but that is only an implementation of the same API--it doesn't mean that your second wife is "emulating" your first wife.
If, on the other hand, your second wife discovers that your first wife used to have some bizarre behaviour (say, she would occasionally wake up screaming "Now Dasher! now, Dancer! now Prancer and Vixen! On, Comet! on, Cupid!" etc. in an overly excited voice even when it was nowhere near christmas) and your second wife decided to start doing it too solely because it's what your first wife did, that would be emulation.
To give a less whimsical example: a browser such as Opera isn't "emulating" Firefox just because they both render HTML, support javascript, etc. Only if the Opera folks were to add a "Firefox quirks mode" that also attempted to duplicate all the overt behaviour of Firefox would they be "emulating" it. (And to be "simulating" they would have to be duplicating the overt behaviour by virtue of having in some sense the "same" internal structure.)
-- MarkusQ
LOL, it seems, the authors of Wine project simple have stealed the code Win32 API from Microsoft... :o)
Apparently one of the great things about open source is that many eyeballs makes all bugs shallow.
Yet WINE developers missed this one and delivered insecure code. What happened to the shallow bugs? Where were all the eyeballs?
And then they take longer than Microsoft to fix it, despite us being told that with open source anybody can fix it, response times are faster, community can turn around a fix in hours, blah, blah.
I guess all of this pre-supposes that there is a large group of open source developers who care about such things. Do they exist? Do they care?
So this affects like, 4 people? Maybe 5?
I kill harmless processes for sport
... that when the WINE Coders were coding the Metafile APIs, they:
/.?
1.) Did not realize this was a design flaw (most likely).
or
2.) Realized this was a security flaw and have been explioting it since years ago (highly unlikely).
or
3.) Have been urging Microsoft to change the code since they realized (highly unlikely, as well).
The point I am trying to make is that this design flaw was not spotted by the many eyes of the WINE project, showing that even the OSS development model is subject to mistakes.
The intent of this comment is not to say which development model is better, just to point out the fact that ALL development models are subjet to failures, and that our analysis should not be so unidimensional and binary, a thought that seems to be quite lost in this particular thread.
As an aside, if this atack was made public in 12/27/05, and confirmed by Microsoft in 12/28/05, shoudnt have the WINE comunity tested for the flaw, posted a preliminary patch ASAP and then post a definitive patch that mimics the efect off the Microsoft patch? Why to produce the patch just AFTER Microsoft posted theirs, late by the comon wisdom of
My other question our regard a Turing-Complete "Image File Format", Postscript. Given the complexity in Postcript, is it not possible (but most likely harder, since it can not touch Filesystems) to do exploits in it?
Just my two cents
*** Suerte a todos y Feliz dia!
Is using IE or Outlook on WINE? In fact I think that only WMF embedded in DOC, XLS, PPT files might infect WINE.
Absolutely right. A WMF is really just a list of GDI calls saved to a file. It is not an "Image" file like JPEG or TIFF (although TIFF can actually contain non-image data too).
GP is NOT informative.
Lump lingered last in line for brains, and the ones she got were sorta rotten and insane.
But the facts are that the original design was made pre-Win3.0, long before the rise of the internet as we know it today. It's not surprising that the design flaw arose in that environment, and the design was used to deal with the hodge-podge of various printer behaviors from those days. And I don't particularly blame the actual handful of Wine devs that implemented the "whole API" and therefore inherited this design flaw.
But I do place blame on the OSS community.
Allow me to quote from Engaging with The Open Source Community:
This flaw was staring the OSS community right in the face for all this time, yet the OSS community failed to find it. Of course, I'm being too hard on the OSS community. I wouldn't expect that community to find this problem. But nor should you. The "many eyes" claim is a canard because in truth very few people not involved in the actual development of a particular piece of code actually examine that code for flaws, and even fewer can identify a flaw even if it's staring them in the face as clearly as this one.
-- "I never gave these stories much credence." - HAL 9000
It's also worth noting that no matter how you feel about Microsoft, they have thousands of people writing code for them - and none of them found this exploit. Wine right now is a couple of dozen guys.
And they have bigger fish to fry, like getting DCOM working correctly so installers work, getting copy protected CDs to work correctly, and implementing DirectX fully.
Weaselmancer
rediculous.
But the facts are that the original design was made pre-Win3.0, long before the rise of the internet as we know it today. It's not surprising that the design flaw arose in that environment, and the design was used to deal with the hodge-podge of various printer behaviors from those days. And I don't particularly blame the actual handful of Wine devs that implemented the "whole API" and therefore inherited this design flaw.
Are you being smug or are you trolling on purpose? There was no pre-Win3.0 gdi32.dll. There was no hodge-podge of printer support. They all printed to LPT1 with thier own escape-codes that the software developers implemented. I print to my year old Samsung laser using my twenty year old AppleWorks. You do know that WINE can use its own built-in DLLs or Win32 native DLLs, don't you? I can switch Wine to use the Gdi32.dll that Microsoft just provided for free.
This flaw was staring the OSS community right in the face for all this time, yet the OSS community failed to find it.
I don't think the Wine Developers are looking for flaws. Most of us use Wine to play Windows Games. In what aspect is my WINE/Linux environment compromised by this Microsoft flaw? There is no kernel to infect. Are the rootkit trojans going to infect my Starcraft session and turn the Zerg into lemmings? Are you mentally challedged?
We appreciate that you like Windows, stay there. When your ready to switch to a environment that doesn't believe that you owe a fee every three years and that you own your own stuff, let us know.
Enjoy.
It's just the normal noises in here.
I have the latest test files created from version 1.17 both OFFLINE and ON-LINE as well as zip files for the last two prior releases 1.16 and 1.14 located here: http://www.dslreports.com/forum/remark,15188688#15 188722
They can be used for testing, also there is an patch NOT supported by Microsoft for those running Windows 98 here:
http://www.nod32.ch/en/download/tools.php
It should be noted that these files have been used for many days and are safe for testing.
Black Gray White Hats Unite to protect http://testing.OnlyTheRightAnswers.com
While I understand what you mean, I don't really buy it as an excuse. You could just as easily argue that postscript is not a graphics format, or hell even jpeg. All files tell the computer to "do something", and you need to be careful when doing whatever it is they tell you. Just becasue the contents of the file match up to function calls in a dll, that doesn't mean you have to pass it directly to the particular funciton.
.exe for windows is a bug. .EXE is a file format same as any other, be careful what you allow them to do on your OS implementation.
And, the fact that you can make a malicious
I just updated my system and it seems that the new version has been released. At least through their apt repository that wine hosts themselves anyway.
A wmf is not a graphics format in a traditional sense, but rather a list of API calls to the GDI libraries that when fired off one after another will recreate an image. ... For this reason, saying that the WMF insecurity is a bug, is like saying that the fact that you can make a malicious EXE for windows is a bug also.
As I understand it, WMF files are allowed to register a callback function that will be executed in certain situations. The code for such a callback function can be embedded in the WMF file itself! Allowing a graphics data file to execute arbitrary code when being viewed is the height of stupidity and just begging for an attack exactly like the current vulnerability.
So, maybe you are right; this is not a bug. Instead, it is a stupid design decision in Windows that was never considered at all in the sense of security. Now, how much do you trust any other decisions made in Windows design?
If they just copy the bugs / exploits. Isn't one of the arguments in favour of OSS meant to be scruitny of the source revealing things like that? Hey, I even bet the original exploiters of this might have got the idea from examining the source code. OSS creates dangers like this, it should be illegal...
The short time when windows is the only OS not vulnerable to a windows exploit and linux is?!
What were the wine developers doing during the week+ we were going after MS for not fixing it?
No, many eyes is actually good.
;) ...
There is alot of people that search for bugs allmost everyday and allways seems to find some.
The problem is that these people are out to exploit this bugs
LOL, it seems, that you are babbler :o). Developers of WINE only implemented bad Win32 API.
I'm curious to know what the exploit is about that it could have been present in two different implementations? I understand that WINE has implemented the API, so is the vulnerability not an implementation of drawing routines but of the spec of the API itself?
I like my dinosaurs feathery, and my pterosaurs hairy (or is it pycnofibery?)
As a free software community member I don't use WINE, as it primarily exists to let people use non-free software, so my eyes aren't on it, it isn't installed on my box, and I'm not that interested in it.
Clearly there is code that has more eyes on it than others. Similarly free software sees a lot of automated code audit, which I know hasn't historically been a high priority at many commercial software organisations. But it won't spot stuff like this.
I'd guess the people interested in secure design aren't interested in reimplementing Windows APIs.
So perhaps the WINE developers missed it as well as Microsoft, but it is inevitable they will reimplement Microsoft security flaws, as so many of the problems with Windows are structural. It isn't really their job to fix Windows.
If you read the fucking article, you would have seen that Marcus Meisner of SuSE had already created a patch and passed it on to the Wine team. So get your facts right, Billie Boy, before you troll. Fucking moron.
I think you state it accurately, it was not a bug, becuase it was the intended behavior, it was instead a really stupid design idea probably caused by a lazy designer.
Big ones, small ones, some as big as yer 'ead!
Give 'em a twist, a flick o' the wrist...
#ifdef FIREFOX_QUIRKS_MODE
#define CALLED_IN_EVERY_FUNCTION sleep(2)
#else
#define CALLED_IN_EVERY_FUNCTION
#endif