The general concept I'd like to see explored is perhaps best explained with a couple of concrete bugs I have found and fixed recently:
- Dimensions error parsing XBM image. Welcome to the XBM image format, a veritable dinosaur of image formats. It's a textual format and looks a bit like this:
#define test_width 8
The WebKit XBM parsing code includes this line, to extract the width and height:
#define test_height 14
static char test_bits[] = {
0x13, 0x00, 0x15, 0x00, 0x93, 0xcd, 0x55, 0xa5, 0x93, 0xc5, 0x00, 0x80,
0x00, 0x60 };if (sscanf(&input[m_decodeOffset], "#define %*s %i #define %*s %i%n",
&width, &height, &count) != 2)
return false;
The XBM parser supports streaming (making render progress before you have the full data available), including streaming in the header. i.e. the above code will attempt to extract width and height from a partial XBM, and retry with more data if it fails. So what happens if the first network packet contains an XBM fragment of exactly the first 42 bytes of the above example? This looks like:#define test_width 8
I think you can see where this is going. The
#define test_height 1sscanf()
sees two valid integers, and XBM decoding proceeds for an 8x1 image, which is incorrect. The real height, 14, had its ASCII representation fractured across a packet boundary. - Out-of-bounds read skipping over HTML comments. This is best expressed in terms of part of the patch I submitted to fix it:
--- WebCore/loader/TextResourceDecoder.cpp (revision 44821)
+++ WebCore/loader/TextResourceDecoder.cpp (working copy)
@@ -509,11 +509,13 @@ bool TextResourceDecoder::checkForCSSCha
static inline void skipComment(const char*& ptr, const char* pEnd)
{
const char* p = ptr;
+ if (p == pEnd)
+ return;
// Allow ".
if (p[1] == '-' && p[2] == '>') {
As can be seen, some simple bounds checking was missing. In order to trigger, the browser would need to find itself processing an HTML fragment ending in: