Not long after Firefox 3.5.1 was released to address a security issue, a new exploit has been found and a proof of concept has been posted. "The vulnerability is a remote stack-based buffer-overflow, triggered by sending an overly long string of Unicode data to the document.write method. If exploited, the resulting overflow could lead to code execution, or if the exploit attempts fail, a denial-of-service scenario." It's recommended that Firefox users disable Javascript until the issue is patched, though add-ons like NoScript should do the trick as well (unless a site on your whitelist becomes compromised).
Update: 07/20 00:09 GMT by KD: An anonymous reader informs us that the Mozilla security blog is indicating that this vulnerability is not exploitable; denial of service is as bad as it gets.
Well, seeing as the bug was found in the Just-in-Time compiler (first link), probably someone who is concerned that the section of the code that they are working on will become a bottle neck, or someone that has to do special stuff that requires unbounded buffers.
This is another, different bug than the one talked about in the first link. None of the other links specify whether this second bug is from the JIT or not.
Yeah, and half the websites out there will stop rendering then. Sadly, the vast majority of them don't need javascript to do their job, but such is the epic lame that is the average web programmer.
Or maybe most web programmers don't want to spend a lot of time and money supporting the 1% of users out there that don't have or disable JavaScript.
Wouldn't avoiding javascript make webpages smaller & therefore load faster? Perhaps you've got a megawide connection, but when I'm traveling all I have is 50k dialup. Even at home I'm limited to a relatively slow 700k. I'd prefer a web that's mainly text and images without the bloat.
Back in the 90s web programmers were taught to optimize and compress their pages as small as possible. It appears this lesson is no longer being taught in the schools.
Wouldn't avoiding javascript make webpages smaller & therefore load faster?
Nope. To the contrary, a well-designed AJAX page that dynamically reloads sections instead of the entire page can potentially be much faster. Take the example of registering for a site account. Old way:
User enters a username, submits the form.
That username is taken, so the server sends back the whole page plus the error message.
New way:
User enters a username, clicks or tabs to the next field.
Their browser sends a validation request via AJAX.
That username is taken, so the server sends back the error message.
The client displays the error message and returns focus to the username field.
Alternatively, look at Slashdot itself. Yeah, it has its issues, but I have to say that I love the dynamic content loading. That's so much better (and easier on bandwidth!) than having to load a whole page just to expose a collapsed comment.
You left off step 0 - the server sends over a ton of javascript code that would not be transfered in the non-javascript case. Since neither case requires the retransfer of any of the images, it is easy enough for your example to go either way based on just how much extra javascript gets transferred.
Furthermore, way too many sites have external javascript dependencies, like doubleclick, coremetrics, etc. By ignoring those we are pretty much guaranteed a faster experience.
Alternatively, look at Slashdot itself. Yeah, it has its issues, but I have to say that I love the dynamic content loading. That's so much better (and easier on bandwidth!) than having to load a whole page just to expose a collapsed comment.
I feel Javascript is an important technology and rather than fucking around with all the proprietary crap like Flash we should be strengthening Javascript so it's more secure and more useful, in fact, a lot of browser vendors seem to be doing this, and those Chrome demos posted a few months back were agood example.
But I also think it's silly to assume and design for Javascript unless Javascript is the whole point of your site. There's so many sites out there that use Javascript for things like drop down menus and sometimes even positioning where CSS would suffice and not require Javascript support it's silly. To turn away 1 in 20 users doesn't seem the brightest idea unless you're building a web application where absolutely the only way to do what you want to do is to use Javascript.
Javascript shouldn't be a requirement for the vast majority of the web, only for those sites that truly need it.
But I also think it's silly to assume and design for Javascript
According to 95% [w3schools.com] of users have JS on. There's no reason to essentially design two separate sites to support the other 5%. And it could be argued that that 5% could either easily turn it back on if they choose (in which case, they're the lazy one), or is using something really really old and has no need to, or doesn't want to.
I'm not a web developer, but it seems obvious to me that while it's possible and often sensible to include the other 5% (which may include spiders, which you typically want), ignoring t
I've disabled it today and some sites are now really much faster than usually.
I guess I really need to invest into configuring noscript.
NoScript + Adblock Plus + Adblock Plus Element Hiding Helper + the Easylist and EasyElement subscriptions for ABP = the Web as it was meant to be.
Advertising business models and entitlement mentalities (regarding ad revenue) be damned. If a Webmaster somewhere does not like that my computer is my property and will load only what I want it to load up, I recognize that their site is their property and I celebrate their right to deny me access to their site so I can find another.
I don't know anything about JavaScript or Firefox internals, but a public sounding central function call like "DOCUMENT.WRITE" having a length related buffer overflow is just unacceptable. This call is used all the time right? How could this be missed?
This is my feeling as well. FYI: document.write is the JavaScript equivalent of write(2). It is used liberally in modern web content; I doubt there are any popular contemporary pages that don't use it.
This code path should be impervious to any overflow exploit that might conceivably appear. Obviously document.write can and is used to exploit other more subtle flaws in a browser as it is capable of producing arbitrary document content, but that's not what we have here. Here we have long strings breaking
It's not a buffer overflow. It's a missing OOM check leading to a non-exploitable (well, if your kernel is sane; some Linux versions are not) null-dereference crash.
Note also that the article linked to is misreporting this in other ways as well; unfortunately I'm not at liberty to go into details on that yet.:(
1) The crash is not exploitable, for anyone who's been able to reproduce it so far. 2) The crash is in system text-rendering libraries (which apparently don't check for
out-of-memory much), not in Firefox code, for everyone who's been able to
reproduce it so far.
Let's just hope that all those eyes are friendly. How many black hats are scouring the source code to generate exploits to sell underground? As quickly as Firefox releases patches, when these bugs aren't reported it's no better than a proprietary browser.
Let's just hope that all those eyes are friendly. How many black hats are scouring the source code to generate exploits to sell underground? As quickly as Firefox releases patches, when these bugs aren't reported it's no better than a proprietary browser.
Except that other people are a lot more likely to find the same bug, and report it regardless of the black hats.
After all, FF is open during development, not just after release. 3.5 has been a long time in coming, the code has been out there for lots to see and lots have looked, yet this was missed.
The thing is, open or closed, any major project has a lot of people looking at the code, and at least some of those people, perhaps most, are highly skilled. What this means is that it isn't likely there's an extremely obvious bug in the code. It isn't the sort of thing that someone would look at the source and go "Oh look
by Anonymous Coward
on Sunday July 19, @12:30PM (#28748615)
It looks like the proof of concept only shows how this could lead to a stack overflow. There is no concept about how this could lead to code execution, which makes this just just another way to crash a browser. Crashing browsers is of course potentially a problem, but it quite boring while there are still so many ways to do real exploits.
> It looks like the proof of concept only shows how this could lead to a stack overflow
It actually doesn't even show that, if you try running it under a debugger... It shows a null dereference due to lack of out-of-memory check on an allocation.
I tried this using greasemonkey and wanted to thank you for it, but I had to switch to Internet Explorer to post the reply as for some reason Slashdot started bringing up a million alert boxes.
.. as the horrible language that is JavaScript is extended ever more to try and emulate real desktop applications (and more pervasive advertising).
Mang, sometimes I wish I could still get by with a browser that doesn't support JS at all, but web devs insist on building websites that absolutely require JS. For example the free SMS service for my mobile phone network (Meteor) absolutely won't work with JS disabled.
Whoever modded the parent as troll is a moron. Offtopic maybe, but not troll. Go ahead and mod me down too.
The parent is right. I've had my paranoid period and tried NoScript; the web was so damn broken, and clicking to allow JS over and over again turned so tiresome that I turned to everything whitelisted by default, and finally uninstalled NoScript after the AdBlock fiasco.
About how bad of a language JavaScript is or isn't: I personally like it, though I'd prefer Lua, or say, Python; but JS is here to stay and it serves its purpose. Except that purpose isn't replacing HTML, or turning HTTP into something it was never meant to be. Back when I was coding JS, we were doing it to improve the user experience, not replace it altogether. Nowadays "web developers" use [insert random JS framework] for everything, but the problem is so, so many use it in braindead ways. You middle click on a thumbnail expecting to open the image in a new tab, but you just get the same page with a nice # added at the end. And then there's the idiots doing <a href="javascript:">, and the utter idiots with an attitude that do onclick="submit_something_via_post" and figure out they know better how the web is supposed to work... These are usually the same idiots that will do broken browser detection based on the User-Agent string, and usually fail miserably if your browser sends along "Gecko", but not "Firefox". Say, something like "Iceweasel". For a nice example of how far this stupidity goes, try browsing VIA's site.
You want to use XHR when clicking on a link? Or submitting a form? That's all fine and dandy, but don't break the web. It's becoming more and more like flash, with the sole difference you can view-source.
If you're building Google Docs or Meebo, all hail JavaScript. But for mostly everything else, lack of graceful degradation with JS disabled is pure idiocy. Not just because there's paranoid people browsing with JS disabled, but because there's blind people using the web, and people with antiquated handhelds, or simply stuck in a console trying to fix nvidia's latest fuck-up. Of course, it would take building the site / web app properly from the bottom up: HTML, server interaction, CSS, JavaScript. But the "developers" these day start with YUI or Dojo: some shiny animation is the end purpose in on itself, not an improvement to conveying information.
By the way: did you try GMail with JS disabled? It works. It probably works in lynx too, since it works in elinks just fine. That's the way JS is supposed to be used.
The proof of concept has crashed every browser I've tried it on; Firefox (obviously) (and the 3.6 nightly), Epiphany, Chromium, Opera and Android Browser. So is Firefox the only browser that is exploitable during the crash or other browsers affected?
Well, the fact that SANS is blindly reposting known-unreliable things like milw0rm postins is something of an event, to me... Forgetting the fact that it tarnishes the reputations of whatever software they falsely accuse of being vulnerable, it leads to SANS being less reliable and less trusted. The whole crying wolf thing.
But yeah, I agree that this "exploit" is nothing of the kind.
by Anonymous Coward
on Sunday July 19, @12:43PM (#28748693)
These recurring requests to turn off something are getting annoying. Why not automate the process? Set up a page somewhere like www.mozilla.com/firefox/3.5.1/current-safety.txt
which would list something like javascript: unsafe java: safe flash: safe
Then by default your browser would fetch that file and automatically implement Mozilla's recommendation of the day.
To say, for the contemporary web, "turn off javascript", is to say, "break everything". If I can't safely use the browser with Javascript, I can't safely use the browser.
This is the reason why I avoid crappy software like Firefox and stick to MSIE! Firefox is riddled with bad, bloated code making it easily subjectable to these types of attacks. On top of that, the development model allows mistakes like this to get into the codebase without proper quality assurance.
See what Mozilla has to say:
http://blog.mozilla.com/security/2009/07/19/milw0rm-9158-stack-overflow-crash-not-exploitable-cve-2009-2479/ [mozilla.com]
In the last few days, there have been several reports (including one via SANS) of a bug in Firefox related to handling of certain very long Unicode strings. While these strings can result in crashes of some versions of Firefox, the reports by press and various security agencies have incorrectly indicated that this is an exploitable bug. Our analysis indicates that it is not, and we have seen no example of exploitability.
On Windows, Firefox 3.0.x is terminated due to an uncaught exception during an attempt to allocate a very large string buffer; this termination is safe and immediate, and does not permit the execution of attacker code. In Firefox 3.5.x on Windows, the allocations are more robustly checked and no crash will result.
On the Macintosh in Firefox 3.0.x and 3.5.x, a crash occurs inside the ATSUI system library (part of OS X), due to what appears to be a failure to check allocation results. This issue is likely to affect any application using the recommended text-handling libraries on OS X. We have reported this issue to Apple, but in the event that they do not provide a fix we will look to implement mitigations in Mozilla code. We recommend that other developers who use these libraries consider a similar practice, and we have added mitigations in the past for similar bugs in these libraries.
As a result of our analysis, we do not believe that this represents an exploitable vulnerability in Firefox. Further, we believe that the IBM report is in error, and that the severity rating in the National Vulnerability Database report is incorrect. We have contacted them and hope to resolve the inaccuracies shortly.
Is this a new copy-and-paste troll? Almost the same post [slashdot.org] appeared in the Linux kernel exploit article. Apparently some people missed the Defective by Design campaign and are completely unaware that it relates to DRM, not to arbitrary bugs.
Some stories tagged "defectivebydesign" that are not at all related to DRM:
"Critical Security Hole in Linux Wi-Fi" "Apple Issues Patches For 25 Security Holes" ""Very Severe Hole" In Vista UAC Design" "MS Responds To Vista's Network / Audio Problems" "Apple's IPhone 3G Firmware Update Bombs" "QuickTime.MOV + Toshiba + Vista = BSOD" "Vista Slow To Copy, Delete Files" "Vista Runs Out of Memory While Copying Files" "Mark Russinovich On Vista Network Slowdown" "Microsoft Knew About Xbox 360 Damaging Discs" "Vista Not Playing Nice With FPS Games"
That's as far as I can be bothered to read. Go look at it yourself. That tag is cheerfully applied to many, many stories about Windows or Apple bugs.
Apparently some people missed the Defective by Design campaign and are completely unaware that it relates to DRM, not to arbitrary bugs.
The primary difference being that bugs like this Firefox flaw are accidental and unintentional, whereas DRM is quite deliberate hence the "defective by design" nomenclature. That's such a sharp contrast, it's reasonable to assume that someone who fails to notice it is either speaking of what they know nothing about or purposely trolling. In other words, "highly advanced incompetence is indistinguishable from malice."
There were two ideas mentioned by GP, which were the "defective by design" label and the security reputation of IE. It's useful to know where those perceptions come from whether or not you actually agree with them. I'll make a very simplified (and therefore imperfect) summary of what I perceive as their bases.
The only reason why I see such a concept as "defective by design" applied to IE is a vague one. IE (and Microsoft in general) has something of a history of implementing ideas that were predictably unsound, the most notorious of which is probably ActiveX. That's mostly because ideas which are computationally sound are often orthogonal to ideas which are most easily marketed. True to the nature of a corporation, whenever these two are in conflict, the marketing concerns will win. This is where that perception of closed-source (that is, commercial) software that the GP mentioned comes from.
ActiveX is running untrusted code from a hostile network with no sandboxing and with the full privileges of the user running the browser. Before a single line of code is ever written to implement this, you can predict in advance that this is an unsound idea which invites trouble. Microsoft wrote the code and implemented the idea anyway. IMO that was a deliberate business decision because they felt the marketing and promotion of $SHINY_FEATURE would gain them more than they would lose from the PR problems of security issues. Because of how ignorant the general public tends to be about computer security, such decision-making has been largely successful. In other words, the people at Microsoft are not a bunch of idiots who didn't know what they were dealing with. They knew and they made their decision. Still, it's better to call that "faulty design" and "poor priorities" than to hijack a very specific term like "defective by design."
So because Firefox was open when it crashed, Firefox must have caused it? Couldn't be that because most people have their browser open 99% of the time chances are that it will be open when something goes wrong?
Have you tried the POC? Ideally under a debugger? It's a null-dereference crash due to failure to check an allocation for out-of-memory conditions. It's not exploitable, as far as I can see. And it's not a stack buffer overflow, by any means.
It'd be nice if these various security advisory services actually double-checked milw0rm postings before echoing them. Half the ones I've seen are in fact crashes, but not the sort the poster claims and not exploitable....
The bug is in the Just-in-Time compiler inside of SpiderMonkey (TraceMonkey). This is brand new code as of 3.5.x. Of course there will be a ton of bugs found in it (just like the ton of bugs that have cropped up in SquirrelFish and have been subsequently patched).
I have to wonder why it's taken so long for anybody's security team to look at this code though. You'd think they'd look at this code before release and not after.
Unbounded (Score:5, Funny)
So who's the moron using unbounded buffers?
Re:Unbounded (Score:4, Interesting)
Parent
Re:Unbounded (Score:5, Informative)
This is another, different bug than the one talked about in the first link. None of the other links specify whether this second bug is from the JIT or not.
Parent
Re:Unbounded (Score:5, Funny)
What are six words you never, ever want to hear?
"I have a headache tonight, dear"
Parent
Re:Unbounded (Score:4, Funny)
"wow, its so small and cute"
Parent
Re:Unbounded (Score:5, Funny)
Parent
A: Firefox users (Score:4, Funny)
If you use firefox, then you are the moron using unbounded buffers.
Parent
Re:Unbounded (Score:5, Funny)
I am shocked, shocked, to find unbounded buffer use in this open-source application.
--
Toro
Parent
Re:Unbounded (Score:4, Funny)
Again? That was my first reply, and it's a joke referencing Casablanca. I can format it the other way, if you like:
I am shocked, shocked, to find half-baked misinformation on this Slashdot web-forum.
Your reply is a meme syntax error: Response Out Of Range: !Sense of Humor ;^)
--
Toro
Parent
Turn off javascript... (Score:5, Insightful)
... and stop using all of your web-apps... sigh...
Re:Turn off javascript... (Score:5, Insightful)
Yeah, and half the websites out there will stop rendering then. Sadly, the vast majority of them don't need javascript to do their job, but such is the epic lame that is the average web programmer.
Or maybe most web programmers don't want to spend a lot of time and money supporting the 1% of users out there that don't have or disable JavaScript.
I'm just sayin'.
Parent
Re:Turn off javascript... (Score:4, Insightful)
Wouldn't avoiding javascript make webpages smaller & therefore load faster? Perhaps you've got a megawide connection, but when I'm traveling all I have is 50k dialup. Even at home I'm limited to a relatively slow 700k. I'd prefer a web that's mainly text and images without the bloat.
Back in the 90s web programmers were taught to optimize and compress their pages as small as possible. It appears this lesson is no longer being taught in the schools.
Parent
Re:Turn off javascript... (Score:5, Interesting)
Wouldn't avoiding javascript make webpages smaller & therefore load faster?
Nope. To the contrary, a well-designed AJAX page that dynamically reloads sections instead of the entire page can potentially be much faster. Take the example of registering for a site account. Old way:
New way:
Alternatively, look at Slashdot itself. Yeah, it has its issues, but I have to say that I love the dynamic content loading. That's so much better (and easier on bandwidth!) than having to load a whole page just to expose a collapsed comment.
Parent
Re: (Score:3, Insightful)
New way:
You left off step 0 - the server sends over a ton of javascript code that would not be transfered in the non-javascript case. Since neither case requires the retransfer of any of the images, it is easy enough for your example to go either way based on just how much extra javascript gets transferred.
Furthermore, way too many sites have external javascript dependencies, like doubleclick, coremetrics, etc. By ignoring those we are pretty much guaranteed a faster experience.
Alternatively, look at Slashdot itself. Yeah, it has its issues, but I have to say that I love the dynamic content loading. That's so much better (and easier on bandwidth!) than having to load a whole page just to expose a collapsed comment.
Well, we are going to have agree to
Re:Turn off javascript... (Score:5, Informative)
Looking at W3Schools stats on it it's about 5%. I've seen some stats suggest as high as 16% around 3 years ago:
http://www.w3schools.com/browsers/browsers_stats.asp [w3schools.com]
I feel Javascript is an important technology and rather than fucking around with all the proprietary crap like Flash we should be strengthening Javascript so it's more secure and more useful, in fact, a lot of browser vendors seem to be doing this, and those Chrome demos posted a few months back were agood example.
But I also think it's silly to assume and design for Javascript unless Javascript is the whole point of your site. There's so many sites out there that use Javascript for things like drop down menus and sometimes even positioning where CSS would suffice and not require Javascript support it's silly. To turn away 1 in 20 users doesn't seem the brightest idea unless you're building a web application where absolutely the only way to do what you want to do is to use Javascript.
Javascript shouldn't be a requirement for the vast majority of the web, only for those sites that truly need it.
Parent
Re: (Score:3, Interesting)
But I also think it's silly to assume and design for Javascript
According to 95% [w3schools.com] of users have JS on. There's no reason to essentially design two separate sites to support the other 5%. And it could be argued that that 5% could either easily turn it back on if they choose (in which case, they're the lazy one), or is using something really really old and has no need to, or doesn't want to.
I'm not a web developer, but it seems obvious to me that while it's possible and often sensible to include the other 5% (which may include spiders, which you typically want), ignoring t
Re:Turn off javascript... (Score:5, Insightful)
I've disabled it today and some sites are now really much faster than usually.
I guess I really need to invest into configuring noscript.
NoScript + Adblock Plus + Adblock Plus Element Hiding Helper + the Easylist and EasyElement subscriptions for ABP = the Web as it was meant to be.
Advertising business models and entitlement mentalities (regarding ad revenue) be damned. If a Webmaster somewhere does not like that my computer is my property and will load only what I want it to load up, I recognize that their site is their property and I celebrate their right to deny me access to their site so I can find another.
Parent
You can't be serious! (Score:4, Insightful)
I don't know anything about JavaScript or Firefox internals, but a public sounding central function call like "DOCUMENT.WRITE" having a length related buffer overflow is just unacceptable. This call is used all the time right? How could this be missed?
Re: (Score:3, Insightful)
This is my feeling as well. FYI: document.write is the JavaScript equivalent of write(2). It is used liberally in modern web content; I doubt there are any popular contemporary pages that don't use it.
This code path should be impervious to any overflow exploit that might conceivably appear. Obviously document.write can and is used to exploit other more subtle flaws in a browser as it is capable of producing arbitrary document content, but that's not what we have here. Here we have long strings breaking
Re:You can't be serious! (Score:5, Informative)
It's not a buffer overflow. It's a missing OOM check leading to a non-exploitable (well, if your kernel is sane; some Linux versions are not) null-dereference crash.
Note also that the article linked to is misreporting this in other ways as well; unfortunately I'm not at liberty to go into details on that yet. :(
Parent
Re:You can't be serious! (Score:5, Informative)
Ok, here's the full deal:
1) The crash is not exploitable, for anyone who's been able to reproduce it so far.
2) The crash is in system text-rendering libraries (which apparently don't check for
out-of-memory much), not in Firefox code, for everyone who's been able to
reproduce it so far.
Parent
Many eyes makes for secure code (Score:4, Insightful)
Let's just hope that all those eyes are friendly. How many black hats are scouring the source code to generate exploits to sell underground? As quickly as Firefox releases patches, when these bugs aren't reported it's no better than a proprietary browser.
Re: (Score:3, Interesting)
Let's just hope that all those eyes are friendly. How many black hats are scouring the source code to generate exploits to sell underground? As quickly as Firefox releases patches, when these bugs aren't reported it's no better than a proprietary browser.
Except that other people are a lot more likely to find the same bug, and report it regardless of the black hats.
The code may not be that relevant (Score:3, Interesting)
After all, FF is open during development, not just after release. 3.5 has been a long time in coming, the code has been out there for lots to see and lots have looked, yet this was missed.
The thing is, open or closed, any major project has a lot of people looking at the code, and at least some of those people, perhaps most, are highly skilled. What this means is that it isn't likely there's an extremely obvious bug in the code. It isn't the sort of thing that someone would look at the source and go "Oh look
failed proof of concept (Score:3, Informative)
It looks like the proof of concept only shows how this could lead to a stack overflow. There is no concept about how this could lead to code execution, which makes this just just another way to crash a browser.
Crashing browsers is of course potentially a problem, but it quite boring while there are still so many ways to do real exploits.
Re:failed proof of concept (Score:4, Informative)
> It looks like the proof of concept only shows how this could lead to a stack overflow
It actually doesn't even show that, if you try running it under a debugger... It shows a null dereference due to lack of out-of-memory check on an allocation.
Parent
fix: (Score:5, Funny)
Re:fix: (Score:5, Funny)
I tried this using greasemonkey and wanted to thank you for it, but I had to switch to Internet Explorer to post the reply as for some reason Slashdot started bringing up a million alert boxes.
Parent
Expect to see much more of this in the future.. (Score:3, Insightful)
Mang, sometimes I wish I could still get by with a browser that doesn't support JS at all, but web devs insist on building websites that absolutely require JS. For example the free SMS service for my mobile phone network (Meteor) absolutely won't work with JS disabled.
Re:Expect to see much more of this in the future.. (Score:4, Insightful)
Whoever modded the parent as troll is a moron. Offtopic maybe, but not troll. Go ahead and mod me down too.
The parent is right. I've had my paranoid period and tried NoScript; the web was so damn broken, and clicking to allow JS over and over again turned so tiresome that I turned to everything whitelisted by default, and finally uninstalled NoScript after the AdBlock fiasco.
About how bad of a language JavaScript is or isn't: I personally like it, though I'd prefer Lua, or say, Python; but JS is here to stay and it serves its purpose. Except that purpose isn't replacing HTML, or turning HTTP into something it was never meant to be. Back when I was coding JS, we were doing it to improve the user experience, not replace it altogether. Nowadays "web developers" use [insert random JS framework] for everything, but the problem is so, so many use it in braindead ways. You middle click on a thumbnail expecting to open the image in a new tab, but you just get the same page with a nice # added at the end. And then there's the idiots doing <a href="javascript:">, and the utter idiots with an attitude that do onclick="submit_something_via_post" and figure out they know better how the web is supposed to work... These are usually the same idiots that will do broken browser detection based on the User-Agent string, and usually fail miserably if your browser sends along "Gecko", but not "Firefox". Say, something like "Iceweasel". For a nice example of how far this stupidity goes, try browsing VIA's site.
You want to use XHR when clicking on a link? Or submitting a form? That's all fine and dandy, but don't break the web. It's becoming more and more like flash, with the sole difference you can view-source.
If you're building Google Docs or Meebo, all hail JavaScript. But for mostly everything else, lack of graceful degradation with JS disabled is pure idiocy. Not just because there's paranoid people browsing with JS disabled, but because there's blind people using the web, and people with antiquated handhelds, or simply stuck in a console trying to fix nvidia's latest fuck-up. Of course, it would take building the site / web app properly from the bottom up: HTML, server interaction, CSS, JavaScript. But the "developers" these day start with YUI or Dojo: some shiny animation is the end purpose in on itself, not an improvement to conveying information.
By the way: did you try GMail with JS disabled? It works. It probably works in lynx too, since it works in elinks just fine. That's the way JS is supposed to be used.
</rant>
Parent
Not just Firefox? (Score:5, Informative)
Re:Not just Firefox? (Score:4, Informative)
When I tried this, I see Firefox crashing with a null dereference. So not exploitable.
Do you see something different?
Parent
Re: (Score:3, Informative)
Well, the fact that SANS is blindly reposting known-unreliable things like milw0rm postins is something of an event, to me... Forgetting the fact that it tarnishes the reputations of whatever software they falsely accuse of being vulnerable, it leads to SANS being less reliable and less trusted. The whole crying wolf thing.
But yeah, I agree that this "exploit" is nothing of the kind.
Re: (Score:3, Interesting)
It crashes FF 3.5.1 and Safari 4.0.2 for me, but not Chrome 2.0.172.37 or IE 8.
automate protection (Score:4, Interesting)
These recurring requests to turn off something are getting annoying. Why not automate the process? Set up a page somewhere like
www.mozilla.com/firefox/3.5.1/current-safety.txt
which would list something like
javascript: unsafe
java: safe
flash: safe
Then by default your browser would fetch that file and automatically implement Mozilla's recommendation of the day.
No Javascript? No Firefox. (Score:3, Informative)
To say, for the contemporary web, "turn off javascript", is to say, "break everything". If I can't safely use the browser with Javascript, I can't safely use the browser.
Firefox sucks (Score:5, Funny)
This is the reason why I avoid crappy software like Firefox and stick to MSIE! Firefox is riddled with bad, bloated code making it easily subjectable to these types of attacks. On top of that, the development model allows mistakes like this to get into the codebase without proper quality assurance.
If I have to /sarcasm, I will kill you.
Firefox Vulnerability (Score:3, Funny)
But, but, but, that's unpossible!
not exploitable (Score:5, Informative)
Re:Defective by design (Score:5, Interesting)
Parent
Re: (Score:3)
It's safe to say that the meme has been co-opted. It seems to pop up in a fair number of articles these days.
Re:Defective by design (Score:5, Insightful)
http://slashdot.org/tags/defectivebydesign [slashdot.org]
Some stories tagged "defectivebydesign" that are not at all related to DRM:
"Critical Security Hole in Linux Wi-Fi" .MOV + Toshiba + Vista = BSOD"
"Apple Issues Patches For 25 Security Holes"
""Very Severe Hole" In Vista UAC Design"
"MS Responds To Vista's Network / Audio Problems"
"Apple's IPhone 3G Firmware Update Bombs"
"QuickTime
"Vista Slow To Copy, Delete Files"
"Vista Runs Out of Memory While Copying Files"
"Mark Russinovich On Vista Network Slowdown"
"Microsoft Knew About Xbox 360 Damaging Discs"
"Vista Not Playing Nice With FPS Games"
That's as far as I can be bothered to read. Go look at it yourself. That tag is cheerfully applied to many, many stories about Windows or Apple bugs.
Parent
Re:Defective by design (Score:5, Insightful)
A simple heuristic: if you can submit a well-written bug report and at least an attempt is made to fix the issue, it's probably not a design flaw.
Parent
Re:Defective by design (Score:5, Insightful)
The primary difference being that bugs like this Firefox flaw are accidental and unintentional, whereas DRM is quite deliberate hence the "defective by design" nomenclature. That's such a sharp contrast, it's reasonable to assume that someone who fails to notice it is either speaking of what they know nothing about or purposely trolling. In other words, "highly advanced incompetence is indistinguishable from malice."
There were two ideas mentioned by GP, which were the "defective by design" label and the security reputation of IE. It's useful to know where those perceptions come from whether or not you actually agree with them. I'll make a very simplified (and therefore imperfect) summary of what I perceive as their bases.
The only reason why I see such a concept as "defective by design" applied to IE is a vague one. IE (and Microsoft in general) has something of a history of implementing ideas that were predictably unsound, the most notorious of which is probably ActiveX. That's mostly because ideas which are computationally sound are often orthogonal to ideas which are most easily marketed. True to the nature of a corporation, whenever these two are in conflict, the marketing concerns will win. This is where that perception of closed-source (that is, commercial) software that the GP mentioned comes from.
ActiveX is running untrusted code from a hostile network with no sandboxing and with the full privileges of the user running the browser. Before a single line of code is ever written to implement this, you can predict in advance that this is an unsound idea which invites trouble. Microsoft wrote the code and implemented the idea anyway. IMO that was a deliberate business decision because they felt the marketing and promotion of $SHINY_FEATURE would gain them more than they would lose from the PR problems of security issues. Because of how ignorant the general public tends to be about computer security, such decision-making has been largely successful. In other words, the people at Microsoft are not a bunch of idiots who didn't know what they were dealing with. They knew and they made their decision. Still, it's better to call that "faulty design" and "poor priorities" than to hijack a very specific term like "defective by design."
Parent
Re:Just patch it and let's move on. (Score:4, Insightful)
FTFA: The vulnerability was reported to SecurityFocus (BID 35707) on July 15.
4 days > 24 hours.
Parent
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
Re:That's notthe first time (Score:5, Informative)
Have you tried the POC? Ideally under a debugger? It's a null-dereference crash due to failure to check an allocation for out-of-memory conditions. It's not exploitable, as far as I can see. And it's not a stack buffer overflow, by any means.
It'd be nice if these various security advisory services actually double-checked milw0rm postings before echoing them. Half the ones I've seen are in fact crashes, but not the sort the poster claims and not exploitable....
Parent
Re: (Score:3, Informative)
Worse POC evar
-----
<html>
<head>
<script language="JavaScript" type="Text/Javascript">
var str = unescape("%u4141%u4141");
var str2 = unescape("%u0000%u0000");
var finalstr2 = mul8(str2, 49000000);
var finalstr = mul8(str, 21000000);
document.write(finalstr2);
document.write(finalstr);
function mul8 (str, num) {
var i = Math.ceil(Math.log(num) / Math.LN2),
res = str;
do {
res += res;
} while (0 < --i);
return res.slice(0, str.
Re:That's notthe first time (Score:4, Interesting)
Fix once, fix forever
The bug is in the Just-in-Time compiler inside of SpiderMonkey (TraceMonkey). This is brand new code as of 3.5.x. Of course there will be a ton of bugs found in it (just like the ton of bugs that have cropped up in SquirrelFish and have been subsequently patched).
I have to wonder why it's taken so long for anybody's security team to look at this code though. You'd think they'd look at this code before release and not after.
Parent