Slashdot Mirror
Another Gaping Microsoft Security Hole Goes Unpatched
For readers who care, this vulnerability results from Microsoft's integration of IE and the operating system. Files received via HTTP are supposed to be handled by examining the Content-Type header sent by the webserver - for instance, the Content-Type sent with this webpage is "text/html", identifying it as a text (non-binary) document which is marked up with HTML.
Netscape and most other browsers have no problem with this.
You will notice, however, that this method is rather different than how a Microsoft operating system determines how to handle a local file - by its three-letter extension. A file named "foo.txt" is handled as a text file, even if it is a binary image file that has been renamed for some reason.
Now, what happens when you integrate your web browser and your local browsing, say to render moot an anti-trust suit filed against your company? Will local files get a Content-Type? Will remote files be handled by examining their file extension?
IE handles files in an odd mish-mash of looking at the Content-Type sometimes for some purposes, looking at file extension sometimes for some purposes. It's hardly surprising that the bug-hunter in the above story has found a way to feed it a Content-Type at odds with the file extension - the Content-Type may be innocuous, but the extension says "execute me", so when the "integrated" IE engine gets ahold of it, the malicious content is automatically executed.
Now Microsoft has a problem. Because they chose to ignore the standard for handling downloaded files, Microsoft has painted themselves into a corner. If Microsoft suddenly changes how their browser handles downloaded files, tens of thousands (perhaps hundreds of thousands? any webpage which downloads files) of webpages "designed for IE" will have to be rewritten. No doubt this is the issue their programmers are wrestling with right now. It's a fundamental design issue - Microsoft designed their web browser with the goal of doing what was best for Microsoft (evading anti-trust charges) rather than doing what was best for their users. In fact a proper "fix" of this hole probably involves de-integrating their browser and local file handling to some extent.
If you routinely browse with Internet Explorer or read mail with Outlook, keep in mind that any web page you visit or any email you open can take over your computer, steal sensitive files, destroy your machine, anything. This has been true for at least two and half years. And keep in mind that you can't fix the problem, you must rely on Microsoft to do it, if they so choose. And keep in mind that Microsoft is in no hurry to do anything about it, because it doesn't even consider it a vulnerability. Happy browsing!
We'll see plenty of coverage within the next 48 hours, Microsoft statements by the end of tomorrow, and a bugfix by month's end. The big question is going to be, how will people cope in the midst of it all? Will this kind of lagtime offer virus creators to do a whole world of damage? Considering how things have spread recently, I wouldn't be surprised at all if they did. Might be time to start browsing with my iBook more often.
What kind of steps can people use to protect themselves now, is there any kind of toggle or security setting that can be turned on in IExploiter 5.0(tm) to keep us a little bit safer?
My own pointless vanity vintage computing page
Google toolbar? I do a google search in Opera by entering "g my search words" in the URL field. And once you got addicted to the mouse gestures, you wonder how you could ever live without.
Hmm, this article seems a little light on details. To me (very much not a know it all) it sounds like it is an exploit in the MIME type headers for a page - if that's the case is IE really the only one that can be exploited or does it lie more in the way that IE handles MIME type headers?
More detail would be nice. (and no, I don't want to know more abou tit so I can exploit, just so that I can learn from it and other's mistakes)
Please give your mod points to others, Im at the cap. They will appreciate it more
Content-type is an HTTP header. To recieve this info must be transmitted via HTTP. You may have noticed that Netscape (and even Lynx, and yes even on Linux) have no problem displaying local html/ pdf/ whatever files without recieving an HTTP transmission, and thus no Content-type header.
Yep, they do the same thing and look at the file extention to determine how to render files.
I'm not saying there's not a bug, or it's not severe, but examining the file extention to determine type is hardly an IE-only thing.
Trolls throughout history:
Jonathan Swift
Most end up knowing that they will clean up the mess, because "The top guys like Microsoft so much - it has so many features." Nobody is willing to do an honest cost accounting for the top guys.
Until the collective IT folk give an honest accounting of how much MS is really costing them, there will not be a switch away from MS. The moment they do - stampede!
I watched a good bit of this thread on bugtraq (check the archives). Several people on the list attempted to reproduce the exloit as detailed by the original poster and failed. Whether that was their mistake or not is anyone's guess. I didn't try it myself. It only seamed to affect certain builds. I'm certainly not saying IE users aren't vulnerable, I'm just saying get details before making too much noise. MS won't release a fix until they're good and ready, so let's just sit on the flames a bit and try to find out what is going on in reality.
Those saying security through obscurity is bad don't deny that the release of notification about the bug may enable people to exploit it. However, forewarned is forearmed, so you can start doing something about it as soon as you know, up to and including disconnecting vulnerable servers from the 'net.
There's also the publicity aspect. Making this extremely serious bug publicly known puts pressure on the vendor to fix it. So far, they have known about it for over two years and have done nothing. That's two and a half years for anyone who might have stumbled across the bug to exploit it. They might have friends. Exploits, easter eggs and all that stuff spread quite happily before the 'net.
Saying "What I can't see can't hurt me" is naive in the extreme.
Just because you're paranoid doesn't mean they're NOT after you.
Opera 6.0 is now available for download. If you tried an older version of this browser and thought it sucked, try it again. It's light, fast, more standards compliant, and its rendering engine is very compatible with the way I.E. and netscape work so it works practically everywhere. You can browse MDI-style, which means you can have all of your browser windows as sub-windows of the main one, OR you can go NS/IE style and have a separate window for everything. Its skinnable (but you don't have to use a skin), it has more privacy and security features than I can count. You can turn off javascript pop-ups (or merely relegate them to popping up in the background). You can spoof the broswer string as being I.E. or netscape for those sites that are browser bigots. I cannot say enough good things about this software. And its available for BeOS, Linux, Solaris, Mac, OS/2, QNX, Symbian OS and of course Windows. Get it here.
Error: PANTS NOT FOUND. Press <F1> to continue.
As soon as trade secrets are stolen, or hard drives are trashed, or economic harm takes place, however, a negligence action may arise.
The first barrier is the economic loss rule. If the contract damages are higher than the tort (negligence) damages, there is a defense to tort. In English, there's no lawsuit unless the bug costs you more than buying your copy of Windows cost you.
The next barrier is the contractual disclaimer, the "EULA" as Microsoft calls it. The waters here are less well charted. To be realistic, it depends on how severe the harm actually is.
The wild card is intentional harm. If Microsoft in fact intentionally included this bug, knowing of the danger, for the purpose of advancing their business enterprise, legal actions could arise that are not precluded by the EULA. This would be difficult to prove, however.
I think /.'s knee jerk assessment of "death of the Internet, film at 11," is premature, however. I hope I'm not wrong, but I think the bug won't prove that severe. Just browse at "medium security" in IE, for example, right?
If I were a lawyer, I would want to sue Microsoft. They have $30 billion in cash or so sitting in bank accounts. It would be more tempting for them to settle claims than it would be for an Enron, for example.
Don't worry about the legal angle. If the harm is severe enough, justice will be done.
I am not a lawyer. Do not take my words as legal advice. If you need legal advice, consult an attorney.
In other words, "no comment." Sounds to me exactly like "refusing to provide any information." So what was incorrect about Michael's writeup?
I found that out when I was trying to make a "view source" link to a .jsp file that was a soft-link to the jsp with the suffix of html. Apache sent "text/plain", as appropriate. Netscape and Mozilla viewed it just fine, just as I wanted them to.
I.E. noticed that it looked awfully like HTML and rendered it as HTML, effectively hiding all the embedded java and jsp tags that I wanted to show.
bastards...
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
Although I never liked Opera's interface, Mozilla has recently become my Goto browser. The first few versions (especially the Netscape branded ones) weren't so stable or capable. But the last last 3-4 milestones have been topnotch. specially .95 with the tabbed interface. Best of all I can use it in Linux.
It does have it shortcomings. Opera much less of a resource pig, and Konquerer is better thought out. But I rarely encounter any problems rendering pages(I did in past releases) The bonus of being open source, skinable and multi-platform clinches it.
In a final note. I think it is obvious that Microsoft's complete disrespect for thier constumers' security and privacy needs necessitates an emigration from their products. I currently run Windows boxen for Macromedia and Adobe apps. For servers I run BSD or Linux, however I was my local Comp Usa playing on a dual -G4 OS-X box. Incredible interface, even ran Windows 2000 via virtual PC. I was impressed enough with OS-X that I almost bought it, $2500 worth. The lesson, Apple is close, Microsoft has slipped. It wouldn't take very much for Apple to gain those of us constantly jumping between Windows and Unix. Maybe a G5 that achieves a better Price/Performance ratio. How about a bare bones Mac, for those who like to build a custom box.
Just a few thoughts I am not a Mac Zealot, but to able to dump Windows and Explorer would make me feel safer.
NIMBA got IE users to autoexecute it by munging the content-type header to say audio/x-wav and then sending a .exe file. IE would happily start 'playing' the file for you.
OOPS.
Microsoft actually has a KB article about this, and it is intentional. Apparently, they don't believe a web developer is competent enough to handle mime types, IE has always tried to glean information from the file, be it by the extension or otherwise, to determine what it should think the file type is. At work especially I have been bitten by this "feature" many times.
.txt for finding easily in the import box, but if you send IE a content type of text/plain it will display it. No big deal, just save right? Well, IE also believes since it got < and > tags that it MUST be HTML, despite the fact that I'm saying it's plain text, so it's going to add the proper html header and footer along with content encoding tags. Pagemaker doesn't like that. And to be even more irritating, is that we'd like to be able to just have the save box pop up. Well, normal browsers that handle things standardly will accept the content type, and if they don't understand the content type they will usually pop up a "save as" box. OK, so now we pass back content type of application/x-hdi-export, surely no browser knows of this, and Netscape/Moz/Opera handle this correctly. But we also pass a default filename, in the Content-disposition part, with a name ending in .txt. So what's IE do? Display it in the window, still thinking it's HTML, all because of the extension.
.txt_ so that IE will not try and read it, along with passing it a bad content type, otherwise if it's application/octet-stream or some such, it will STILL RENDER IT IN THE DAMN WINDOW because for "common" types such as text/plain or application/octet stream, it examines the content of the file.
The most irritating aspect of it is that you simply can't get around it. For example, we have a web-based flyer/catalog generation program at the office. The advertising department enters records such as item code, part number, color, size, etc, some text, and attaches items to the record. Hardware distribution (like shovels/rakes/nails/etc) has extremely low margins, so purchasing something like Quark Express or another database driven tool is out of the question. Well, we found Adobe Pagemaker to be sufficient, and lo and behold it supports importing tagged text. So from our database, they select items and it can export SGML-ish text to be imported into Pagemaker.
Now here comes the rub. Pagemaker wants the files to be
So what it comes down to, is I also have to mangle the output name be making it
And for those of you who thing "why not right click -> save as", well the generation needs several arguments, such as sorting, template name, etc, so it's a form, and you can't click the button and tell a form you want to save the download.
This isn't the only time I've had a problem, I don't want to even get in to how IE badly handle dynamically generated PDF's, how since 5.5 it ignores the settings to not embed PDF since that's the only work-around, and how 5.5 also asks the "open here/save" question TWICE when passing it some file types.
Overall, they may tout it as a feature, but if they'd just follow the damn standard like everyone else I wouldn't have to waste so much time finding workarounds for their "features"
Free Online Woodworking Resources Directory
I know from my web development experiences that this has long been a problem. In fact, recently me and a friend were contracted to make some modifications to a site built in perl. The client was an all-MS shop and did not notice that sometimes the contents of the CGI's got dumped out the screen raw. It turned out that since they all used IE, it automatically assumed the output to be HTML and rendered it, but when we used Mozilla, since no propoer MIME header was sent, the browser just rendered it as text. Kind of scary that this can go on without anyone doing something about it.
--Jon
Ironically, I ran into this one just the other day, but didn't recognize it for what it was.
I develop software for a living, and one of my tools is a web-based thingy with a CGI interface. A typical URL might look like this:
http://foo/bar.cgi?blah=blah&filename=quux.jpg
This CGI script returns a web page with info about the file "quux.jpg," which exists on the server.
When I serve this URL up to IE 6 under Windows 2000 (maybe other versions; that was the only Windows IE I tried) the browser thinks it's downloading a JPEG image, and asks me where I want to save it.
My script sends a nicely formatted Content-type header of text/html, but the browser is stubborn and won't listen.
So in my case, this wasn't really indicative of a security hole, but rather a pretty dumb design flaw in the browser that should have been caught in testing.
(Oh, and FYI, my "fix" was to reorder the CGI parameters as the URL gets constructed, so the filename never comes last. I'm not happy with this, and I may implement URL-encoding the filename's "." character instead, then decoding it on the server side. But the spec says I shouldn't have to do that, so the whole situation has left me kind of pissy.)
There's a fairly easy exploit (for IE since 4 I think) that allows a malicious web page to read arbitrary files off a users hard disk.
No patch available as far as I know. It's also a lot easier to exploit than this one (heck, I even was able to do it).
I'll put details up if anyone's interested...
Let's not stir that bag of worms...
Funnily enough I got one that did this just this morning.... but my procmail filter cleaned it up nicely. Note the original content type below.
> SECURITY WARNING!
>
> The mail system has detected that the following
> attachment may contain hazardous program code, is
> a suspicious file type, or has a suspicious file name.
> Do not trust it. Contact your system administrator immediately.
>
> X-Content-Security: [www.ccimackay.com] original Content-Type was audio/x-wav;
> Content-Type: application/octet-stream; name="HUMOR.MP3.27525DEFANGED-scr"
> Content-Transfer-Encoding: base64
> Content-ID:
>
Another case of security vs convenience I suppose.
You are in a twisty maze of processor lines, all alike.
There is a lot of hype here.
You want to see it for yourself? The problem is that IE get's a file that ends in say, .ZIP, asks the user to download or open from current location, and if it's "open from current location" it actually executes the code as an executable, even if it _IS_ a .ZIP. There's nothing special here, and it doesn't need you to have web administrator access, I did it here: http://www.cs.nmsu.edu/~dfoesch/funny.zip If you want to see the exploit first hand, select "open file from current location" and then if it asks you what application to use, just click "ok" (ok, you might have to select the first entry) and PRESTO! Notepad.EXE! Running remotely on your computer! This could easily be any arbitrary program, I just chose Notepad.
I am unamerican, and proud of it!
This happened to me! Twice. However, for me it was Mozilla on Linux. I got some strange email with a subject line that was simply "Re: ". I clicked on the message, and the preview window starts to "render" the message by informing me it's about to execute an exe (OK/Cancel?). Now, I wasn't too worried about trying to run Windows executables on Linux. I just hit cancel and went on with my life.
BUT...what the heck is going on here???? Is this a worm trying to exploit this MS problem? Or is it even an MS-only problem? I'm guessing that Mozilla on Windows would have executed whatever it was in the message as happily as Outlook would have!
"So what it comes down to, is I also have to mangle the output name be making it .txt_ so that IE will not try and read it, along with passing it a bad content type, otherwise if it's application/octet-stream or some such, it will STILL RENDER IT IN THE DAMN WINDOW..."
:P
;)
I had this same problem. Basically, you must make sure to pass the filename as part of the content header, but not attached to the end of the script name. This way, IE will always pop up a window asking you to save. It will tell you that it is saving your script name, but in reality, it will save the page you want it to.
First, write the page from your database to your local server as a file. Then do the following (my script is written in PHP; translate as needed.)
I wrote my database contents to a variable called $content, then executed the following code:
# put content into file called download/$page_num.html
$fp = fopen ("download/${page_num}.html", "w");
fwrite($fp, $content);
fclose($fp);
if ($action == "download") {
# set up file download to client
header("Content-Type: text/unknown\n");
header("Content-Disposition: attachment; filename=\"${page_num}.html\"");
header("Content-Transfer-Encoding: ascii");
$fn=fopen("download/${page_num}.html", "r");
fpassthru($fn);
unlink("download/${page_num}.html");
exit;
};
Note the key difference between my script and yours is the fact that I'm not passing anything but a content header to IE. Don't use your_script.php?filename=xxx... that doesn't work. Just write the filename as a variable and put that variable in the content disposition header. Also note that the Content Type can't be text/html, or, really, anything that IE will recognize.
This works in both Netscape and IE. Note that if you're working cross-platform using text files, you'll have to convert line breaks. I use the following code:
# get os for carriage returns
if(strstr(getenv('HTTP_USER_AGENT'), 'Win')) {
$content = eregi_replace("\r","",$content);
};
Again, that's PHP -- translate if necessary.
Here's the final trick I'll pull out of my bag: if you set a Content Type to application/vnd-msexcel or somesuch (I could be off on that), and send the client a tab-delimited text file, it will open in Excel. Same goes for plain text and Word. It's a great trick to pull when you know your client is going to be using Windows and will say, "Hey, how did you get your script to make an Excel file? That's so cool!" (Always nice to have a little extra trick to impress your clients...
Hope this helps --
Erica
If this bug in IE has really been around for two and a half years, how is it that no one has stumbled on to it until now? Could it be that (GASP!) security through obscurity actually worked in this case?
The nimda virus used a variation of this "Content-type/TLE" switcheroo.
FreeBSD for the impatient.
upon first reading michael's post, i thought this wouldn't work, because ie has that annoying behavior of examining the first bytes of file to determine its mime type, sort of like apache's mime-magic module. and then ie in 5.5sp1 had to go and break the content-dispostion header, but i digress.
.bat
.txt
.txt
.bat
.exe renamed to b.txt
.bat file as text in the browser.
.txt, ie prompts to open or save, defaulting to save. selecting open opens the binary file in notepad.
anyway, i tried to recreate this bug, with no luck. maybe someone can explain what i'm doing wrong, assuming this is a valid hole in i.e.:
server: apache 2.0.28 beta for win32
client: ie 5.5 sp2 (not sure if it's stock sp2 or has a hotfix on top of sp2. there's some Qxxxxxx following in the "about" box)
in httpd.conf, created the following:
<Directory "c:/foo/bar">
#AddType audio/x-wav
#AddType audio/x-wav
AddType application/octet-stream
AddType application/octet-stream
</Directory>
created two files:
a.bat:
@echo off
format a:
b.txt:
this is a just an
ie renders the
in the case of the
changing the mime-type to audio-x-wav just renders the files as text in the browser (no prompting in the case of the txt/exe).
so what's the big deal?
For all the fanboys that scream out that Opera is better than IE (and it is, I love it too) - in this case it is vulnerable too, as this link proves. The file save dialogue will show the text.txt filename, but if you select to open it directly, it will run.
Opera 6.0 is not vulnerable - but take note - even though it is much better and has less exploits than IE, it's still not completely free of them. (On the other hand, the only secure applications are those on an unpowered computer, or a program of 'Hello World' complexity)
I've stated something like this before, but... If a program is causing problems like that with your operating system, then you should either:
- fix your OS
- get a new OS
- or complain to your OS distributor
since, if the operating system is crashing, there is clearly a problem with the operating system. Programs run INSIDE (or ON TOP OF) the operating system, and when they misbehave you should be able to use the OS's tools for closing them down. In a well-designed system, applications do not have enough control over the operating system to do damage to it, and even when they do have enough control, it is up to the OS to respond appropriately, instead of crashing. If a KOffice application crashed when you tried to insert an Mpeg video sample into a word processor document (if it can do this) would you blame the person who wrote the MPEG decoder? No. The application that it is running inside is to blame (in this case it would be KOffice, in your case it would be your operating system).Please not that I have nothing against KOffice - I merely picked a random name to illustrate my point.
Follow me
I had a similar problem once, when I had to make a CGI that would send back a spreadsheet to be passed off to the right application from either Netscape or IE. The eventual solution was to change the content-type slightly for each browser, and for IE to append a fake parameter with the right extension so IE would open it correctly.
It was a workaround for IE, really, Netscape handled it fine with the correct content-type. IE didn't handle it correctly unless you munged the content-type AND added that fake extension...
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
I have been unable to get this to work as described in the article, or by the other attempts posted so far. The closest I have come is to create a Redirect or Rewrite rule that takes a request for a *.txt file and points it to a .bat file (thereby fullfilling the "text" requirement"), which is then soft linked to your malicious executable. This still displays the file's name however. And the dialogue asks you to "run" this program. The extra step of the soft-link bypasses a warning about running the file; if the redirect went straight to the .exe, the browser will complain about security.
.exe file to .txt, that just spits binary data at you in Notepad.
/.ers would have hit on it by now.
Either way, this is entirely server-side. The article states that simple HTML can pull it off. I am wondering if that is just a smoke screen.
- I have tried renaming an
- I tried a cgi (source is here).
Now, this time the dialogue displays the requested file (.cgi) instead of the executable filename (not a redirect). However, you are then prompted to "choose a program to run this..." which means that the requested file has to have an executable extension, or a known extension. Wav, mp3, mpg won't work as the format is obviously invalid.
3) I tried messing with the mime.types in Apache, various soft links and combos of all 3 methods. Basically I fail to see how standard HTML without any server-side config or scripting can fool the browser or get it to exec code unwillingly, as described in the article.
Maybe if I renamed the file to mayIhaveyouradvice.txt.pif or something, but the extension IS displayed to the user. Maybe the average user doesnt pay attention, but its kind of hard to miss.
Obviously they have ommitted something crucial because (my box - W2K, IE 5.5 SP2) this "bug" is not happening, and it's not happening for other people too. If this is so easy to implement in palin HTML and would affect "millions" then I think other
File extensions seem to me to be a safer way to manage filetypes - on any Mac OS prior to X all you had to do to fool a user into running a spoofed program was to change the filename extension and icon (say, make an application with a .jpg extension and a quicktime image file icon). The os runs the file based on the actual file type and creator codes when it is double-clicked, and those codes are typically invisible to the user, so someone could very easily open a malicious program instead of, say, some downloaded pr0n.
.jpg will always be opened as a .jpg, even if its just a renamed .exe
At least with file extensions as the absolute identification of file type you can't be tricked (ignoring the method discussed in this article), and a
I was developing a web application that would serve out a chunk of opaque data for the user to save on their hard drive. So I set the Content-Type to "application/octet-stream" and the "filename" in the URL was foo.yai which is a totally bogus extension, right? Well it just so happened that the actual content of the data was XML. But not only that, it was XML saved as a UTF String so that it had this two-byte header on it which indicated how long the UTF String was.
.com is an executable as far as Windows is concerned. Brilliant.
Clicking on the link that generated this file worked fine on all browsers but IE, of course. You would click on it and all other browsers would properly show the user the "Save As..." dialog. IE looked at the file and determined that it was XML (even without and xml extension!) and not only that, it was so bold as to tell me that my XML was mis-formatted because of this 2-byte header at the beginning of the file! So it started its embedded syntax-highlighted XML viewer that it has and then stops and says "Misformated XML, unknown characters before the <xml> tag...". Gimme a break!
The "workaround" was to set the Content-type to X-Made-Up-Content-Type-To-Fool-Stupid-IE and it decided that this was something that should receive the "Save as..." dialog, as did the other browsers, thankfully.
So I'm not at all surprised that someone found this vulnerability with IE being so bold as to guess the content-type when it is set to application/octet-stream and start doing whatever it wants to based on its guess.
And have you ever noticed that IE get's the extension from the last thing in the URL _even_ if it's a query string? So if you have a URL like http://www.foo.bar/download?e=greg@yahoo.com
then the filename it will try to save is "download.com". And of course
Read the original post closely:
.exe files are text/plain ... in which case you get the prompt, and then Windows opens the executible in Notepad.
.txt files are application/octet-stream ... in which case they are still displayed as text in your browser.
IE handles files in an odd mish-mash of looking at the Content-Type sometimes for some purposes, looking at file extension sometimes for some purposes. It's hardly surprising that the bug-hunter in the above story has found a way to feed it a Content-Type at odds with the file extension - the Content-Type may be innocuous, but the extension says "execute me", so when the "integrated" IE engine gets ahold of it, the malicious content is automatically executed.
Where is the exploit in this? Any user with half a brain (not many, I know) will see that this supposed text file ends with ".exe" or something. That's a trigger right there.
AFAICT, IE relies soley on the file extension when deciding whether or not to execute a file.
You can try and tell it that
You can try and tell it that
The only way I can think of making this work would be to change the MIME types on the client machine (i.e. Explorer > Tools > Folder Options > File Types). And I'm pretty damn sure that's not possible via plain-Jane HTML.
Tuus crepidae innexilis sunt.
Secondly, the text/html content-type is not executed, it is rendered in the browser. You would need to set the content-type to something automatically run by an external viewer, like video/mpeg.
Then the browser will say, "Ok, this is a video file, better ShellExecute() it", then the Shell API will look at the extension, .EXE, and run the file as a standalone executable.
Anyways, I haven't tried it yet for myself, but that's the impression I'm under as to how it would work. It might be trickier than this, or only work with specific set ups and content-types.