| |||||||||||||
|
| |||||||||||||
How to kill a web browserHow to kill a web browserPosted Oct 21, 2004 5:56 UTC (Thu) by mmarkov (guest, #4978)Parent article: How to kill a web browser
I don't know the free browsers' internals, but don't
I mean, come on, you cannot crash a C compiler
(Log in to post comments)
Maybe tolerance to legacy pages is part of the problem? Posted Oct 21, 2004 6:53 UTC (Thu) by eru (subscriber, #2753) [Link] It would certainly be trivial to weed out these really malformed pages if you simply parsed them strictly according to the HTML spec and rejected all pages that do not pass, but in practice users expect browsers to also render many syntactically incorrect pages, otherwise a large chunk of the web would be unviewable.I suspect attempts to implement fuzzy parsing that tolerates slightly broken pages is partly to blame here (but of course that is no excuse for buffer overflow errors).
Maybe tolerance to legacy pages is part of the problem? Posted Oct 21, 2004 10:44 UTC (Thu) by NAR (subscriber, #1313) [Link] in practice users expect browsers to also render many syntactically incorrect pagesNot to mention that some of us like the feature that a browser starts to display the page even when it hasn't fully download it yet.
How to kill a web browser Posted Oct 21, 2004 7:08 UTC (Thu) by hodoscek (subscriber, #5290) [Link] It doesn't kill it, at least in my version of firefox nothing happens
How to kill a web browser Posted Oct 21, 2004 7:36 UTC (Thu) by dale77 (guest, #1490) [Link] Likewise, Firefox 1.0PR on WinXP (sorry) handles <HTML><INPUT fine
How to kill a web browser Posted Oct 21, 2004 8:30 UTC (Thu) by nathan (subscriber, #3559) [Link] > I mean, come on, you cannot crash a C compiler> with an invalid C source.
I beg to differ :)
How to kill a web browser Posted Oct 21, 2004 9:38 UTC (Thu) by nix (subscriber, #2304) [Link] Definitely you can. The old `confused by earlier errors, bailing out' message in GCC, and the new `internal compiler error' messages are definitely crashes... Have a look at:<http://gcc.gnu.org/bugzilla/buglist.cgi?keywords=ice-on-i...;
At the time of writing, that's 689 cases of crashing a C (and C++, Ada, Java, Fortran) compiler with invalid code. Add an &component=c to the end of that URI, and you find 56 examples of crashing the C compiler.
This is not a crash! Posted Oct 21, 2004 15:21 UTC (Thu) by spudbeach (guest, #5837) [Link] A "crash" is when a program completes incorrectly, often with a segfault. A compiler saying "giving up" isn't a crash -- it is a normal termination for bad input. No signal, no possibility of exploitation, and the user got some output that is useful.
This is not a crash! Posted Oct 22, 2004 13:46 UTC (Fri) by nix (subscriber, #2304) [Link] The old `bailing out' message was triggered, IIRC, by a SIGSEGV being caught. So there was a signal.
I doubt it could be regarded as exploitable, though. :)
How to kill a web browser Posted Oct 22, 2004 0:10 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] Almost all of the GCC crashes occur when GCC itself detects an inconsistency and quits with an internal error. There are a few, though, where the compiler actually crashes because of internal corruption, but those are far rarer.Cases where the application itself decides to abort aren't security risks (though they could possibly be used to create a denial of service attack if the app can be made to repeatedly shut itself down).
How to kill a web browser Posted Oct 22, 2004 13:45 UTC (Fri) by nix (subscriber, #2304) [Link] The internal-corruption crashes certainly are rare, now. I was really thinking of the days of egcs and before, when the `bailing out' message often *was* the result of a SIGSEGV being caught, if memory serves, and was really rather easy to trigger...
... and no, this isn't a security risk. (Who would execute a compiler in a security-critical environment anyway? The security risks are generally in the compiler's output when it succeeds :) )
|
|
||||||||||||