A Photo That Can Steal Your Online Credentials?

TedSamsonIW writes "InfoWorld reports on a new potential ploy for stealing Web user's private information: Researcher has found that by placing a new type of hybrid file on Web sites that let users upload their own images, they can circumvent security systems and take over Web surfers' accounts. 'They call this type of file a GIFAR, a contraction of GIF (graphics interchange format) and JAR (Java Archive), the two file-types that are mixed. At Black Hat, researchers will show attendees how to create the GIFAR while omitting a few key details to prevent it from being used immediately in any widespread attack.'"

Comments

I can haz ur eebay de-tails?

[Channard]

Just imagine - something as innocent as lolcats could be a potential minefield. God only knows what goatse would do.

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

4chan is fucked, /b/ is going to spend all day trying to hack eachother.

Re:I can haz ur eebay de-tails?

[ya really]

Just imagine - something as innocent as lolcats could be a potential minefield. God only knows what goatse would do

There's no actual pictures involed though, just a java applet masquerading as a gif file to the browser (so no kitties harmed). Now, they could give a user a link saying, "Here bez sum picz of lolcatz, come lookz," which would then cause them to "download" what they think is a gif (though it will never show an image). I'm not sure about others, but I tell my browsers to ignore java. Anything written as a java applet is not worth viewing anyways, aside from security risks.

Re:I can haz ur eebay de-tails?

[X0563511]

Wait, aren't they doing that already? Well, between faps anyways...

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

What's this "between faps" time you speak of?
No, this will allow them to add hacking eachother to their fapping, doubling their troll productivity.

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

you said goatse.

Re:I can haz ur eebay de-tails?

[odiroot]

You broke rules 1 & 2.

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

Fuck you, fuck your rules, fuck /b/, fuck 4chan, and fuck all the losers that are too pathetic to see how goddamn useless that place is.

Re:I can haz ur eebay de-tails?

[The Ultimate Fartkno]

God only knows what goatse would do.

Talk about a gaping security hole...

Re:I can haz ur eebay de-tails?

[Grimbleton]

Oh if only it were as useful as posting anonymous flames on Slashdot...

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

well to access the machine (do harm) your applet must be signed, and normally the browser will warn you about the certificate (you can disable this)

I do not see too many chances of this to happen with a savvy user, but how many they are?

oh well

Re:I can haz ur eebay de-tails?

[gd2shoe]

Who says it wont display an image? An applet can render an image and do nothing else. Most users wouldn't know that it was an applet. If the users can anticipate there being an image in that location (often, not always) then it makes sense to keep the subterfuge going.

Re:I can haz ur eebay de-tails?

[odiroot]

1) You are *Anonymous* **Coward** 2) I see you have issues with yourself 3) gb2sandbox

Re:I can haz ur eebay de-tails?

[Nadaka]

There is no reason that I can see that this java applet could not fool the user by displaying a real image in the space that the gif was supposed to have been loaded. If well done, a casual user would never know something funny happened.

Re:I can haz ur eebay de-tails?

[gd2shoe]

