I’m posting a fresh 0day vulnerability in Firebug in my next post! But first, an analysis of the current 0day vulnerability:

Firebug is a very popular web application development tool that comes in quite handy when debugging HTML, CSS and Javascript. It’s intuitively easy to use, has got great features such as console logging and live debugging of XMLHTTPRequest queries and it gets the Thumb Up from Thor – I use it daily.

It seems that pdp over at gnucitizen discovered a 0day vulnerability in Firebug. Joe Hewitt, the author of Firebug, has published an entry on his blog about the Firebug v1.0.2 and v1.0.3 updates that he released in response.

Firebug is a great tool and Joe Hewitt is a fine developer, but when you combine the inherent lack of separation between trusted and untrusted content in Firefox with a development tool that exposes near-direct access to its custom-built HTML construction logic you will inevitably end up with some security vulnerabilities. The Javascript chrome code inside Firebug comes in at roughly 700KB, a large portion of which deals with the function oriented tag construction logic that Joe decided to implement in Firebug.

As an extension, Firebug is built upon XUL and a large dash of HTML, CSS and Javascript. Ordinarily one would use templates or DOM methods to construct new elements such as the rows and links inside the console or the navigation tree of your HTML structure. Instead, Firebug opts for a functional approach where each designated HTML tag has its own corresponding constructor function, which means that the code for generating a table might look something like this:

TABLE({width: "100%"},
    FOR("prop", "$group.props",
        TR(
            TD({class: "stylePropName"}, "$prop.name"),
            TD({class: "stylePropValue"}, "$prop.value")
        )
    )
)

These identifiers have corresponding manipulation functions such as cropString and escapeHTML, the latter of which is where the vulnerability pdp discovered comes from:

this.Obj = domplate(Firebug.Rep,
{
tag:
OBJECTLINK(
SPAN({class: "objectTitle"}, "$object|getTitle"),
FOR("prop", "$object|propIterator",
" $prop.name=",
SPAN({class: "objectPropValue"}, "$prop.value|cropString|escapeHTML")
)
),

You see, the FOR construct iterates $object using the propIterator function and for each iteration it assigns the current object to the $prop variable and then outputs the name and value properties. The value property is cropped and escaped as HTML but the name property was not. The fix was quite literally
" $prop.name|escapeHTML=".

Once again the KISS principle reminds us that security is like music - just keep it simple and have fun.

As I promised my next post will detail a completely new 0day vulnerability in Firebug that remains unpatched :)