Uh... All think tanks, by and large, have no agenda other than shaping political discourse. The vast majority are intellectually dishonest. This is true whether you label them "conservative" or "liberal".
Now it may be that in some cases you feel that the ends justify such means. That's a separate issue. But let's not pretend that think tanks are anything other than tools for policy creation by unelected folks of all sorts. Sadly, that's the only kind of policy creation we have nowadays.
Of course, there are also all sorts of non-think-tank organizations whose only purpose is to shape political discourse (Greenpeace comes to mind, though there are others that are less extreme). So I'm not even sure why you're picking on think tanks...
40 years? See end of http://www.thenation.com/doc/20000320/kitman/3 and beginning of http://www.thenation.com/doc/20000320/kitman/4 for some background on why we ended up with leaded gasoline to start with: it's because back in 1918-1921 there was a strong push to make gasoline more competitive with ethanol in high-compression engines so as to keep being able to sell gasoline as car fuel....
Well, hold on. You said 3.5.2 has "horrible JavaScript rendering". Presumably some other browsers don't. If so, that needs to be investigated; there's a good chance that this is a bug in Gecko or at least something Gecko can work around.
Hard to do that without specific steps to reproduce the issue, though.
> I have ver 3.52 and it takes forever to startup.
In that case, the random number thing is not your problem.
Is startup still slow in safe mode? If not, can you pin down which extension or combination of extensions is contributing? If it's still slow in safe mode, please file a bug with whatever details you can come up with.... Might also be testing with a new profile; if _that_ is fast while the old profile is slow then it could be an issue in the Places code or something; useful information for that bug that you'll file.
Please feel free to cc me (":bz" in Mozilla's Bugzilla) on any bugs you file. I'll make sure they land in the right place.
Because both browsers and various websites have spent years telling users "lock == secure". So they need to either make it very clear that in this case the site really is not as secure as the "normal" secure case, or need to not show the lock.
That's the other obvious option: show no SSL-related UI for self-signed certs. Treat them exactly like http:/// connections UI-wise. That would have to include showing "http://" instead of "https://" in the url bar, since users have been trained to look for that too.
> SVG doesn't have timer support, its scripting language does, which is open.
I have no idea what "open" means in this case. SVG 1.2 Tiny support would presumably include support for the SVG 1.2 uDOM (that's the only profile of SVG 1.2 Tiny defined section 1.2.1 of the SVG 1.2 Tiny specification) which includes the things I listed in my comment. The uDOM is a language-independent interface specification; there is no "SVG scripting language".
Are you quite sure you've read the SVG 1.2 Tiny specification?
> I was going to go one
One what?
> your post translates into 'Firefox support for SVG is absolutely ass-tastic'
Firefox support for SVG 1.1 Full is sorta-ok (not great, by any means).
Support for SVG 1.2 Tiny is an explicit non-goal for every single browser implementor, because of the issues I mentioned. Given that when the browser implementors raised precisely these concerns during the standardization process the SVG Working Group basically told them that they weren't meant to implement this specification, I'm not sure why you're suddenly demanding that they do.
Now SVG 1.2 Full, which is being worked on, is a very different beastie. We'll see how it works out. It's probably a few years from being in CR (and hence call for implementations) at this point.
Is this the part where one should comment about how the 17" MacBook Pro is 6.6 pounds?
If you really need the 17" screen, and move around a lot with it, that makes it very very worthwhile. Of course there's the slight price point problem.
Canvas is an immediate-mode graphics API. SVG is a retained-mode graphics API. They solve very different problems and have very different use cases; that's why both sorts of APIs are out there in the wild... There's some overlap where either one could be used, but in almost all such cases one or the other is an obviously better fit.
Are you talking about SVG 1.2 Tiny, or SVG 1.1 Tyny? Firefox supports SVG 1.1 Tiny as well as or better than it does SVG 1.1 full. As for SVG 1.2 Tiny, parts of it conflict with CSS or the W3C DOM (as in, either impossible or very difficult to support those and SVG 1.2 Tiny at once). Still other parts are completely off-the-wall bonkers for a graphics language (an incompatible XHR replacement? A setTimeout/setInterval replacement? An incompatible window.location definition? Thankfully, the socket access APIs seem to have gotten cut at some point after all.).
Those parts of SVG Tiny 1.2 will likely never get implemented in Firefox, or any other SVG UA that actually has to deal with web content.
Sure, I'm not saying that the Apple and Microsoft situations are equivalent. Just that Apple is no better if you actually have to deal with it; the difference is that it's easier to not deal with it.
> Plus, Apple doesn't design the OS around the browser like MS does.
Are you sure? As I understand, Apple's changing the way painting works on an OS level so Safari might be able to do process-per-tab. The "system" Webkit is used to do all sorts of stuff outside Safari (e.g. dashboard widgets). Last I checked, various non-public OS APIs were used by Safari. You can't set the default browser to use without going into Safari's preferences.
How is this different from the IE situation exactly?
> You don't validate the memory manager returns a value, your code gets a security alert.
Except in this case it's "You don't validate the memory manager returns a value, the code of whatever app is using your system library gets a security alert." No skin off the Apple or Microsoft employees who wrote the buggy code, right?
So it's not just CS 101 that doesn't "properly" deal with blame for ignoring OOM. Neither does the real world.
> A "missing OOM check" IS A GOD DAMN BUFFER OVERFLOW.
It's a pretty special case, though, since the pointer you get when you OOM points to a big hunk of memory which you can't overwrite (trying will just crash your process). Of course if you try to write too far into the buffer you could still lose.
So I definitely agree this needs to be fixed, and am all in favor of the system libraries involved fixing it. The missing OOM check isn't in Firefox code, note.
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.
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.
> 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.
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.:(
Slashdot Mirror
Uh... All think tanks, by and large, have no agenda other than shaping political discourse. The vast majority are intellectually dishonest. This is true whether you label them "conservative" or "liberal".
Now it may be that in some cases you feel that the ends justify such means. That's a separate issue. But let's not pretend that think tanks are anything other than tools for policy creation by unelected folks of all sorts. Sadly, that's the only kind of policy creation we have nowadays.
Of course, there are also all sorts of non-think-tank organizations whose only purpose is to shape political discourse (Greenpeace comes to mind, though there are others that are less extreme). So I'm not even sure why you're picking on think tanks...
40 years? See end of http://www.thenation.com/doc/20000320/kitman/3 and beginning of http://www.thenation.com/doc/20000320/kitman/4 for some background on why we ended up with leaded gasoline to start with: it's because back in 1918-1921 there was a strong push to make gasoline more competitive with ethanol in high-compression engines so as to keep being able to sell gasoline as car fuel....
So the right number is closer to 90 years.
Well, hold on. You said 3.5.2 has "horrible JavaScript rendering". Presumably some other browsers don't. If so, that needs to be investigated; there's a good chance that this is a bug in Gecko or at least something Gecko can work around.
Hard to do that without specific steps to reproduce the issue, though.
You _can_, but since there's no JIT shipped for x64 the pref does absolutely nothing on that architecture.
What problem did you encounter, exactly? Did you report it?
I'd love to fix whatever the issue was, but the above is really not enough information to start on that...
> I have ver 3.52 and it takes forever to startup.
In that case, the random number thing is not your problem.
Is startup still slow in safe mode? If not, can you pin down which extension or combination of extensions is contributing? If it's still slow in safe mode, please file a bug with whatever details you can come up with.... Might also be testing with a new profile; if _that_ is fast while the old profile is slow then it could be an issue in the Places code or something; useful information for that bug that you'll file.
Please feel free to cc me (":bz" in Mozilla's Bugzilla) on any bugs you file. I'll make sure they land in the right place.
> but all browsers scream, yell, and throw a fit
Because both browsers and various websites have spent years telling users "lock == secure". So they need to either make it very clear that in this case the site really is not as secure as the "normal" secure case, or need to not show the lock.
That's the other obvious option: show no SSL-related UI for self-signed certs. Treat them exactly like http:/// connections UI-wise. That would have to include showing "http://" instead of "https://" in the url bar, since users have been trained to look for that too.
Somehow, I doubt that would make you happy.
> You're comments show you haven't read the SVG specification
Uh... Trust me, I have. See http://www.w3.org/Search/Mail/Public/search?keywords=&hdr-1-name=from&hdr-1-query=bzbarsky&index-grp=Public_FULL&index-type=t&type-index=www-svg
> SVG doesn't have timer support, its scripting language does, which is open.
I have no idea what "open" means in this case. SVG 1.2 Tiny support would presumably include support for the SVG 1.2 uDOM (that's the only profile of SVG 1.2 Tiny defined section 1.2.1 of the SVG 1.2 Tiny specification) which includes the things I listed in my comment. The uDOM is a language-independent interface specification; there is no "SVG scripting language".
> My SVG render supports setTimer in Javascript
I have no idea what setTimer is (nor does Google, in the context of SVG). The SVG 1.2 Tiny timer object is created via createTimer on the global object (typically the Window). See http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGGlobal_createTimer
Are you quite sure you've read the SVG 1.2 Tiny specification?
> I was going to go one
One what?
> your post translates into 'Firefox support for SVG is absolutely ass-tastic'
Firefox support for SVG 1.1 Full is sorta-ok (not great, by any means).
Support for SVG 1.2 Tiny is an explicit non-goal for every single browser implementor, because of the issues I mentioned. Given that when the browser implementors raised precisely these concerns during the standardization process the SVG Working Group basically told them that they weren't meant to implement this specification, I'm not sure why you're suddenly demanding that they do.
Now SVG 1.2 Full, which is being worked on, is a very different beastie. We'll see how it works out. It's probably a few years from being in CR (and hence call for implementations) at this point.
Is this the part where one should comment about how the 17" MacBook Pro is 6.6 pounds?
If you really need the 17" screen, and move around a lot with it, that makes it very very worthwhile. Of course there's the slight price point problem.
Canvas is an immediate-mode graphics API. SVG is a retained-mode graphics API. They solve very different problems and have very different use cases; that's why both sorts of APIs are out there in the wild... There's some overlap where either one could be used, but in almost all such cases one or the other is an obviously better fit.
Are you talking about SVG 1.2 Tiny, or SVG 1.1 Tyny? Firefox supports SVG 1.1 Tiny as well as or better than it does SVG 1.1 full. As for SVG 1.2 Tiny, parts of it conflict with CSS or the W3C DOM (as in, either impossible or very difficult to support those and SVG 1.2 Tiny at once). Still other parts are completely off-the-wall bonkers for a graphics language (an incompatible XHR replacement? A setTimeout/setInterval replacement? An incompatible window.location definition? Thankfully, the socket access APIs seem to have gotten cut at some point after all.).
Those parts of SVG Tiny 1.2 will likely never get implemented in Firefox, or any other SVG UA that actually has to deal with web content.
Sure, I'm not saying that the Apple and Microsoft situations are equivalent. Just that Apple is no better if you actually have to deal with it; the difference is that it's easier to not deal with it.
> Plus, Apple doesn't design the OS around the browser like MS does.
Are you sure? As I understand, Apple's changing the way painting works on an OS level so Safari might be able to do process-per-tab. The "system" Webkit is used to do all sorts of stuff outside Safari (e.g. dashboard widgets). Last I checked, various non-public OS APIs were used by Safari. You can't set the default browser to use without going into Safari's preferences.
How is this different from the IE situation exactly?
> You don't validate the memory manager returns a value, your code gets a security alert.
Except in this case it's "You don't validate the memory manager returns a value, the code of whatever app is using your system library gets a security alert." No skin off the Apple or Microsoft employees who wrote the buggy code, right?
So it's not just CS 101 that doesn't "properly" deal with blame for ignoring OOM. Neither does the real world.
> A "missing OOM check" IS A GOD DAMN BUFFER OVERFLOW.
It's a pretty special case, though, since the pointer you get when you OOM points to a big hunk of memory which you can't overwrite (trying will just crash your process). Of course if you try to write too far into the buffer you could still lose.
So I definitely agree this needs to be fixed, and am all in favor of the system libraries involved fixing it. The missing OOM check isn't in Firefox code, note.
I know what your reference was, but the joke in Casablanca is that everyone knows there's gambling all along.
I can definitely agree with the rephrasing! ;)
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.
Again, do you actually see any?
Yes, it is. That's not related to the issue at hand.
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.
Well... That code _does_ crash the browser. Just not exploitably. ;)
When I tried this, I see Firefox crashing with a null dereference. So not exploitable.
Do you see something different?
Good question. I don't see any unbounded buffer use here. Do you?
> 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.
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. :(