They're not talking about access to the machine, but to stealing other peoples facebook accounts, etc. You're right that this can be used as an attack vector on the stupid, though. Bright people can still get their myspace page hacked without much trouble (if any bright people had a myspace account; I'll assume there are a rare few).

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

If it will just run java so couldn't you instruct the java to load an image to display anyway?

Re:I can haz ur eebay de-tails?

[MozeeToby]

I think you've misunderstood what the hack is doing here. It isn't someone posting a picture which, when downloaded, infects your computer. This is you uploading a picture which infects the server the next time it is viewed. Basically, it looks like a gif when you upload it, but when the server goes to display the image next time it sees java code instead and runs it; theoretically allowing you to craft a java applet that can pull information off of their servers.

I say theoretically because there's still a quite a few barriers to get this to work, or at least there should be if they've set up their server environment at all correctly.

Re:I can haz ur eebay de-tails?

[hostyle]

1. bE sTUPID
2. dO iT oNLINE

Re:I can haz ur eebay de-tails?

[giantweevil]

4chan already blocks archives embedded within image files. Including Jars. Your point is mootle.

Re:I can haz ur eebay de-tails?

[Dogtanian]

Just imagine - something as innocent as lolcats could be a potential minefield. God only knows what goatse would do.

I don't know about online credentials, but Goatse and Tubgirl have been stealing something for years- peoples' minds.

Re:I can haz ur eebay de-tails?

[clone53421]

There's no actual pictures involed though, just a java applet masquerading as a gif file to the server (so no kitties harmed).

You're slightly mistaken. The server thinks it's a GIF; the browser figures out that it's actually an applet and starts Java. Since it's coming from the same server, the applet is able to interact with the rest of the page and see the site's cookies, and it can then transmit whatever stuff it discovers to a third party. As you said, not having the Java plugin would thwart the attack.

Also, I hate to get on my soapbox, but file extensions are a good thing. In this case, the extension is the only thing that the user has to tell them what sort of content is being delivered... when the file type doesn't match the extension (or MIME type), the browser should complain. This "magic" stuff where the extension is ignored is dangerous.

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

The first thing I, and everyone I know, does when installing a browser is disable Java.

Client side Java is dead.

Re:I can haz ur eebay de-tails?

[sexconker]

Big fat java loading icon might tip some people off.

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

"There's no actual pictures invol[v]ed though..."

Why not?

If your description is valid, then there's nothing preventing the payload java applet from containing the code and data necessary to first display the seemingly-relevant picture, and then proceed to take over the host machine. It might be significantly slower than just delivering the image and displaying it with the browser, but with network bandwidth limitations, people might not notice or particularly care (especially if it was a picture they really wanted for some reason, like the cute kittens).

Re:I can haz ur eebay de-tails?

[makomk]

Funnily enough, 4channers have been using something like this - a combination of an image file and a ZIP file - to hide small files in images on /b/ for ages. Since JAR files a type of ZIP file, I'd hope that the site already blocks this. (People were abusing it to distribute stuff like child pornography and hacking tools on /b/ hidden in innocuous-looking images.)

Re:I can haz ur eebay de-tails?

[Tony Hoyle]

The opposite is true - for this to work the extension must be wrong and the server must not use any fingerprinting the validate the file (just looking for GIF89a at the start is normally enough).

Ignoring the extension is precisely what should be done.. the server is accepting a .jar just by renaming it as a .gif therefore the server is broken.

Re:I can haz ur eebay de-tails?

[mopower70]

Also, I hate to get on my soapbox, but file extensions are a good thing. In this case, the extension is the only thing that the user has to tell them what sort of content is being delivered... when the file type doesn't match the extension (or MIME type), the browser should complain. This "magic" stuff where the extension is ignored is dangerous.

Then please don't because you have no idea what you're talking about. File extensions are arbitrary, irrelevant, meaningless naming conventions based on absolutely nothing, while "magic" is determined by examining the actual contents of the file.

If you understood what you were talking about and you wanted to label anything "dangerous", you'd be saying that relying on file extensions to convey any serious information about the content of the data is stupid and potentially dangerous. I can name a file anything I want. It at least takes a little bit of work to fiddle with the magic signature without corrupting the file's contents.

Re:I can haz ur eebay de-tails?

[clone53421]

No, for it to work, the browser needs to ignore the .gif extension - and the MIME-type sent by the server that says "this is an image/GIF" - and say "hey, this looks like an applet, better fire up Java!"

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

Glad someone's paying attention.

Re:I can haz ur eebay de-tails?

[clone53421]

I knew somebody would flame me for my opinion, but look at the facts.

File extensions are, currently, the sole determining factor that Windows machines use to determine what a file is.

I can name a file anything I want.

Yes, but extensions aren't interchangeable. Your malicious .exe won't run if you rename it .pdf. It's a safety feature, and it's very useful. "Hide file extensions" is dangerous for this very reason: "readme.pdf.exe" looks like "readme.pdf" and that's just WRONG. If they'd get rid of that stupid "feature", then "readme.pdf" would be obviously safe, whereas one can't conclude that if the extensions are hidden. The user can't trust the icon: a malicious executable could disguise itself by having an icon that looks like a PDF.

Now, if the operating system says "hmm, this has a .pdf extension but it's actually an executable, I'll just go ahead and run it", that's blatantly dangerous.

Furthermore, on the internet, the extension is the only way a user can tell what a file is. Since TFA states that the server thinks the so-called GIFAR is a .gif, it'll send a content-type: image/GIF header. It's dangerous and stupid for the browser to ignore (1) the .gif extension AND (2) the image/GIF content-type and launch Java.

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

So a very basic stenography?

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

So we are raiding /. now?
Lurk Moar!

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

Not even that. They were just concatenating archives onto the end of images. Image readers would process the image only, and decompression programs would ignore the "noise" at the beginning and work solely with the archive after the image

Re:I can haz ur eebay de-tails?

[Rinikusu]

There's a few games that I quite enjoy that are java applets.
NES Golf
Stuff over at Puppy Games using LWJGL
etc.

So, don't knock it.

Re:I can haz ur eebay de-tails?

[rfuilrez]

Probably if you read the article you would understand how this works. But, this is slashdot so I'll explain it for you with quotes from TFA

To the Web server, the file looks exactly like a .gif file, however a browser's Java virtual machine will open it up as a Java Archive file and then run it as an applet.

So in short, The web server sees the file as an image, and serves it as such. The browser sees it as a Java applet, and RUNS it as such.

There is one catch, however. The victim would have to be logged into the Web site that is hosting the image for the attack to work.

The user needs to be logged in for it to work. We all clear on this now?

Some one mod this guy NOT informative because it's completely wrong.

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

If most of them can't figure out to hide a RAR in a GIF, much less a JAR.

"...And nothing of value was lost."

Re:I can haz ur eebay de-tails?

[Rob Kaper]

I knew somebody would flame me for my opinion, but look at the facts.

File extensions are, currently, the sole determining factor that Windows machines use to determine what a file is.

That's a shortcoming of Windows, it's not a shortcoming of other systems such as the magic database.

Yes, but extensions aren't interchangeable. Your malicious .exe won't run if you rename it .pdf. It's a safety feature, and it's very useful.

Then why does malicious Java archive run when you rename it .gif? I thought they weren't interchangable?

Furthermore, on the internet, the extension is the only way a user can tell what a file is.

You can't trust something as arbitrary as a filename, extension or content-type given by a remote server. You have to check the file itself. Now I won't expect an end user to do this manually, which is why the magic database is so useful.

Since TFA states that the server thinks the so-called GIFAR is a .gif, it'll send a content-type: image/GIF header. It's dangerous and stupid for the browser to ignore (1) the .gif extension AND (2) the image/GIF content-type and launch Java.

It's fine for the browser to ignore them because the server cannot be trusted to supply the correct information. It's dangerous and stupid for the browser to run Java code without warning, especially if it allows it to be done from inside the img tag because it can know the data is not a valid image by simply checking it first.

I do think it's a flaw of the server to not verify this itself when storing the so-called image, but it's a bigger flaw of the client to trust every server will do this and no single server will abuse it.

Re:I can haz ur eebay de-tails?

[ins0m]

So, you realize the error in your logic then?

1. Server does magic check. Sees image/gif.
2. Server sends file as image/gif.
3. Browser deliberately misfires helper routine, get r00ted.

There's a reason why magic strings are used: they're part of the encoding process. Let's look at it from two angles:

1. Browser gets set JAR, reads it as GIF. What happens? Broken image, possible buffer overflow. In the former case: that's what is supposed to happen. In the latter case? Problem in GIF decoding algorithm, _not_ the browser's fault.

2. Browser gets the JAR, goes by file extension, gets access to DOM and cookies. Uh... wait, what? Yes, my friend, that is the sound of raep.

Are you honestly attempting to state that #2 is better than #1?

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

You broke rules 1 & 2.

Only during raids. Newfag.

Re:I can haz ur eebay de-tails?

[TheLink]

Huh. Magic databases are a contributor to the problem not the solution.

The problem is browsers are NOT respecting the mime type AND are using a "magic database" to decide whether something can be executed. It's not that relevant whether magic database is from the O/S or from the browser. The main issue is the browsers are NOT respecting the mime type.

With magic databases stuff that contains executable stuff can get executed no matter what it is called.

The way to protect against the "magic database" is to set permissions on the file to "not execute" (and even so might still work).

But currently the browser does not know what permissions are on a file that's downloaded (all it knows is it can read it). You are supposed to set the mime type, but seems the browsers aren't respecting that.

I have actually proposed something that could help against stuff like this AND other attacks, to both the browser people and the W3 bunch but they were NOT interested.

Example:
http://osdir.com/ml/mozilla.security/2002-10/msg00029.html

If they had implemented my suggestion years ago, the myspace worms and other similar worms would likely not have worked on browsers that supported the security feature - it would be trivial for the websites to restrict 3rd party stuff to allowed behaviours.

Re:I can haz ur eebay de-tails?

[zapakh]

File extensions are, currently, the sole determining factor that Windows machines use to determine what a file is.

That's not an argument in favor of using file extensions as metadata; it's an argument against Windows.

Re:I can haz ur eebay de-tails?

[clone53421]

Parent is precisely right.

Then why does malicious Java archive run when you rename it .gif? I thought they weren't interchangable?

Because the browser is trying to be "clever" or "helpful" and ignoring both the mime type and extension. Instead it's using a magic database, which is dangerous. THE OS DOESN'T HAVE THIS FLAW: extensions AREN'T (typically) interchangeable in Windows. (I specifically cited one instance where Microsoft decided to cleverly make .asf and .mp3 extensions interchangeable, and it bit them. In another case, I described how image extensions are interchangeable, but I pointed out that since the security of the formats are the same, it's not as big a security issue. It's still not smart, IMO.)

Re:I can haz ur eebay de-tails?

[clone53421]

Uh huh... when I said "look at the facts" I didn't mean "read until the quote and then stop". That's what you did, right?

It's merely an initial description of the situation. I further went on to describe why it's a good situation, and why ignoring the extensions is dangerous. It's silly to say that's a claim against Windows: determining filetype by extension works IF the extensions are strictly followed. Maybe you should go back and read the rest of what I posted.

Re:I can haz ur eebay de-tails?

[clone53421]

I wasn't saying it SHOULD do that, I was describing how the browser must react for this exploit to work. Yeah, it's dumb, and it's an obvious security flaw.

In order for this exploit to work, the browser has to ignore the mime type and the extension. The extension says it's a .gif; the mime type says it's image/GIF. If the browser ignores them and runs the applet, it's a huge security flaw: BAD DESIGN!

Also, I'm not sure what you're referring to here:

1. Server does magic check. Sees image/gif.

2. Server sends file as image/gif.

3. Browser deliberately misfires helper routine, get r00ted.

The server obviously doesn't do a magic check or it would see that it's an applet. The server just looks at the extension. Server sees .gif, sends image/GIF, browser either (1) says "well I'll give this data to the gif decoder" and you get a broken image or (2) says "hmm, the extension is .gif and mime type is image/GIF, but magic(data) == applet, so I'll send this to Java instead". What's this about the helper routine?

1. Browser gets set JAR, reads it as GIF. What happens? Broken image

Yeah, that's how it should be... a .jar, renamed .gif, should be interpreted by the browser as a .gif, no more. There is absolutely no way the browser should look at "renamed-jar-file.gif" and say "whoops, that's a .jar, I'll just go ahead and run Java".

2. Browser gets the JAR, goes by file extension, gets access to DOM and cookies. Uh... wait, what? Yes, my friend, that is the sound of raep.

Um? Of course JAR applets could sniff their own DOM/cookies... that's obvious. The point here is that USERS can upload .gif files that are really applets. However, no system is going to let users upload arbitrary .jar files; that'd obviously be stupid for the very reason you stated. If they try to upload a .jar, then the server's going to look at the extension and say "nope, can't have that". The extension has to be .gif, .jpeg, .png, etc: if the browser goes by the extension, you get situation #1, not #2. If the browser ignores the extension and does its magic, that's how you get "raepd".

Re:I can haz ur eebay de-tails?

[ChameleonDave]

I don't see what shorthand has to do with it. Try steganography.

Re:I can haz ur eebay de-tails?

[CaptnMArk]

>File extensions are, currently, the sole determining factor that Windows machines use to determine what a file is.

Not just Windows, also the user.

That's why hiding the extension (stupid Windows Explorer) and sniffing the content using magic (stupid IE) is a bad idea.

While the content is in the browser, the browser is supposed to insure that any content stays within a sandbox, but the downloaded/saved content should be properly tagged with a file extension (properly matched to a mime type).

Re:I can haz ur eebay de-tails?

[Lanzaa]

You might be mistaken. There have been talks for a while about combining these two types of files, a jar archive and a gif image. The jar format is based on the zip format. Zips have their header information in the end of the file. Gifs have their header information in the beginning of the file. One trick people have used to upload data files and secret messages to the internet is to simply append the zip file to the end of a gif file and upload it to an image host. When you download the image file from the image host, you get both the gif and the zip files. With a gif extension, the file will usually act like a gif and open up in image programs. With an archive program, you can open the zip file part. So, i believe the attack uses some of the trickery you describe, but also uses this type of trick to fool most detection programs. At least all of the detection programs that look for a valid image header.

Re:I can haz ur eebay de-tails?

[negRo_slim]

I think you could still keep fapping and manage to do this.

Re:I can haz ur eebay de-tails?

[Nazlfrag]

There's surely more to it than that, I'd wager they found a way to pass GIF fingerprinting tests and still have a valid JAR file. They could have gone so far as to have the GIF renderable. Until further details arise, who knows, but one things for sure, the hack isn't just a trivial renaming of a file.

Re:I can haz ur eebay de-tails?

[Yvanhoe]

How do you tell a browser that your PHP script generated a text file, an HTML, a SVG or a PNG then ?

Re:I can haz ur eebay de-tails?

[jrumney]

Pure zip files do have a small header at the start of the file, but most tools that deal with zip files ignore it so they can work with self-compressed exes as well. Since java doesn't really need to handle self compressed exes, it could reject jar files that don't start with the PK\003\004 byte sequence.

But this only closes the attack for sites that check the types of files uploaded carefully. Most image uploading sites make thumbnails and other sized images, so would probably detect a non-image as part of that processing, but there are also a lot of sites that just check the extension of files users upload, so a simple renaming of a jar file to .gif will expose users to the same attack there.

Re:I can haz ur eebay de-tails?

[odiroot]

Raids are over.

Re:I can haz ur eebay de-tails?

[Ed Avis]

You're slightly mistaken. The server thinks it's a GIF; the browser figures out that it's actually an applet and starts Java.

This is the same kind of idiotically 'helpful' behaviour that led to lots of exploits with WAV files about a decade ago. Oh I got a WAV file in an email, let's play it because it's just a sound file and that must be safe right? Then the media player saw that despite the filename it was actually an executable, and helpfully decided to run it instead...

Moral: use the Content-type from the server and do not do any kind of guessing based on filename, content or anything else. (With the possible exception of showing an unknown type as plain text.)

File extensions are fine for local filesystems, but they are not the way the web was designed to work. Web pages have a Content-type header.

Re:I can haz ur eebay de-tails?

[clone53421]

Interesting. That still doesn't explain how (apart from bad design) the browser ends up thinking it's a jar, though... if the server is fooled, the browser should at least be consistent and assume it's really a gif.

Re:I can haz ur eebay de-tails?

[clone53421]

Um, do you actually use PHP? (Granted, you might never need to do it, so it's possible that someone could use PHP and not know this.)

Anyway, it's really easy... use header("image/PNG"); before any data is sent to the browser.

I happen to know this because I run mySql/Apache/PHP5 on my home PC...

Re:I can haz ur eebay de-tails?

[clone53421]

Afterthought: you can also trick the browser into thinking the image has a filename. Just call the image http://www.mysite.com/script.php/image.png... script.php will run, but if someone tries to save-as the browser will use image.png as the filename.

Alternately, you could use a custom 404 script that (for example) takes a non-existent http://www.mysite.com/images/image.png and instead serves http://www.mysite.com/_private/images/image.png (obviously, you'd need to generate a 404 error page sometimes, so you'd have to check the requested URL and take the appropriate action).

Re:I can haz ur eebay de-tails?

[clone53421]

You're correct, but I want to clarify one minor detail.

File extensions are fine for local filesystems, but they are not the way the web was designed to work. Web pages have a Content-type header.

Although the HTTP protocol does have the content-type header, it's generally just based on the extension of the file. A .gif will have an image/GIF type, a .html will have text/HTML, and so on. Apache can be configured to use magic to send the appropriate content-type but the default is to use the extension. There's really not any practical difference between using the extension and using the content-type unless the content was generated by a script (like PHP)... in that case, the script needs to send the appropriate header.

Re:I can haz ur eebay de-tails?

[Anonymous Coward]

Looking at the file extension was the cause of similar security bugs in IE a couple of years ago. Someone would add music to their web page, setting the server up to return "Audio/midi" - but the file was named ".exe". So, IE downloads the file, it's an audio/midi file, so no need to pop up the "run/save/cancel" dialog, and then IE passes it on to the OS. Which looks at the file extension, (.exe), and runs the program.

File extensions should not be used, only the mime type.

Re:I can haz ur eebay de-tails?

[clone53421]

File extensions should not be used, only the mime type.

They have to be used, because Windows relies on them, but everything should stop if they don't MATCH the mime type. That's when you get into trouble.

Re:I can haz ur eebay de-tails?

[whong09]

We're revoking your fight club membership card. Turn in your soap.

Re:I can haz ur eebay de-tails?

[Ed Avis]

Point is, if the server indicates a particular Content-type (which could well be based on filename extension, or alternatively on a script header, phase of the moon, whatever) then the client must respect it and not override it with its own guesses.

Re:I can haz ur eebay de-tails?

[clone53421]

Agreed. Your point stands. (I tend to be just a little bit pedantic and I wanted to clear up something that just wasn't quite right...)

Re:I can haz ur eebay de-tails?

[kalirion]

How many security issues do applets have? I thought they were supposed to run in a sandbox. What's the point of the sandbox if it allows an applet access to the file system or registry? Just protecting against buffer overflow?

Re:GIFAR

[Anonymous Coward]

I'll pirate your account with my Gif-Yarr!

At last, after all my years of searching...

[Paradigm_Complex]

I warned you all! I've known for years the bad guy from Aladdin would eventually tire of stealing stuff from mysterious caves and start breaking into computers!

Re:At last, after all my years of searching...

[An ominous Cow art]

I'll be disappointed if the command to begin the attack isn't:

GIFAR, kree!

Re:At last, after all my years of searching...

[Anonymous Coward]

If I had a parrot that sounded like gilbert gottfried, I'd probably be as bitter and sociopathic as GIFAR.

Re:At last, after all my years of searching...

[pcgabe]

Do you pronounce GIF (graphics interchange format) with a soft G? How do you pronounce "graphics"? Does it sound like a tall animal?

Re:At last, after all my years of searching...

[FineWolf]

I can not wait until my screen starts flashing with the following: Harek rel kree lo'mak onak rak shel'na

Re:At last, after all my years of searching...

[Paradigm_Complex]

The developers pronounce it with a soft 'G,' as in the peanut butter brand. When it comes up in conversation, most people I've heard use a soft 'G' in GIF. (I can't think of an exception, honestly.) It may be a local/regional kinda thing, like pop vs soda vs coke.

I've heard "Ubuntu" pronounced every way imaginable.

Re:At last, after all my years of searching...

[pcgabe]

Oh, I know, but as GIF did not enter English via a Romance language (eg, Italian), and all OTHER words that begin with gi- are pronounced with a hard g, and everyone I know (except for one guy) pronounces it with a hard g, and the hard g pronunciation is by far the more common one (despite your personal anecdotal evidence to the contrary) especially with people who don't know the word's origin, I'm going to say that hard-g GIF is the more correct pronunciation.

Or to quote Erik Macki: "English is full of words whose pronunciation deviates from prescribed standards--precisely because usage, and not prescriptive rules, dictates what is "correct." No amount of arguing from pundits and word-coiners can ever change this!" (emphasis mine)

So yes, the creator of the GIF format pronounced it JIF. Unfortunately for him, he doesn't control the minds of everyone on the planet (or DOES he?).

This can be our Shibboleth. Have someone pronounce GIF, and if it's a soft g, you know they're probably an old-school type programmer, the kind who likes to make painful puns and is a wizard on the console. If it's a hard g, they're just a regular person with, you know, social skills and such. ^_^

Re:At last, after all my years of searching...

[Paradigm_Complex]

Your argument for a hard 'G', as I understand it, is based on the pronunciation of other words 'gi-' words which - as you point out - have Romantic etymologies. The fact GIF is not decedent from another Romantic language essentially frees it of this obligation, no? The word is made up, and as such it does not rely on any etymology at all.

I do agree with your quote - English has changed over time based on the general public's understanding/use of the language irrelevant than what is proper. An (tech-related) example of sorts: Firefox is officially abbreviated 'fx,' although the vast majority of times I've seen it abbreviated it ended up being 'ff.' As Firefox, and along with it 'ff,' becomes more and more popular it doesn't matter what Mozilla says - 'ff' is what will be used.

How I interpret this, though, it only means that when one pronunciation is sufficiently popular it can be taken as the 'correct' pronunciation irrelevant of the official/original pronunciation. We would need a sufficiently disproportionate number of people pronouncing it one way for your quote to be relevant.

I did not know the developers pronounce it with a soft 'G' until I looked it up just before posting. I pronounce it such because that's how I've pretty much always heard it pronounced. While I know this is not a large amount of evidence for the popularity of either pronunciation it does make the possibility of a hard 'G' being substantially more popular less than likely.

Considering the fact that we don't have any sort of statistics (a /. poll would be nice), and considering the fact that GIF - being made up - has not etymological ties, the only thing we have to fall back on is what the developer's stance is.

Hence, a soft 'G' is more correct. QED? :D

Re:At last, after all my years of searching...

[Anonymous Coward]

Criticizing the GP for using anecdotal evidence to "prove" GIF is pronounced with a soft g right after using your anecdotal evidence to "prove" it's pronounced with a hard g. Grammar nazis, this is ironic, right?

please...

[pohl]

...won't someone think of the PORN!?

Re:please...

[D Ninja]

I'm sure they already have.

Re:please...

[j00r0m4nc3r]

Just wait until they figure out how to merge Goatse with SWF

Re:please...

[AutopsyReport]

Already been done.

Re:please...

[Lord Apathy]

I do.. all the time.....

Re:please...

[Anonymous Coward]

www.goatsemarathon.com

Re:please...

[Anonymous Coward]

HOW FUCKING DARE YOU! Leave crocker aone! WHAT HAS HE EVER DONE TO U? he's just been through a BRITNEY MELODRAMA! can't you JUST LEAVE HIM ALONE!!10!1CAT!

Re:please...

[zapakh]

...I'm not clicking that with a ten-foot pole.

Re:please...

[Aerospike]

You mean by using a PornStjar?

Oh no

[fortyonejb]

As if tub girl wasn't insidious enough... Now she's going to steal my accounts?

Mmhhmm....those pesky details...

[MeanderingCode]

What a roadblock to all those brialliant, anti-social types who won't ever be able to put the last pieces to together as they spend 23 hours a day in front of their "command centers". Sounds like security through obscurity, except they forgot to obscure it.

Re:Mmhhmm....those pesky details...

[Adriax]

The point was to slow the kids down by making them figure out the fine details themselves, giving browsers and image sites time to fortify against this attack.

Re:Mmhhmm....those pesky details...

[The Dancing Panda]

Security through obscurity does, in fact, keep things secure for a period of time. Hell, password protection is security through obscurity.

This is sort of a weak attack, if I understand what they're doing. The web browser sees the file as an image when you upload it. The server, on the other hand, sees it as a JAR file, and when it is accessed the next time, executes it. If it works, this is a pretty decent hack, but to actually get user information, you'd need a bit more info. First, they need the JVM installed on the server (which they probably have, but it's not a given). They also need a database schema, an open hole to get the information back to the hacker, and most importantly, DB passwords. So, even if this comes out 0-day, your myspace profile is probably safe.

Re:Mmhhmm....those pesky details...

[pjt33]

In terms of creating something which is both a gif and a jar, it's a simple case of cat myimg.gif myapplet.jar. The fact that you can cat a gif and a zip file and get something which conforms to both specifications has been known for years. The interesting bit will be the way they turn the Facebook img tag into an applet tag or otherwise persuade the browser to execute the applet.

Re:Mmhhmm....those pesky details...

[The Dancing Panda]

Wow...RTFA...I was way off. But I don't quite understand what would make Java open these image files... Do they have ".jar" extensions? shouldn't facebook and the like be...I don't know...not allowing those?

Re:Mmhhmm....those pesky details...

[Anonymous Coward]

IIRC, there was an attack on php which worked by embedding php code inside the GIF comment field - the php parser ignored all the image cruft and ran the embedded php. Sounds similar - the attack could just depend on a few misconfigured variables.

Re:Mmhhmm....those pesky details...

[Phybersyk0]

easy and old:

copy /b myimage.jpg + filetohide.mp3 my_new_image.jpg

It's a good way to hide mp3 files in images and get past the pesky proxies blocking .mp3/.mpg files.

Just drop the mp3-imbedded gif/jpg file into winamp and... presto! you got music.

Re:Mmhhmm....those pesky details...

[gd2shoe]

They probably do have a .gif extension. There are several ways for a browser to determine the file type, and I don't think the file extension is the primary way. The HTTP server itself can send a mime type, and many HTTP servers pick a mime type by inspecting the beginning of the file.

That said, I doubt it is as simple as renaming a .jar to .gif before uploading it. If I could guess that line of logic, so could most web black hats.

Re:Mmhhmm....those pesky details...

[sakdoctor]

How is password protection security through obscurity? I can think of no case where this is true.

Re:Mmhhmm....those pesky details...

[Anonymous Coward]

Modded 4 informative? RTFA. The jar is executed on the client (specifically Internet Explorer), not the server.

Re:Mmhhmm....those pesky details...

[MagdJTK]

Security through obscurity does, in fact, keep things secure for a period of time. Hell, password protection is security through obscurity.

I think you may be misunderstanding the phrase "security through obscurity". Password protection is not security through obscurity because the system essentially says "I'll let you in with the password. What is it?" The system tells you exactly what's going on and that you need a password.

An analogy with a door: A large padlock is like a password. It's clear how it works, but you need the key to get in. Security through obscurity might be only having the door open if you touched a particular part of it. It'll fool people for a bit, but once they've realised what to do, it's blown wide open.

Re:Mmhhmm....those pesky details...

[Creepy Crawler]

Obscurity: hiding so that the proper user knows the secret will be allowed in.

password: secret word/phrase. Can be brute forced, cracked, found hiden on a post-it, or just plain guessed at. Absolute worst case puts password at 2^8 per character, minus stated password rules.

Re:Mmhhmm....those pesky details...

[bunratty]

At its most basic, security by obscurity is relying on a secret to remain secure. Obscuring your password is security by obscurity. It's only a matter of time before an attacker could guess your password, so it keeps you secure for only a period of time.

Re:Mmhhmm....those pesky details...

[bunratty]

How is a door opening when you press a certain part of it different from a computer letting you in after you press certain parts of the keyboard? I have learned someone's password by watching them type it in over their shoulder. Their password was not obscure enough. A good password is simply more obscure -- it will take longer to crack, but it can be cracked.

Re:Mmhhmm....those pesky details...

[zapakh]

At its most basic, security by obscurity is relying on a secret to remain secure. Obscuring your password is security by obscurity. It's only a matter of time before an attacker could guess your password, so it keeps you secure for only a period of time.

Depends on the nature of the secret. By your reasoning, all shared-secret cryptography is security by obscurity, because every secret key can be brute-forced (and if it doesn't work, you're not using enough).

You have security by obscurity of your security depends on the secrecy of not only a cryptovariable, but the design or implementation of the system in question. For example, the construction of a GIFAR. As GGP notes, obscurity may work for a while (but there's no telling how long). GGGP's point was that "concatenate two files" is not all that obscure.

Re:Mmhhmm....those pesky details...

[TedRiot]

Any HTTP/1.1 message containing an entity-body "SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream"."

(http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1)

So what the RFC says is basically that if Content-Type is given by the server, the client must not try to guess any different.

I don't know about the situation at the moment, but when I did web work (the last time was about 3 years ago), it was only IE that didn't care about Content-Type headers. Firefox didn't try to guess at least on text/plain and application/octet-stream.

Didn't try to send jar's as gif's, though. Didn't try to rename jar as a gif and see what Apache sent, either.

But the point is that if the browser guesses Content-Type other than is provided by the server, the browser is broken.

Re:Mmhhmm....those pesky details...

[MagdJTK]

I think maybe I explained it badly.

Suppose we have an encryption system. It takes a message m and a key k and outputs e=c(m,k), our encrypted message (c being our encryption function).

Security by obscurity would be keeping the function c secret. Although this sounds like a good idea, it's actually a very bad one. Because noone but you knows how it works, noone will test it and it could be open to attack without you knowing. All it would then take is an enterprising person to reverse engineer the function and screw you over (without you having the faintest idea).

For best security, the function c should be freely available. Then any security holes can be found. It should be very difficult to find k or m from e, despite the function c being public knowledge. (Examples include AES, PGP, DES [now no longer secure due to brute-force methods].)

Going back to our door example (yet again): a properly secure system might be a big beefy lock which has undergone lots of testing. Security through obscurity would be some kind of custom-built electronic hidden lock that you can't see. Although that sounds more secure, it hasn't been thoroughly tested and could in fact be easily bypassed.

Re:Mmhhmm....those pesky details...

[gd2shoe]

I didn't bring up HTTP clients guessing by inspection. I brought up HTTP servers guessing by inspection. Apache can be set up to do that, for example.

My point was that different code may be responsible for verifying that an image is being uploaded (simplistic file extension test) than what determines the mime type (file inspection).

Re:Mmhhmm....those pesky details...

[TedRiot]

Well, you did bring out the browser, too. My reply was mainly to the "There are several ways for a browser to determine the file type, and I don't think the file extension is the primary way." -part.

I think this said vulnerability has to be looked a bit from both perspectives (server and client). If a server sends a jar-file with a correct mime-type that is requested by the client because an img-tag referred to the URL, does the client really run the java-code? I think the client should be programmed to discard anything except image/* -types for img-tags. If the jar-file is sent using image/gif or image/jpg, the client should display a broken image. Of course the situation is different, when the jar-file is not referenced by an img-tag. If the server sends a jar-file with any extension and says it is a jar-file, the client must according to the RFC treat it as a jar-file.

Re:Mmhhmm....those pesky details...

[Anonymous Coward]

I hate to ruin a party, but facebook converts gif files to jpg on upload.

But What's the Use

[D Ninja]

So, I, for the life of me, cannot figure out what point an (essentially) "executable" image would have. To me, it seems like this mixing of concerns is a very bad idea. It's either data (an image) or an executable (application). Not both.

Can anybody explain the thought process behind this?

Re:But What's the Use

[Anonymous Coward]

it sounds like what they are doing is creating a specially crafted Java archive (jar) that is disguised as a gif. You upload it to a site, the site stores it on their domain eg: images.somesocialsite.com The attacker would then make a webpage on his site, http://attacker.com/loadgar.html and in it would tell it to include the jar file from images.somesocialsite.com - in this situation the jar would be considered to be "from" the images.somesocialsite.com which would put it in the proper zone to be able to read *.somesocialsite.com cookies.

Re:But What's the Use

[Anonymous Coward]

Er. I don't think it's meant to be executable. I think that's the point: it's a security flaw.

Re:But What's the Use

[Sloppy]

The attacker would then make a webpage on his site, and in it would tell it to include the jar file from images.somesocialsite.com

The part I don't get, is that images.somesocialsite.com is presumably sending it as an image/gif mimetype, so why is the browser running it (passing it to the JVM)? This sounds like a browser bug.

Re:But What's the Use

[Coward Anonymous]

I'm guessing you have it backwards. The referencing webpage marks up the file as a Java object. I imagine the GIF part is to get past the socialsite server's image validity tests so that it will agree to host the file.

Re:But What's the Use

[Anonymous Coward]

Does somesocialsite.com allows arbitrary HTML on user-created pages? Then *this* is a security hole size of Uranus.

Re:But What's the Use

[UnderCoverPenguin]

The part I don't get, is that images.somesocialsite.com is presumably sending it as an image/gif mimetype, so why is the browser running it (passing it to the JVM)? This sounds like a browser bug.

I'm guessing you have it backwards. The referencing webpage marks up the file as a Java object. I imagine the GIF part is to get past the socialsite server's image validity tests so that it will agree to host the file.

In my experience, the server should be sending the file with a MINE type of image/gif, so the brwoser should be treating the file as a GIF.

Something I actually tried to do, once:

I uploaded an SVG image to an image hosting website. But, the website, not "knowing" what a SVG file is, sent "Content-type: text/plain". (SVG is XML based, so is actually text.) Several web browsers, including FF and others, dutifully displayed the actual XML text.

I then tried making a webpage included the type attribute, specifiying "xml/xml+svg". The web browsers continued to display the XML text.

Given this observed behavior, I would expect that, when servering up a GIF file, either the server failed to include "Content-type: image/gif", or the browser ignored the contact type from the server. Either of these, IMHO, is a bug.

PS, FYI, I ultimately got the SVG file to be displayed correctly by re-uploading it as an XML file. The server then sent "Content-type: xml/xml" and the web browsers figured out what to do with it.

Re:But What's the Use

[AC-x]

I was wondering how they could actually turn this into an attack vector, but that sounds about right, quite a clever hack too

Presumably any resizing / processing done on the image by the server would destroy the hack tho...

Re:But What's the Use

[ConceptJunkie]

Basically every data format Microsoft uses has some way to embed executable code or scripts. I guess it seemed like a great idea to them in the early 90's, and we live with the pain from that decision every day.

Re:But What's the Use

[pjt33]

the jar would be considered to be "from" the images.somesocialsite.com which would put it in the proper zone to be able to read *.somesocialsite.com cookies.

This is slightly more subtle than it seems. Sure, you can get document.cookie via JSObject, but how do you get cookies for another domain?

Re:But What's the Use

[owlstead]

IE looks at the content instead of the MIME header. Another case where M$ fucks up standards protocols. Firefox does this correctly. This is why you see garbage in your browser instead of pictures/movies on some sites. The server tells Firefox that the content is just text/html, while IE just looks at the file itself and simply ignores the MIME HTTP header.

I've once send a message to Tom's hardware because I could not few their video's in Firefox. They configured their server correctly and everything was dandy. I feel a bit more worried in doing this for all other sites that deliver videos and are frequently have ill-configured servers though. They are not always the places I would like to send emails to.

Re:But What's the Use

[owlstead]

Reading through the other comments and reading the bug report on Apache, it seems some other piece of software is to blame as well. Just returning text/plain if the content is unknown, WTF are these guys thinking? And why isn't this fixed after ~ 6 years?

Re:But What's the Use

[WWWWolf]

I then tried making a webpage included the type attribute, specifiying "xml/xml+svg". The web browsers continued to display the XML text.

Which is pretty logical, considering the correct MIME type for .svg files is "image/svg+xml". "xml/" isn't (last I checked) a valid prefix at all, and XML-based formats have "+xml" in the end of the latter part, not the beginning!

The MIME types of various XML-based formats are a pretty complex issue; some ill-defined formats (*cough* some OPML hacks) may need to be served as deprecated "text/xml", some as "application/xml", and then there's various text|application|image/*+xml types.

PS, FYI, I ultimately got the SVG file to be displayed correctly by re-uploading it as an XML file. The server then sent "Content-type: xml/xml" and the web browsers figured out what to do with it.

Well, isn't that bad voodoo? One would assume that the correct behaviour when encountering "some random XML stuff" would be to display the file as XML, again, and not make weird assumptions...

Re:Another reason Java sucks

[X0563511]

We might say the same about you. Try to be considerate and civil, it makes you look like less of a tool.

As usual, safe browsing practices protect you

[Lord Kestrel]

Things like a properly constructed white-list for Noscript, not allowing Java by default, etc. will all protect you from this.

It's a shame that security tools that can help mitigate some of these attacks are difficult to understand and use for many users.

Re:As usual, safe browsing practices protect you

[andymadigan]

Actually, my guess is that this is some sort of automatic file type detection where the browser tries to detect the type of file and use the appropriate plugin (thus causing the JRE Applet Plugin to potentially get selected). If that's the case, NoScript may not recognize it, though disabling Java should fix it.

Re:As usual, safe browsing practices protect you

[kaidadragonfly]

Noscript can be set to block Java (and Flash) by default, so activating either plugin requires explicit user interaction.

Re:As usual, safe browsing practices protect you

[andymadigan]

The question would be whether it blocks the HTML that causes the applet to be initialized, or whether it can actually prevent Firefox from loading the JRE through plugin loading. Admittedly, I don't know how NoScript works.

Re:As usual, safe browsing practices protect you

[Giorgio Maone]

NoScript blocks both.

If either the attacker site containing the applet tag (likely) or Facebook (unlikely) are not whitelisted, the applet won't run by default.

Furthermore, if NoScript is configured as a content blocker as kaidadragonfly said, there's no chance for the applet to run even if both sites are whitelisted.

Advert on hacker message board

[hivebrain]

"Upgrade to a hybrid today and get 20% more mileage on your phishing messages"

I thought only Windows did this:

[CustomDesigned]

The mime type says "GIF", but if it looks executable, try to run it anyway. Or maybe it is just Windows. TFA didn't mention which software does this (other than "the browser"). At one point they blame Sun. Huh? Does the GIF have an applet tag? Or does this attack involve running a malicious applet at evil.com, which then loads a JAR from facebook.com (which was uploaded as a GIF) and the JRE runs it as if it came from facebook. *That* would be a Sun problem (and not a "browser" problem).

Re:I thought only Windows did this:

[Bogtha]

The article was light on details, but it sounds like an extension of a known attack, and if this is the case, then it's not Windows, but Internet Explorer. Internet Explorer ignores the Content-Type header in various circumstances, in violation of the HTTP 1.1 specification.

This matters because services like Facebook serve these fake "images" provided by their users to Internet Explorer and explicitly tell Internet Explorer that they are images. Internet Explorer then happily ignores them and tries to guess what type of file it is on its own. If the file looks a bit like HTML and you click on a link to it, Internet Explorer will happily execute Java and JavaScript on that page within the security context of the domain serving it.

If you've wondered why these types of services force you to save images when you try to view them outside of the context of a web page, now you know why. It's because it's the only reliable way to ensure that Internet Explorer doesn't execute it. Think of it as a straight-jacket to stop a mentally ill person from hurting themselves.

It's okay though, Microsoft are fixing the issue in Internet Explorer 8. By making Internet Explorer respect the HTTP 1.1 specification? Of course not! By adding a new proprietary header attribute.

Re:I thought only Windows did this:

[Anonymous Coward]

I agree with the parent, the article is a bit unclear. If I read this correctly:
http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/java_js.html
Unsigned java applets are usually highly sandboxed (they can't even access the DOM) and can only communicate with the server they reside on (e.g facebook webserver). So, wouldn't one need another exploit to get around the VM sandbox before even considering using this?

Re:I thought only Windows did this:

[CustomDesigned]

TFA mentions that "you need to be logged in to facebook for the attack to work". So an evil applet that JRE thinks came from facebook would indeed be able to do things on facebook as the logged in user.

Re:I thought only Windows did this:

[Anonymous Coward]

http://blogs.msdn.com/ie/archive/2005/02/01/364581.aspx

From the link you posted.

Because of the number of legacy servers on the web (e.g. those that serve all files as text/plain) MIME-sniffing is an important compatibility feature.

You may say they shouldn't have done it in the first place. But even now when they want to fix it, they cant because of the shitstorm people kick when they are asked to fix their servers.

Re:I thought only Windows did this:

[Culture20]

like installing custom FB apps.

Re:I thought only Windows did this:

[Bogtha]

Because of the number of legacy servers on the web (e.g. those that serve all files as text/plain)

If you missed it, that was a thinly-veiled jab at Apache. Check out Bug #13986. You know you aren't doing well when an author of the HTTP 1.1 specification shows up on your bug tracker to post a "WTF?" comment :).

Re:I thought only Windows did this:

[Myen]

It's not IE, it's the Java plugin (which, umm, MS doesn't even make anymore). It's just a normal cross-origin vulnerability.

(Umm, this is my best guess, but I believe it makes sense and not surprising.)

GIF files have a header (GIF89a and all). JAR (PKZIP) files have a footer (central directory, i.e. the TOC). When the attacker uploads the file, the server sees the GIF (/PNG/JPEG/BMP/...) header and accepts it as an image. Anybody going to the server's page would have their browser attempt to load the file as an image (and possibly succeed, if the attacker wanted it).

The Java plugin would be invoked by a page on a completely separate sever (that the attacker controls), with an <object> / <applet> tag. The plugin would load from the attacked server (e.g. facebook), and therefore for origin checking purposes it belongs to the attacked server.

It's like this old IOCCC entry which happens to be a shell script, a makefile, and C source all at the same time.

People have been doing similar things as weak stenography already - posting images which have been concatenated with archives (rar, zip) that show as images in the browser, but the archivers would search through the whole file for something to extract.

Re:I thought only Windows did this:

[Bogtha]

The Java plugin would be invoked by a page on a completely separate sever (that the attacker controls), with an <object> / <applet> tag.

If the server being attacked specifies that it is an image in the Content-Type header, then a browser should respect that and not pass what is supposedly an image to a Java plugin. If a browser ignores the Content-Type header, then it is in violation of the HTTP 1.1 specification.

The plugin would load from the attacked server (e.g. facebook), and therefore for origin checking purposes it belongs to the attacked server.

It's been a while since I've done anything with Java applets, but I thought that the host restrictions were based on the location of the page and not the applet?

Linux

[Darkness404]

Well, this proves it again, by making Java so hard to install, Linux avoided yet another threat.

Re:Linux

[FunkyELF]

emerge jdk

Yeah, you're right...that was hard.

Java has never been hard to install, it just isn't installed by default just like Nvidia drivers. Although, I just gave a Gentoo example where nothing is installed by default.

Re:Linux

[Darkness404]

Well, actually on my (eee)Xubuntu install I'm still having a bit of trouble getting Java to work for vNES, though I think it has more to do with my screen being so tiny then a flaw in Ubuntu or Java.

Re:Linux

[hansraj]

You are such a cheerful person. You must be a thousand years old.

Re:Linux

[dstech]

Well, this proves it again, by making Java so hard to install, Linux avoided yet another threat.

Your joke is about a year late... fedora 8 and 9 even have java installed by default.

Nice try though.

In fairness, the browser plugin requires you to 'yum install (openjdk|icedtea)-plugin'. But, still, not that hard...

Easy to defend against

[Anonymous Coward]

It looks like it's just crafting a java applet so that it fools web sites into thinking its a gif image and allows it to be uploaded, whereas they usually wouldn't allow java applets, thus anyone who then tries to view this file, their browser would try to open it with the JVM.

The first thing is that Java uses a strong sandbox model, so you really couldn't do much with it. Secondly, if you don't have Java installed, or have it turned off by default using AdBlock or NoScript, the file wouldn't run.

Thumbnails

[omnichad]

What site doesn't resize the uploaded image for display? That wouldn't result in "compressed code" it would just be an image.

Re:Thumbnails

[FunkyELF]

A better solution is not to allow GIFs. No more animated emoticons!

Re:Thumbnails

[UnderCoverPenguin]

If the file is small enough, the service might not resize it.

Java not Javascript?

[fortyonejb]

If i'm reading this correctly, it is a java applet, which if you don't have the runtime installed, or turned off, you'd be ok, but for the millions of users who have no clue about java, they'd be nailed. If you didn't have java will it prompt you to get it, thus assisting the attack? Even a javascript attack would be vicious, as the script would appear to be coming from the site itself, so if I was allowing scripts from facebook, this nasty little bugger could still get through...

Re:Java not Javascript?

[Anonymous Coward]

Well if its an applet, clueless users are saved. They'll be trying to load a picture and get frustrated by the long load time and close the window.

YouTube?

[LM741N]

I am very curious whether some similar type of exploit could be used on YouTube uploads. Well, I guess we'll know soon.

Re:YouTube?

[jebrew]

Not likely, youtube transcodes anything uploaded, so unless you've got a way to slip the code past a transcode and subsequent wrap into a .flv, then you're not going to hone your pwnage.

Now as for taking down some youtube servers using this exploit, while it's unlikely, is definitely more possible. Though I'd imagine their transcoders aren't written to execute code if a supposed videostream is mislabeled.

Re:YouTube?

[EvilIdler]

I doubt ANY transcoders execute code in the streams. If they go from one video format to another where both support some sort of scripting, it would just translate the instructions to the new format, not run it. Not that there are many formats beyond MS formats and perhaps Real which do more active things..

Re:YouTube?

[Anonymous Coward]

Actually the content of the video could tell the viewer to go to evil.com for the rest of the video, or more similar videos or they can unlock the rest themselves by using the command format c:.

I know there are Tony Robbins followers out there that would do it if he were the person in the video giving the instruction. : )

print page

[A little Frenchie]

http://www.infoworld.com/archives/emailPrint.jsp?R=printThis&A=/article/08/08/01/A_photo_that_can_steal_your_online_credentials_1.html

Re:print page

[giantweevil]

Browser security is an oxymoron?

Apparently they aren't using firefox.

Re:Another reason Java sucks

[GigaHurtsMyRobot]

Java is the epitome of bad programming, despite all that you can do with it. It's just a terrible implementation of a great capability. I loathe its insurgence into the mainstream.

So what?

[Anonymous Coward]

OK, so this attack can allow bad guys to put java applets in web pages which appear to be GIF images. So what? You can already put a java applet directly in a web page.

And aren't java applets run in a sandbox? It seems you need another hole to get out of the sandbox.

Re:So what?

[Deadplant]

they are suggesting that BadGuy could upload a 'gif' which is really a jar file to his facebook page.
Then any logged-in facebook user who viewed that 'picture' could have their facebook login cookie stolen.
BadGuy could then use that cookie to look through the private part of your profile, change your password, etc..

Re:So what?

[ignoramus]

OK, so this attack can allow bad guys to put java applets in web pages which appear to be GIF images. So what? You can already put a java applet directly in a web page.

Indeed.

But you can't normally put your own custom applet up and have it downloaded and run from somewhere under, say, facebook.com. This has implications... the simplest to imagine is that your browser will gladly provide facebook cookies to facebook applets--which is why this particularly affects the type of sites where people stay logged in all day.

Re:So what?

[Tacvek]

Um... how does the java code from the jar end up getting executed anyway? Surely when embedded within an IMG tag the browser will determine that the file is a GIF, and use its own tools. I would find it hard to believe that a browser would ever load the java runtime to display something in an IMG tag. If the browser does do that, that sounds like a major browser flaw.

That's no photo, that's my wife!

[Anonymous Coward]

Thank you, thank you, come again.

Re:GIFAR

[Vectronic]

Or Jafar

Jafar's name seems to be derived from a character named Jafar or Giafar in tales of the Arabian Nights, who is the Vizier to the 9th century Abbasid Caliph Harun al-Rashid; this character in turn was based on a real-life vizier, Ja'far bin Yahya Barmaki. Harun and Giafar were the protagonists of many stories in Arabian Nights, but Giafar was never presented as a villain. Harun did have the real Ja'far bin Yahya Barmaki beheaded after a dispute arising from allegations that Ja'far had engaged in an affair with the Caliph's sister. The original tale of Aladdin, a Syrian story not originally attached to the Arabian Nights, features two characters who correspond to Disney's Jafar. One is an unnamed vizier who is jealous of Aladdin but does not serve as a real villain; the other is the major antagonist, an evil magician from the Maghreb in North Africa who introduces Aladdin to his magical lamp.

...
He is shown to be scholarly and learned in arcane lore, his secret chamber filled with strange devices and stacks of tomes, and, as such, he operates more on the level of an alchemist throughout the film's duration than an actual magician. Instead of casting spells, he relies on previously prepared potions capable of producing magical phenomena...

Re:Another reason Java sucks

[Random Guru 42]

He's not wrong, you know. Java was pretty much Pascal for the nineties.

Re:Another reason Java sucks

[Deadplant]

It is true, java is great big stack of Fail.

My speculation

[MobyDisk]

This sounds like those tricks where someone writes a code module that compiles in both a C++ compiler and a Pascal compiler, by playing with anomolies in the syntax of the language. Only someone has made a JAR file that looks like a valid GIF file.

I fail to see how this will work though. Even if I could craft such a file, it will have .GIF extension which will make it serve-up as image/gif MIME type so it won't be loaded by the JVM. Now we know that older versions of Internet Explorer will look at the file content not the MIME type - do they still do that? If so, I guess IE might see the file as a JAR not a GIF, but nothing else would. Also - won't that GIF file be in an tag? Surely even IE won't run the JVM for something that isn't in an tag right?

I can put a Java file on my MySpace page anyway, so disguising it as a GIF doesn't really change things. I guess the benefit to the hacker here is that they could do it on sites that normally don't serve Java. And since Java can do basically the same things that Javascript can, it's another XSS attack vector.

Overall, this isn't anything I'm too worried about. Although I'll be very impressed if someone can get a JAR to run from an tag. Also, Kudos to anybody who can make a GIF appear as a JAR. They get points for being inventive.

Re:My speculation

[nabsltd]

Even if I could craft such a file, it will have .GIF extension which will make it serve-up as image/gif MIME type so it won't be loaded by the JVM. Now we know that older versions of Internet Explorer will look at the file content not the MIME type - do they still do that? If so, I guess IE might see the file as a JAR not a GIF, but nothing else would.

IE up to version 7 still does this, but unless the IE programmers are a lot smarter than we think, IE should see this combined file as a ZIP file, which is all a JAR file is.

Using a very recent version of "file" (Fedora 9), I get the following:
$file foo.jar
foo.jar: Zip archive data, at least v2.0 to extract

If "file" can't figure it out, I'd be surprised if the IE programmers can.

Re:My speculation

[ratboy666]

It's a two-cut - short in the front, long in the back...

GIF in the front, ZIP (JAR) in the back. Just append them. It's an old stego trick. Of course we can hide the "zip" part as well -- append a block of zero to the end of the file.:

$ cat Chess_knight_icon.png a.zip >a.png
$ file a.png
a.png: PNG image data, 21 x 21, 4-bit colormap, non-interlaced
$ unzip -v a.png
Archive: a.png
warning [a.png]: 257 extra bytes at beginning or within zipfile
    (attempting to process anyway) ..listing elided to bypass junk filter..

See? It even works with PNG format! Now, a warning - zip will search for a valid zip header from the end of the file, so to hide
the fact that its a zip file (for stego), you have to jam in a lot of random crap at the end.

IE7 ignores "content-type", and uses its best guess. My guess? "facebook" (whatever) accepts the file as an image, because of the GIF stuff in the front. It shouldn't even care about the extension, so "jar" may even be ok (haven't tried this at all, play with it).

When IE gets the reference to download a "jar" from facebook, it does it -- and blithely ignores the "content-type image/gif". It looks at it -- its a ZIP, probably jar, and... bobs you uncle. I know IE7 ignores content-type text/plain - feed it something that smells like html, and it renders. Which makes display of text documents with htmly stuff kind of tough.

Just a guess.

Re:GIFAR

[Anonymous Coward]

Jafar?

No... Jew?

Possibly not.

[khasim]

First off, what idiot mod'ed you "Troll"?

Secondly, if the user whitelists FaceBook then that would PROBABLY also whitelist the picture/jar that is the exploit which would be downloaded from FaceBook.

Yeah, the security is an issue. At least for right now. It might take a major re-write to kill this exploit. Probably a sandbox where EVERYTHING from a web page would be temporarily stored, then analyzed to see what it was and what the web page reported it as. Probably by digging into the headers of each file and having a setup similar to Apple's for identifying the app that should run a given file.

Re:Possibly not.

[Tony Hoyle]

No it would just take facebook to do better validation, and any other site that allowed this to happen.

I have my doubts it would even work in the real world, otherwise facebook need a kick up the arse as they should have seen it coming.

Workarounds for websites

[ak_hepcat]

* resize the image
* crop the image 1x1 pixel smaller
* convert the GIF(ar) to PNG or JPG
* optimize the GIF file
* shrink/reorder the color palette
* edit the comments

Gosh.. really, anything that affects the actual data package, but doesn't visibly hamper valid pictures.

Re:Workarounds for websites

[ignoramus]

You're right, of course. Problem is mainly that it's one of those "if everybody does X, all will be fine" solutions.

Right now, all sites that provide for image uploads would need to act or all users would have to disable Java. Reminiscent of the recent DNS caching issue, or 3/4 of the proposed solutions for spam... there's a long turnaround, if it works out at all.

And if we somehow made the applet file format different, more strict to avoid it masquerading as another file type, how would that affect the jillion existing applets? Not sure if a simple solution exists.

Re:Workarounds for websites

[TheMeuge]

Somebody mark this comment "Insightful" would you please. It certainly deserves to be modded up, and possibly forwarded to the services that allow this kind of an attack to occur.

This would be a rather simple way to protect their clients against such an attack.

Re:Workarounds for websites

[hotdiggitydawg]

Even better, just truncate (or tweak) the image metadata.

If it was a JPG it would be a good idea to do this to protect user privacy anyway - I'm not familiar with the GIF metadata though.

Re:Workarounds for websites

[Anonymous Coward]

Most sites that allow image uploads already do some processing on them. This issue seems overblown.

This already happened to me...

[anomnomnomymous]

I've got this photograph in my wallet... and it's gauging my money on a daily basis :/

Java applet?

[SilverJets]

There are websites still using Java applets? I thought those died years ago.

how is that different from XSRF?

[Krischi]

TFA says that a user needs to be logged in for this attack to work. This sounds as if the mechanism is the same as or similar to a cross-site request forgery. Shouldn't it be possible to stop the attack with similar countermeasures, such as tokens that need to be submitted along with the request for sensitive information?

This is true...

[Channard]

.. but just think about how many people happily forward links to all their friends? Who then happily click on the links. Granted, your average Slashdot reader might be too IT literate to fall for this, but Joe Public certainly isn't.

Java?

[changa]

I uninstalled java from my machines years ago.

Does anybody honestly still use it for anthing useful on a webpage?

JAR = ZIP, and GIF+ZIP = old news

[marcansoft]

JAR files are just ZIP archives. ZIP archives are based on the end of the file, where the central directory is located (this is also why you can often unzip a self-extracting exe using a normal unzip application). GIF files, like most other files, are based on the beginning of the file. ZIPs don't care if you shove data in front of them. GIFs don't care if you shove data after them.

$ cat file.gif file.zip > file.gizip
Rename the result to .gif or .zip. Both work. You can also substitute JPG instead of the GIF, or any other file type that ignores trailing garbage.

I'm not sure if there's some kind of trick that is needed for the exploit to work, but the fact that you can make a file that works both as a zip and as almost any other file type has been known for ages.

Re:JAR = ZIP, and GIF+ZIP = old news

[Anonymous Coward]

Actually, just tacking a ZIP file onto the end of a GIF file will result in an invalid ZIP archive, since the various offsets (central directory start, as well as the start of each file's local header) are relative to the beginning of the file (which has now moved forward by N=length('file.gif') bytes).
That's not to say it can't be done - you just need a more sophisticated program to do it.

Re:JAR = ZIP, and GIF+ZIP = old news

[EkriirkE]

Sorry, no. Most ZIP programs simply search for the PK header and use that offset as the header. Try it.
in windows you can do..
COPY /b infile1.gif + infile2.zip outfile.gif

the resulting file can be opened as a graphic, yet an archive program will see the contents of the ZIP

Re:JAR = ZIP, and GIF+ZIP = old news

[noidentity]

ZIPs don't care if you shove data in front of them. GIFs don't care if you shove data after them.

$ cat file.gif file.zip > file.gizip

Actually, a zip file's central directory has file offsets in it, which get broken by the above cat operation. I encountered some files in the past that had a GIF prepended (to act as an album cover for the music inside) and fixed the offsets in the central directory of one of these files, then everything worked properly again.

Re:JAR = ZIP, and GIF+ZIP = old news

[QuoteMstr]

This trick also works with RAR archives.

Re:Another reason Java sucks

[Dishevel]

It is true, java is great big stack of Fail.

With slathering of WTF poured on top.

Uh, I have done this with PHP

[Anonymous Coward]

Uh... anyone forget that you can create PHP files that pretend to be JPG's? I used to have a signature on a forum that would tell users their IP, Browser, OS and generate a random quote... I wouldn't find it hard at all to hack into someones myspace account using the same concept... The only news to me is that they are doing this with JAVA.

Re:Uh, I have done this with PHP

[Anonymous Coward]

That's not really PHP pretending to be a JPG, what comes out of your server really, truly is a JPG. PHP is server-side, remember? You can't get any more information than you would get if they accessed a 'normal' JPG on your server anyways. So yes, you WOULD find it hard to hack someones MySpace with the same concept.
The key to the 'GIFAR' is that the JAR would be run on the client side, so you could have a visitor to evil.com load up a GIFAR from facebook.com which would read the facebook.com cookies, and then submit the entire cookie back to the evil.com server. Copy paste, and voila, you have a valid session to do with what you please.

Re:Uh, I have done this with PHP

[Anonymous Coward]

The parents script could put javascript in the clients page which is even more direct than running java.
As far as browser priveliges go, java and javascript are equal.

Re:Uh, I have done this with PHP

[Anonymous Coward]

Good luck getting facebook to host your PHP script, much less execute it. Besides, the javascript that ran wouldn't be able to access the cookies from facebook.com, even if it was generated with a PHP script from facebook.com. Sure, the PHP could put the cookie in there, but why would you bother going about generating some bullshit javascript when you can execute PHP on facebook's servers?

More Java Hater-aid

[Anonymous Coward]

Uhhh... You mean that 99.9999% of the world doesn't validate images properly on upload and only checks the file extension if that? Wow. You mean a file extension doesn't guarantee MIME type? Thanks for the breaking news.

In other breaking news (circa 1998)....

Drumroll please....

The sandbox for applets prevents them from doing anything malicious, like accessing the file system, opening a socket, or accessing cookies, unless explicitly enabled by the user through the altering of a security policy.

Unlike scripting in IE and Flash, you can't even access the system clip board in Java applets without explicit user permission.

Perhaps this article should have been titled: Everyone on slashdot is retarded, so you'll buy whatever we tell you.

This is a time when the ...

[BitterOldGUy]

goatse guy is appropriate. But, I guess that just me.

and the fix is also known

[SmallFurryCreature]

Just check your ANY and ALL date the user submits for validity. That INCLUDES images. In this case, simply recode the image and foila, it will strip the padded info and all is well.

NEVER EVER TRUST ANY DATA THE USER SUBMITS!

Re:and the fix is also known

[Threni]

CHECK for abuses OF upper CASE characters! NEVER make YOUR text EASY to READ!

Omitting details is a bad idea

[AmiMoJo]

Anyone who knows much about web browser security will almost certainly have enough to replicate this attack very quickly. The recent DNS flaw was replicated based only on the knowledge that there was a DNS spoofing flaw, some rumours and a few patches.

It would be much better to go with full disclosure, so that at least everyone has access to the same info and can take steps to prevent the attack. It would be impossible to try and inform every affected software developer, including open source projects, and anywhere there is no guarantee that they wouldn't just sell the info on the exploit market anyway.

Re:Omitting details is a bad idea

[Tony Hoyle]

Except the attack fails if the image is modified in any way, fails if the server does minimal validation, *and* it only works in IE because that ignores mime types from the server.

I doubt there's an attack surface worth the effort. You can bet facebook does checks.

Stegonography, anyone?

[grayn0de]

The technique is new, but the concept and prctice of it has been around for years. Does anyone remember the days of javascript embedded gifs? NO? ... Hmmm. I think it's odd that people are just now starting to realize that more things on a site can hold code, besides an applet or widget.

Absolutely yes

[Giorgio Maone]

Even if Facebook is whitelisted, the applet wouldn't run because it's hosted on a different site.

NoScript checks both the embedding site and the embedded (Java) object against the whitelist to determine if it can be run.

Re:Absolutely yes

[Nazlfrag]

The applet is contained in the gif that is hosted on facebook. There is no different site. Noscript wouldn't stop it (assuming the facebook user has whitelisted facebook).

Re:Absolutely yes

[Giorgio Maone]

The tag cannot be embedded in a facebook page, it must be embedded in a 3rd party site, even if it pointing to the GIF hosted on the facebook domain. Under these conditions, NoScript still blocks it.

What the hell are you talking about?

[Anonymous Coward]

When a web server deals with image files, it transmits the contents, it doesn't parse them. This is not an attack against servers, but against other end users.

Re:What the hell are you talking about?

[Nazlfrag]

Correct. The code hidden in the image file will be executed by whatever browsers view it, not executed by the server. Even if the server does parse it, it would just be looking for a signature. It has enough similarity to fool the server into thinking its a valid GIF file, but the end users browser will render it as a JAR file (or possibly both).

Re:Another reason Java sucks

[X0563511]

There ya go! That was much better, and I almost agree with you now ;)

Better combo

[CriX]

"Jif" would be a better combo, imo. No, I didn't RTFA.

Re:Better combo

[sexconker]

Choosy moms choose Jif!

Snow Crash?

[Anonymous Coward]

Sounds familiar...

In the book, Snow Crash, a hacker causes people in their virtual world to "crash" by looking at an animation that works like an executable.

Re:Snow Crash?

[^_^x]

.TIF /.TIFF files have also been used to build exploits for the iPhone and PSP. The same library is used on so many platforms.

I know on the PSP it basically just caused a memory overflow, and about 1 in 10 times it would write the exploit code in front of the execution pointer and start running it.

I hate the Java community and their buzzwords

[dzfoo]

Of course, they have to give it a cutesy, buzzworthy name.

        -dZ.

Irony is that Java's much-hyped Applets failed

[Dogtanian]

Java is the epitome of bad programming, despite all that you can do with it. It's just a terrible implementation of a great capability. I loathe its insurgence into the mainstream.

Regardless of whether that's true or not... the irony here is that on its launch, Java's use in web browsers- via Applets- was the main thing it was hyped for to the user in the street. And it totally *failed* to achieve mainstream success in that area. Seriously, how often do you see Java applets?

Flash- which used to be a tool for creating lightweight vector-based multimedia- somehow rose to become the tool for embedded apps in web pages. The exact niche that Java was supposed- and failed- to occupy.

I wouldn't even say Flash out-competed or usurped Java Applets. By the time Flash started growing up, Applets had been around for years and had clearly failed to be the success they were supposed to be.

Re:Irony is that Java's much-hyped Applets failed

[Tony Hoyle]

Seriously, how often do you see Java applets?

Cisco SDM. It only works on Windows (it'll *run* on other platforms but none of the buttons work, and cisco are very plain that they only support IE+Windows).. makes me wonder why they bothered with an applet when an executable would have done just as well.

So much for run anywhere...

Simple solution

[ksd1337]

Just more reason not to use GIFs.

Re:Simple solution

[SilverJets]

Or turn off Java in your browser. I don't think I have come across a web site using an applet in 3 years now. If a site is using Java it's in the backend where it doesn't really affect me (ie. I wouldn't know or care if they were using Java, perl, or even Pascal back there).

Re:Simple solution

[Waccoon]

Call me a wet blanket, but should we really just turn everything off to solve problems? Java applets are like BASIC. Just because 95% of the applets out there are totally unnecessary doesn't mean all applets are useless. The same goes with Javascript. Why can't we just have a browser not run Javascript from a 3rd party server, rather than disable it entirely?

My web site uses Java applets to allow my forum members to draw pictures on an art BBS. I plan to write a Java applet with my new gallery system that will allow people to crop images into thumbnails, too, and upload stuff in a batch. That's a lot of lost functionality if people just turn Java off.

Re:JARJAR

[TaoPhoenix]

So if they combine two Java archives together, we get the other iconically ridiculed movie? Someone make a "Gifar"/JarJar YouTube mashup!

Oh, fortunately I run linux...

[Anonymous Coward]

... and can't get java to work.

Re:Another reason Java sucks

[ssintercept]

the only "tool" here is forced morality.

My personal experience suggests otherwise

[pjt33]

I've done it with cat and had zero problems unzipping it. I've also done it today with a .gif and a .jar containing an applet and had the applet run. Try it yourself.

Re:GIFAR

[konohitowa]

Jeez - if you don't understand the joke then just don't mod it. Here - I'll clue you in...

Jeet?
No, jew?

Translation...
Did you eat?
No, did you?

See how that works? Now someone please give the AC the funny mod they should have gotten to start with. This is why I browse +6 on flamebait/troll/offtopic (and -6 on insightful).

all of them should enforce consistency

[speedtux]

Both the server and the browser should check that the content and the extension are consistent. Furthermore, the server should enforce consistency on both upload and download.

Re:all of them should enforce consistency

[clone53421]

Frankly, it wouldn't really matter IF the browser would quit trying to be so "helpful". If the server says "this has a .gif extension, I'll send it using content-type: image/GIF", and if the browser would (1) require anything in an <IMG> tag to be an image and (2) require anything with a .gif extension or a content-type: image/GIF header to be opened as a .gif, this exploit wouldn't be possible: you'd just get a broken picture icon.

Re:all of them should enforce consistency

[clone53421]

As a side note, this exact same problem came up not too long ago when .asf files could be disguised as .mp3's and Windows Media Player would play them. It was a problem because .asf files are insecure.

As another example, you can take any image file that Preview will open, rename it with the extension of any other image file that Preview opens, and both Explorer and Preview will still display it... and Explorer will display no indication that it isn't what the extension says it is. It's not as dangerous as the .asf exploit, because all of the picture formats are already "safe" formats, and you can't disguise a .jar as a .gif in this case - Preview won't launch Java (I tried it), which is apparently the problem with the browser in TFA.

In short, extensions (if they are strictly followed) are a good way to avoid exploits like this. Trying to be clever/helpful by opening a file anyway when the extension is wrong is dangerous. At least Windows Media Player warns you (although it doesn't necessarily indicate that there is any particular danger in opening the file, IIRC).

Re:all of them should enforce consistency

[Schraegstrichpunkt]

What happens when the file extension is something like ".dat", ".ogg", ".xml" or one of several other extensions that are used for more than one datatype?

File extensions are a Windows-specific and Apache-specific feature that don't uniquely identify the file type and have no meaning on most platforms. What needs to happen is that both the server and the browser need to do whatever is necessary to preserve the content-type (a.k.a. MIME type) of the original file.

File extensions are an implementation-specific distraction.

so this is new ?

[Anonymous Coward]

Files masquerading as one type, then another type is nothing new at all.

Yes, the internet is broken.

So was windows media player.

Any moronic application chain that allows you to upload a *picture*, and then present it to the browser *without a picture content-type*, and any browser that *will run it* as an applet because it looks like java-code.

Wow. So, very, very broken.

Fix is obvious: write correct code in the first place...

That sounds like...

[gillbates]

An interesting way to do amateur steganography... (Think teens on MySpace posting messages in pictures...)

Misleading article. Not Java problem, but browser!

[Anonymous Coward]

The article doesn't say this explicitly, but the flaw doesn't lie in Java at all. The problem is that some browsers, most notably Internet Explorer, in some scenarios ignore the filetype as sent by the server but try to guess the filetype themselves. So there's no problem in Java's security model, nor even in that of the website. The website just serves it as an image, but then the browser says 'hm... what would happen if I were to execute this as a Java applet instead?' based on the ZIP header at the end of the file, thereby bypassing the website's security and running an untrusted applet in the context of the website. I don't see why Sun should be expected to fix this, the blame and shame lies squarely on the browser vendor's shoulders as far as I'm concerned.

Tag to disable unwanted content

[TheLink]

What would be good is what I proposed _years_ ago:

http://osdir.com/ml/mozilla.security/2002-10/msg00029.html

Then even if someone manages to slip in javascript or other html naughties into an allowed content-type=text/html that's uploaded or emailed to the site, it still won't work on the target's browser.

(if the browser supports the feature, and the website encloses all stuff that _should_ be "plain old harmless stuff" with such tags).

Basically when the browser sees such tags, it will go "Ah, between these tags, I behave as a browser with the fancy stuff disabled". So java, activeX, javascript AND _NEW_STUFF_ that people think up that slips through the upload checks would still be disabled.

That's right, even fancy new stuff that people are thinking of, could be disabled without the website having to keep up with the latest and greatest way to pwn you that the browser or w3c have decided to bless the world with.

It's been 7 years already and everyone seems to be happy to create new "foot guns" for the world but nobody seems interested in making a "foot gun safety".

Re:Tag to disable unwanted content

[clone53421]

That looks like it would work, but I don't think it should really be difficult to create "safe HTML" from user-created text/HTML.

Basically, you would have to check every <, find the matching >, and examine the middle. Maybe you allow A, IMG, STRONG, EM, B, I, BR, P, TT, and BLOCKQUOTE for example. You should determine which of those tags is being implemented, then re-generate the tag ... e.g. replace the entire < ... > in the user code with a clean hard-written tag, stripping out any parameters (except SRC in IMG tags and HREF in A tags, obviously). It pretty well cripples HTML, but the user isn't allowed to write arbitrary HTML anyway: they have to use your framework.

I can't think of any way to break that system... maybe a second brain thinking about it could come up with something, though, so feel free to try and break my "virtual parser". Just post it in HTML code using the &lt; and &gt;... =)

Re:Tag to disable unwanted content

[TheLink]

(To be clear I believe filtering should still be done, I'm saying it isn't sufficient and things are getting harder)

Your suggestion works if you don't want to allow much user/3rd party HTML.

But it's not so simple for many sites - the more tags you allow, the more likely is you are going to forget something.

For example: Say you are a popular webmail provider and you want to allow your users to receive and view html webmail, or you are one of those "social" sites and you want to allow users to do fancier html stuff, and you want to allow multibyte, UTF etc. What would your filters look like now? There are lots of ways to sneak in "dynamic stuff".

See:
http://ha.ckers.org/xss.html
http://www.symantec.com/avcenter/reference/malicious.yahooligans.pdf
http://namb.la/popular/tech.html

So if you want to allow _some_ HTML and you add stuff like multibyte/UTF and browsers behaving differently, it's not so simple to filter out the bad stuff anymore.

I think you'll see that my proposal provides an _easy_ _additional_ layer of protection.

I'm not saying don't do filtering, I'm saying we _also_ need a way to tell the browser that "between these two points behave like a dumb browser with a minimum set of features".

Browsers parse stuff differently, but if they have been told "disable javascript from now on", even if they have a buggy parsers and javascript sneaks through - it's off on the browser.

And what if the browser or W3C bunch unleash some new "HTML feature"? At least with my proposal, there's some chance of sites still being safe by default. It's not 100%, but brakes on a car aren't 100% either.

Lastly there are many other scenarios where you need to allow 3rd party HTML that you can't trust to be "safe" - e.g. ad content from partners.

I've been filtering images for years

[Waccoon]

I have an image BBS system called an Oekaki that accepts image uploads much like the channel boards do. For years, I've had a file type identifier in my code that inspects the file and makes sure it is what it's supposed to be.

Since it's a forum specifically designed for artists, I did this primarily to keep BMP files, Photoshop images, and corrupt PNG files off the board. It's effective at keeping code attacks like this from happening, though.

Turning off Java is a bit of a problem, because Oekaki involves using a Java applet to draw pictures. Perhaps web developers should simply apply the principle of filtering everything that is uploaded. It's not that hard to check image headers and the position of end markers, since (unlike many text formats) today's bitmap image formats still have proper binary headers.

I'm not looking forward to the day when image formats use markup instead of binary headers. There's a lot of opportunity for bad things to hide in there, as any web developer who has had to deal with XSS attacks and intrusive banner ads can tell you.

Kittens are not safe.

[Anonymous Coward]

I believe the way it works is the front of the file is a valid image, and the exploit is hidden at the tail end of the GIF. So you would see a picture, AND run the code.

Does happen with those avatars in Wordpress

[gatorgse]

Wordpress has some themes where when people comment, their web avatar can be used next to their comment. Is this a liability as well? If so, what would be the fix? Thanks,

Re:GIFAR

[Anonymous Coward]

But it just isn't very funny.

Specific to GIF?

[camg188]

The article wasn't clear if this was something specific to the GIF format. Could it be used with PNG, the supposed GIF replacement?
The article implies that the GIF/JAR file has to be from the site you are logged into. Could it come from a third party ad hosted by the site? If not, then servers that upload image files could just convert the images to some standard format (png,jpeg) before serving them out again.

Re:GIFAR

[konohitowa]

That may be true. But not being funny doesn't make it flamebait.

Gifar = Gefahr = Danger in german

[cowbud]

Clever

Using "magic" is what causes this.

[Schraegstrichpunkt]

The server obviously doesn't do a magic check or it would see that it's an applet.

A "magic check" is probably the problem in the first place. GIF files typically start with the string "GIF89a", and have nothing consistent at the end. JAR files (which are ZIP files) aren't required to have anything special at the beginning, but instead have their "signature" near the end of the file (this allows stuff like self-extracting archives to work).

So, your "magic" file could have two different entries:

• Any file starting with "GIF89a" is a GIF file
• Any file ending with a ZIP signature is a ZIP file

Depending on the order that these tests are performed, you'll get different results. Where the same file can be interpreted different ways, there is an avenue for attack.

The UTF-7 autodetection bug caused the same kind of problem. If the past couple of years have taught us anything, it's that we need to preserve datatypes along with the data itself, rather than trying to autodetect it later.

Re:JARJAR

[paulgrant]

lord this is prolly just a rar/zip[ file renamed to .gif with the magic cookie in it - u're browser a views an uncompressed (compressed) file (a gif) and runs a browser viewer

Jeez, how many more reasons

[al0ha]

do people need to get them to NEVER enable Java by default in the browser?

This has been true for years and continues to be true regardless of code-signing or sandbox techniques.