Slashdot Mirror
WMF Flaw not a Backdoor
koro666 writes "In a blog post, Mark Russinovich from SysInternals responded to the allegations made by Steve Gibson labeling the flaw as an intentional backdoor. It seems that the hype was about Steve's discovery that the code would only be executed if the size of the metafile record was deliberately tampered with, which is not the case. The technical details are explained in his post."
Conspiracy theories don't need reasons backing them up. I still think that microsoft eats babies.
I'm sorry. The number you have reached is imaginary. Please rotate your phone 90 degrees and try again.
Well, googlefight has Russinovich on the ropes, Gibson comes out well on top as far as hits go.
However, Mark has been gaining himself a decent reputation recently.
I know whos opinion and factchecking I trust at the moment.
Mark Russinovich
483,000 results
Steve Gibson
13,700,000 results
liqbase
Not quite a backdoor in itself, but it makes a very nice doorframe. Complete with the Windows 'critical flaw of the month' moulding and Welcome mat placed in front of it, just ready for someone with a door to install it into the wall...
Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
At least not many people I know.
I think the real question about this WMF vulnerability is how on earth could it have survived five years under the new security aware, code auditting regime that we supposedly have at Microsoft?
(Please don't reply that the wine people implemented it too - their goal reimplement the windows API, not audit it for security)
My pics.
read topic much?
because the issue continues to draw media attention I've decided to publicly document my investigation.
:)
i.e., I'd better hurry and get this out before nobody cares.
FREE - Java, J2EE and Ajax Audiobooks for Software Developers - www.DeveloperAdvantage.com
And already had a link refuting the claim that an invalid record size is necessary: http://blogs.technet.com/msrc/archive/2006/01/13/4 17431.aspx
I think the real question about this WMF vulnerability is how on earth could it have survived five years under the new security aware, code auditting regime that we supposedly have at Microsoft?
(Please don't reply that the wine people implemented it too - their goal reimplement the windows API, not audit it for security)
Sorry if I don't care about your rules for what I may and may not reply, but that the wine group did implement it says a whole lot of how difficult it was to spot. Their goal was to reimplement the API, sure, but you can bet your ass that they would have reported it if they saw it. And they did, despite it being right under their noses. Even Russinovich makes this point (but I guess you didn't really read TFA anyway, did you?). Forgive me if I trust his judgement a little more than yours.
That doesn't say anything bad about wine coders, who, as we all know, are pretty good coders, but it does about the subtlety of the issue. Yes, MS deserves some blame. But let's keep things in proportion -- this was a tricky little bug.
First of all, that was extremely wordy article to explain the WMF vulnerability, IMHO. But some important points were made:
...given a choice of believing there was malicious intent or poor design behind this implementation, I'll pick poor design.
if an attacker can get your computer to execute their WMF file through Internet Explorer or Outlook, for example, they can make your system execute arbitrary Windows commands, including downloading malicious applications and launching them.
My belief is that Microsoft developers decided to implement as much as the GDI function-set as possible.
In any case, its not clear that the developers envisioned applications creating on-disk metafiles with abort procedures.
Either way, it is still hard to tell why it was designed that way in the first place, maybe one of these links can tell us?
He who knows best knows how little he knows. - Thomas Jefferson
Well, as their name subtlely denotes, backdoors are on the back, hence the difficulty to spot them if not proactively looked for.
That must be the raison d'etre for constructing them in the back.
And, to conclude, if it is built like a backdoor, and squeaks like a backdoor, it must be a...
My other post is a First.
Sorry if I don't care about your rules for what I may and may not reply, but that the wine group did implement it says a whole lot of how difficult it was to spot.
My point was that the wine people's goal was to reimplement. Not audit.
MS's goal over the last 5 years was to audit. You would think they would have looked particularly hard at code with roots in Windows 3.1 (which, as Russinovich pointed out is a common source of poor API design)
Their goal was to reimplement the API, sure, but you can bet your ass that they would have reported it if they saw it. And they did, despite it being right under their noses. Even Russinovich makes this point (but I guess you didn't really read TFA anyway, did you?). Forgive me if I trust his judgement a little more than yours.
Well, forgive me if I don't trust some MS shill posting anonymously on slashdot, especially when they say:
That doesn't say anything bad about wine coders, who, as we all know, are pretty good coders, but it does about the subtlety of the issue. Yes, MS deserves some blame. But let's keep things in proportion -- this was a tricky little bug. [emphasis mine]
MS deserves some blame? Who else should we blame? The wine group? Mark? Steve Gibson? Slashdotters?
Microsft deserves all the blame for this - they're responsible for the bad design, the bad implementation and the lax audit. Suggesting they only deserve a portion of the blame shows your bias.
My pics.
by stupidity.
Why waste time putting in a backdoor? Just ship the OS around the world and enjoy.
With an expensive scaled up consumer operating system - the operating system is the backdoor.
Domestic spying is now "Benign Information Gathering"
So, why would M$ (or anyone there) need to create such an elaborate "back door" to Windows? I mean, they could put anything in anywhere they wanted to. If they wanted to download some stuff to my PC and execute it they could distribute it as an update. They could add the code to IE or the kernel. This is one of the dumber conspiracy theories I have read.
"how on earth could it have survived five years under the new security aware, code auditting regime that we supposedly have at Microsoft?"
It takes time to look trough 35 milion (Windows 2000) - 40 milion (Windows XP) lines of code...even for a big company.
Slightly off topic but I was plesantly supprised to see that in Visual Studio 2005 (probably where there already in VS 2003 but I've never used that one) most of the offending runtime functions (memcpy, strcpy etc) have been marked deprecated and replaced with more secure functions checking for buffer overflow.
Many other functions such as to stop hijacking of the stack pointer etc have also been implemented.
http://www.intellipool.se/ - Intellipool Network Monitor
How did it get into Wine? Well, there are two ways it could have done. One involves Microsoft documenting the behaviour of the relevent calls, which, the TFA implies, they did. They did it in the context of the printing subsystem, but it was, certainly, documented, and the reasons explained in that documentation make sense. This is almost certainly how the behaviour got into Wine.
The other possibility is that there are a lot of WMFs around that make use of the feature, and after debugging, the Wine people found it worth implementing for compatabilities sake. We can safely assume that if there are that many WMFs around that us4e the feature, and they're not trojans or viruses (which we can assume they're not otherwise the Wine people wouldn't be trying to be compatable), then, again, Microsoft's reasons for incorporating the feature are, on the face of it, legitimate, and they're implementing something many programmers find useful.
As usual Steve Gibson, like his brother Mel*, is seeing conspiracies that appear to have more to do with his dislike for those he disagrees, and, even more probably, his wish to attract a large audience of people who dislike them even more, with than any real bad faith on (Microsoft)'s part. Unlike Mel, he doesn't seem to be that successful, probably because the vast majority of the audience are a little more open minded, their open intelligence and open-mindedness often being the reason they dislike the dominant operating system seller in the first place.
* Yes, I know he's not his brother, I'm just making a point.
You are not alone. This is not normal. None of this is normal.
... when you can just throw a small rock through windows!
If you want to render something postscript-like onto a screen, why not just reuse the printer code?
I can see how it happened. The original introduction of setabortproc violated separation of code and data, but it was needed for performance - and on the kind of hardware win3.1 ran on, that was vital. I suppose it shows that you should never compromise on design for the sake of performace - but in the real world, you have to. May I also point out that if the x86 had a working way to mark memory non-execute then this wouldn't be a problem.
I am trolling
Perhaps Steve would like to present his findings at the next DunceHats security conference. We could do with people of his caliber.
Tim Brown
Excuse me if i'm wrong but i believe this post was stolen from a previous artical way back when. I know this why? because i sit at home in my mothers basement looking at slashdot all day and have a kick ass memory ... almost as good as ecc ram!
If i wasnt a lazy slashdot junky i would actually go looking for this posting but at the end of the day the GP being the 1st post and being so long at the same time makes obvious sense that it was c&p from somewhere.
and that's all Steve Gibson does. If I read one more blurb about how great it is that he can code in assembly...
This guy is way out there
Steve Gibson gave his final word on this matter in a thisweekintech podcast interview: http://thisweekintech.com/sn23 Briefly, someone at Microsoft had the bright idea that one should be able to run code inside an image, for whatever reason. This left a backdoor, probably unintentional. Mr. Gibson regrets that his use of the term "backdoor" implied malice to some people. This was not his intention.
I mean, if I worked for Microsoft, given the context, I can tell you right now that had I invented WMF, I probably would have made a similar error in the name of "flexibility", and I would have assumed that computers in five years time would be using real-time EPS (that's embeddable PostScript, the initials standing for Encapsulated Post Script, for you young'uns, that's what we were all talking about then as being the future of vector formats) renderers, not WMF, seeing it as a short-term hack until processing power became powerful enough. I certainly would have been surprised to see it still in operating systems in 2006. I'd have been surprised to see the ix86 range in computers in 2006.
Bad faith on Microsoft's part? Bullshit. Microsoft made no effort to hide this one. It made sense they implemented it that way given the context. It was an error, a short-termist attitude which has undermined many a Microsoft product. Until the late nineties, Microsoft was routinely making such errors, the most infamous being the support for embeddable, automatically run, Visual Basic scripts in Word documents. Why this is being treated as any different to every security error Microsoft has made in the past is beyond me.
You are not alone. This is not normal. None of this is normal.
This is more of a hole than a door.
You are not alone. This is not normal. None of this is normal.
I think everyone would agree that Steve Gibson is a technically-gifted person, but we should also agree that the guy is a little wacky, just like we should also all agree that Theo De Raadt is a little hot-headed. Not that this makes Steve or Theo a bad person - quite the contrary! It's just that when they make grand pronouncements, the pronouncements should be viewed skeptically. Anybody remember the controversy over NSAKEY a few years ago? I.e., a flurry of wild allegations over something used for code signing that no one now cares about now that it's named something less offensive (_KEY2 for those playing along at home). It's easy to get all hot-headed and worried and freaked out, but that's the antithesis of what a information security officer is supposed to do. They are supposed to stay calm and rational in times of crisis, never jumping to conclusions (because most of the time, those conclusions are worse than wrong: they are misleading). Well, I'm ranting but you get the picture.
I'm proud of my Northern Tibetian Heritage
Gibson is an idiot with a talent for self-promotion.
Big time. He's the guy who came up with broken SYNcookies and blathered on and on about how they were "Beautiful and Perfect". Gibson is a quack and no serious attention should be paid to his ramblings.
We have more to fear from the bungling of the incompetent than from the machinations of the wicked.
Not to add to the continual Linux vs Windows battle-royal here on /. but this is exactly where being able to look at the source code helps. There would be no conspiracy theory if we could see the code related to WMF files. The most we'd be able to do is say "Damn, why'd they do it that way?". As one of the readers already posted, Mark Russinovich has seen the NT source, and is in the best position to say what is or isn't in the code. The rest of us are left to listen to whatever source seems credible at the time and hope they're right. Hiding things from your customers leads to just this sort of public speculation, and when you're the voted "Most hated monopoly", public speculation isn't really ever going to be in your favor.
Either way, it is still hard to tell why it was designed that way in the first place, maybe one of these links can tell us?
It's quite simple:
WMF is used under the hood in lots of places in GDI. Any time GDI passes a bunch o' commands from one place to another, you'll find WMF. And as a result, WMF encapsulates almost everything you can do with GDI.
SetAbortProc is used to allow an app to display a custom "Printing Page xxx of xxx... [Cancel]" dialog to be displayed on Windows 2.0, 3.0 and 3.1, all of which are cooperatively multitasking and so need to drain their message queues on a regular basis - which they do every time that AbortProc is called.
There are even examples of this exact behavior on MSDN. It's still semi-useful under later versions of windows to be able to do this, and it's good for backwards compatibility, so it stuck around.
Coming soon - pyrogyra
What else is there to say? It's a bit of legacy code left over from the days when it was safe to assume that any code on a computer had been put their with the owner's knowledge and consent. That assumption has since been invalidated by subsequent events. A backdoor it may be -- but when it was put there, there used to be a fence around the back garden.
And this is just one example of a whole class of things that are really, seriously, terribly wrong with Windows {and for that matter, closed-source software in general}. A lot of benign application software has come to depend on behaviour in the operating system that ought never to have been allowed in the first place -- behaviour that makes the propagation of viruses and worms so much simpler. Now, if Microsoft change the way Windows works so as not to just hand out permission for any process to interfere with any other process, then the worms and viruses that depend on this behaviour will die off -- but so will all those applications that depend on this broken behaviour. Then what used to be a choice between "Stay with Microsoft, and all your old software will still work like it did before" and "Leave Microsoft, and none of your old software will work anymore" becomes one between "Continue to splash out good money after bad to Microsoft, but none of your old software will work anymore" and "Wave goodbye to Microsoft, none of your old software will work anymore but there are better-than-adequate replacements for all of it".
And my prediction? A company that still makes extensive use of an obsolete software product will find themselves -- and their precious data -- orphaned as a consequence of the switch to Vista. They will have to obtain a pirated copy or copies of an earlier Microsoft OS {because there is no way to obtain a legitimate one} just in order to read their own files. This will only be discovered in a Licencing Gestapo bust.
Je fume. Tu fumes. Nous fûmes!
Well lets think a little bit here, I guess Linus intentionally allowed a back door into the Linux kernel as there have been security bugs that have lasted back into the pre 1.0 days. Going past bunches and bunches of seucrity revies (many more the WMF one). So I guess those must be really, really secret backdoors.
Kool-aid, how about you taking off the tin-foil hat and come back to reality. FYI there was an article posted here that said they don't help at all.
But it succeeded in getting people to see the name Steve Gibson on a website again. From the plagarizer of SynCookies, the father of Raw Sockets paranoia, comes a new wild and unfounded allegation, WMF bugs put there intentionally to let Microsoft SPY ON EVERYTHING YOU DO OMGWTF!
I can't believe people on the last thread actually took him seriously without looking at his past media whoring failed attempts at security analasis.
Steve Gibson is the Bob Lazar of the security field, only wackier.
I like music
We're talking here about a file format designed in the late eighties, based upon the original Win16 API, with support for callbacks, designed then, not in 1999, to be written in 80x86 assembly language. You bet implementing that in a modern OS would cause security problems. We can be armchair operating system designers here and say that Microsoft should have adopted something more akin to EPS, complete with sandboxed programming environment, back when it became viable, but it's one thing to say "Microsoft, you suck!", it's another to claim they're Sonying our machines.
If I had to find a paranoid, Microsoft is evil, reason for this, I'd say follow the anti-trust behaviour trail. They continued to support, and encourage the use of, a major file format with a key feature couldn't be fully supported on any operating system that didn't implement a significant part of Win16? I wonder why that would be!
You are not alone. This is not normal. None of this is normal.
So, you think that M$ can and have put backdoors into your system
Did I say that? I can't remember saying that I think M$ has put backdoors in my system. I was just saying that they can, easily. Would they? Probably not. They would be stupid to. As with most conspiracy theories this doesn't take into the account the simple fact that in any sizable organization, CIA included, you simply cannot keep secrets for that long.
If M$ put backdoors in their systems employees leaving M$ for one reason or another, would sooner or later tell the world. Having as many employees coming and going as M$ has makes this every bit as safe as the checks you "automatically" have in Open Source.
but you still use it?
I am not, as seems to be the case with a lot of Linux advocates (to the strong detriment of Linux may I add) religious about what Operating System I use. I have two desktops, one for Windows XP and one for Linux (currently running Fedora, but that changes regularly). I also have a laptop that dual-boots into Linux. I use Linux for most of my work stuff, and I use Windows XP for most of my home stuff which mainly includes video editing.
I'd use Linux for video editing too if there was a decent "prosomer" editing app for it, but there isn't, not even close.
Mark doesn't have access to NT source code. Never has. This is a common misconception.
He's a technical writer, not a psychologist. Why should he write about motivations. A classic adage goes, "Never attribute to malice what can be explained by stupidity". Steve jumped the gun in a BIG way. Microsoft's actions over time have been explained by many as being malicious. I never saw Microsoft as malicious at the coder level. Most developers at Microsoft love their jobs and could give a crap about a competitor - let alone coding in something to "cut off their air supply".
Windows sucks for the reason you have pinpointed. It is backward compatible to the point of killing itself. Compatibility code was one of the single largest attack surfaces I recall hearing about during the security code review in 2001. Windows doesn't get culled regularly for "old code" or "bad code" as those aren't binary values - those are hard things to discern in an automated fashion, so they get effectively swept under the rug. Code doesn't get removed in Windows. It just gets forgotten. Seriously.
I agree his explanation is a bit off, but I still feel this is a mistake, not something intentional.
Where he is wrong is his assertion that MS saw any reason to put the AbortProc into WMF files. The fact that they work at all is entirely by accident, nobody went and typed in any code that is executed only for making AbortProc run from the file.
What happened is they had an interface of a few hundred calls to print and control printers. They wanted three things: for the calls to work, for the same calls to write a WMF file, and for reading the WMF file to do the same thing as the original calls. The only reliable way to make sure the WMF file does the same thing as the original calls is to make sure they call the same code.
To do this, they made up an enumeration for every call. Every call was then recoded to turn it's arguments into a block of data, a length, and the enumeration value, and to call a central function. This function first checked if a WMF file was being written, in which case the enumeration and block of data was written to a file. Otherwise it ran a big case statement or dispatch table to code that took the arguments back out of the block and implemented the function. When reading a WMF file the reader extracted each enumeration and block and called the function as well. This meant that if the direct call worked, you were almost certain that the write and read of the WMF file worked, too.
It is highly likely this central function did a lot of other code before running the dispatch (such as check if the printer actually exists), and the SetAbortProc needed to do that code as well. So somebody implemented SetAbortProc as another enumeration, and stuck the code pointer into the already-available block pointer, and called the central function. I would guess that they left the block length as garbage (somebody needs to find out if you can write a SetAbortProc call to a WMF file using the normal interface to see. I bet it is not possible to create a usable file this way).
Without any planning they now have the backdoor. If you manually put the enumeration for SetAbortProc into the file, the file-reading code blindly calls the dispatch with that enumeration, a pointer into the file, and a length (which will be ignored). The dispatch calls the interpreter, which sticks the pointer into the AbortProc pointer. I expect the dispatch function also calls the AbortProc as the first thing, so the very next record causes the code to be executed.
Two things about this:
First, the code must have contained an obvious cast to a function pointer from a data pointer. This should have been trivial to catch with automated auditing tools. Once detected, it should have been easy to prove that the normal interface could never write a working SetAbortProc to the stream, so there was no reason to interpret it, and rip the function out of the dispatch and recode SetAbortProc to set the pointer directly.
Second, it is a good reason why such designs are trouble-prone. A stream-based interface is better, where the user code constructs the stream in a buffer, and the contents of this buffer, rather than the calls used to fill it, is the definition of the API. In this design they never would have reused the interface for SetAbortProc.
Another thing this points out is just how much Microsoft resists open standards. As far as I can tell, the chief reason WMF was and is still widely supported in Windows is that it effectively emulates vector graphics. How many opportunities did Microsoft turn down to put in SVG, PDF, or similar support?
The sociology of this is more interesting than the programming details, in my opinion. It often happens that one person in the computer industry analyzes an abuse, and another person, who is competing for attention, attacks the first person. Admittedly, Steve Gibson of grc.com has a flawed, exaggerated manner of communicating. But many abuses never are fully recognized because technical people attack each other, rather than analyze carefully how they are being abused.
:-("
As others have mentioned in comments I have excerpted below, the U.S. government stated clearly and for the record that it wanted access to all computers. It appears that the government got what it wanted in what I think I can show logically is the only way possible.
Mark Russinovich of SysInternals is an extremely competent programmer. His utilities for Windows are the best available. Even Microsoft recommends using them, to supplement the limited and unfinished and flawed utilities supplied with Windows. However, Mark Russinovich is not a sociologist, so his comments may not take into account the complexities of the social issues.
The main issue seems to be, not that graphics files have the ability to execute code, but why was there inadequate testing in the code to prevent security vulnerabilities?
Here are quotes from Mark's article:
"The actual reason is lost with the original developer of the API, but my guess is that he or she was being as flexible as possible."
And: "... given a choice of believing there was malicious intent or poor design behind this implementation, I'll pick poor design. After all, there are plenty of such examples all throughout the Windows API, especially in the part of the API that has its roots in Windows 3.1. The bottom line is that I'm convinced that this behavior, while intentional, is not a secret backdoor."
Mark's perception of Microsoft's sloppiness seems correct to me. I coded a program for Windows 3.1 using the Windows 3.1 API that dialed to a bulletin board and downloaded stock quotes. I was amazed at the extreme sloppiness and bad design of the Com port API. The actual code that Microsoft shipped had the quality of code that I would expect from an overtired programmer's first draft. A rested programmer would not have been so sloppy, even in his first proof-of-concept code.
Quotes from the comments:
"Thanks for this excellent analysis! Steve Gibson certainly does not deserver to be taken seriously by anyone, but unfortunately he is
This is a reference to the fact that Gibson's language often contains a hysterical, exaggerated quality.
Another comment -- This commenter makes the point that Microsoft had hired a technically knowledgeable top manager, who would certainly demand that programmers check the security of any code that is supplied by a user:
"Q: When was this backdoor coded?
A: About 1992.
Q: How old was VMS at that time?
A: 15 years.
Q: Who directed the development of Windows NT?
A: Dave Cutler.
Q: What's Cutler's background.
A: Directed VMS at DEC.
Q: On who's watch was this security lapse ported into the Windows NT stream.
A: Presumably Cutler's.
While anything's possible, it's hard to imagine how a security lapse of this magnitude (trusting user-written code) could have made its way into VMS code.
"The point is that Stephen Toulouse's "the security landscape in the early 1990's was very different than today" is, well, self-serving. Only in MS's myoptic view is this the case."
Another comment:
"Now that I think about it, even Mark has to guess at what some coder was thinking when she wrote this, and maybe she did it intentionally. You'll never know will you? Maybe somebody's been watching all of us for years, and it ends up in some massive NSA database."
An
Conspiracy theories don't need reasons backing them up.
There is no way to disagree with that, if one accepts the anthropomorphism. s/theories/theorists/ would make this a stronger statement.
But whatever... At the time this particular exploit was introduced into Windows, there was definitely a conspiracy within Microsoft that involved at the very least mucking about with the documentation of the Windows API.
One of the reasons that Win30 and Win31 succeeded in capturing the market so quickly was because MS made the Windows API available to application competitors, notably Quattro Pro, then from Borland, and WordPerfect, then from WordPerfect. MS presented Windows as being a Good Thing for the entire software industry and got a lot of needed buy-in on that basis. During the development process for Win31, it was highly significant to the marketplace that Borland, WordPerfect, and other industry leaders of DOS software were writing native Windows versions of their applications, and urging their customers to upgrade from the DOS versions to the Windows versions. (The DOS versions ran better under OS/2 than they did under Windows since OS/2 had preemptive multitasking; moving the market to Windows versions of these products was critical to MS if Windows with its cooperative multitasking was going to survive the OS/2 challenge).
But MS wasn't playing fair: when Win31 came out, Excel and Word danced rings around Quattro Pro and WordPerfect. And when people started to look at how MS was able to get such better performance out of the same API, they found that the MS application coders were not using the same API at all: they were relying on undocumented features and features that were documented in misleading ways.
This and similar shenanigans from MS are matters of historic record, vetted by the courts. There can be no question that MS is a company that has used conspiracy tactics to gain market share. There can be no question that MS was doing this at the time it implemented the WMF structure under Windows.
Where does the WMF vulnerability fit in, in light of this background? Obviously it was not written initially as an internet backdoor.
But consider an MS application that used a trademarked WMF graphic on its splash screen. That graphic could run a small bit of code that would unlock hidden capabilities in the Windows API. For example, it could set DEBUG=TRUE in some low level part of the task scheduler, turning off chunks of code that other applications would have to wade through, and thus making the MS app so much more efficient in a way that would be undetectable even on dissassembling the code. There is no technical reason why the WMF vulnerability could not have been used in this way. There is no question that the MS corporate culture of that time would have celebrated and rewarded this kind of cleverness. In view of this background, and the fact that this vulnerability managed to survive the intense scrutiny of several major code revisions, the only reasonable assumption is that the WMF vulnerability is a deliberate backdoor and has been kept around because MS has thought it would be useful to them.
MS has always been a company that has put more value on cleverness than on ethics.
So the questions now are what has MS used this backdoor for, and what has been their plans for future use? Anyone who has used a Windows machine recently should be wondering what information MS has gathered from them and what MS is doing with that information-- the ability to swap a keyboard logger in and out as different graphics or icons are presented while an application is running is a disturbing thought.
I continue to think that there is cause here to consider a Grand Jury investigation. I don't see any other way in which MS employees could demonstrate that their unethical business practices haven't transgressed over the fine line and become criminal behaviors.
[i]I would have assumed that computers in five years time would be using real-time EPS (that's embeddable PostScript, the initials standing for Encapsulated Post Script, for you young'uns, that's what we were all talking about then as being the future of vector formats)[/i]
.rhosts, authorized_keys, .Xsession, etc.) It wasn't even all that long ago that support for those commands was removed from ghostscript and it's decendants (xpdf, etc.). But last I checked, nobody has accused Adobe of trying to backdoor all of our computers.
And lest everyone forget, the PostScript language includes file operation commands (reading and writing). Which of course could be use for all sorts of nastiness by overwriting various important files (.login,
Or a number of standard Unix terminal emulators which have had some pretty iffy functions added to them which can lead to system compromises: TERMINAL EMULATOR SECURITY ISSUES. Has anybody accused Rasterman (or whomever wrote Eterm) of trying to backdoor everybodies computer? Of course not.
What's my point? I don't know. Maybe that, as much fun as it is to kick around Microsoft for dangerous programming choices, they aren't the only ones to design systems and API's that have holes. In hindsight, both the PS and terminal issues I mentioned above are pretty obvious. I mean, slap your forehead obvious that you probably shouldn' do that. But they did.