Maciej Stachowiak wrote:

On Dec 22, 2005, at 6:48 PM, Kurt Kohler wrote:

...

I haven't been following the chat room so I might have missed it, but I'm surprised there hasn't been any discussion here about the "denial of service" bug reported at the following URL.

http://www.security-protocols.com/advisory/sp-x22-advisory.txt

I don't want to jump to conclusions, but we're talking about open source software here. He could have fixed it himself or at least filed a Bugzilla report. As far as I can tell he did neither. He does claim to have reported it to Apple. Is it in radar perhaps?

It is in Radar.

I don't recall ever getting proof of the "execute arbitrary code" exploitability. We don't usually treat crashers as security bugs, because then every reproducible crash would count as a security exploit and that's not really reasonable given how many there are.

Can't comment on when/whether this will make it to a security update.

...

I'll wait before I say what I think about this guy. I don't want to be slanderous without cause.

BTW I saw a claim elsewhere that it had been fixed in the nightlies, but it looks like as of a few minutes ago ensureRows in TOT still has the problem (it does a resize with a value that doesn't appear to be checked against any limit).

We don't check against a hard limit but TOT will no longer crash or overwrite memory (try it). We now detect the allocation failure. But it might be good to also set a hard upper limit on rowspans.

Regards, Maciej

Wearing belt AND suspenders never hurts, right? Until there's a performance hit, I don't see that you can have too many checks. A lot of people seem to be interpreting it as a security hole in spite of the fact that the report says Safari will "crash, and or execute arbitrary code." I suppose that "and or" maybe gives them an out, but do they truly believe that _every_ crashing bug is exploitable? I know how I'd feel if somebody pulled a stunt like this on me! I'm probably over-reacting, but it really annoys me! Kurt

John Sullivan wrote:

...

...

We don't check against a hard limit but TOT will no longer crash or overwrite memory (try it). We now detect the allocation failure. But it might be good to also set a hard upper limit on rowspans.

Regards, Maciej

Wearing belt AND suspenders never hurts, right? Until there's a performance hit, I don't see that you can have too many checks.

Any time you put in a hard limit for something, you run the risk of running into a legitimate case where the hard limit is exceeded. So it's not just a "belt and suspenders" issue -- there is a real downside for this kind of change.

Absolutely! Whatever limit you choose, someone will want more. I didn't word what I said very well.

...

A lot of people seem to be interpreting it as a security hole in spite of the fact that the report says Safari will "crash, and or execute arbitrary code." I suppose that "and or" maybe gives them an out, but do they truly believe that _every_ crashing bug is exploitable?

They aren't thinking at all, is my guess. One person somewhere found a reproducible crash, and somehow got the idea that it was potentially a security risk, and he wrote that down somewhere, and everyone else is just repeating it without thinking.

John Well except that the report is from a "company", although of course it could be just the one guy. People are definitely giving it more credence than it deserves.