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 
I and all the other Firebug userss would really appreciate it if you could alert me (joe@joehewitt.com) to the new exploit you have found so I can patch it before it leaves us all vulnerable.
One motivation for the functional DOM construction was indeed security - it’s far easier to identify code where I’m inserting potentially hazardous HTML this way. Firebug 0.4 used DOM methods which resulted in a lot more code to scan.
The exploit doesn’t indict the domplates system as much as it indicts me for forgetting to escape one string.
I’m not sure how you draw the conclusion that domplates are responsible for a large portion of the 700k weight of Firebug. domplates.js is only 25k, and while uses of domplates are many in Firebug, those applications would consume many more lines of code using DOM methods instead.
domplates are also much faster than DOM methods because they compile down to strings, reducing potentially hundreds of DOM method calls to a single innerHTML call.
[...] 0day vulnerability in Firebug [...]
Hi Joe, thank you for commenting so quickly.
You are right that a functional construct such as your domplate does enable you to more easily identify potentially hazardous HTML. If properly designed, any input validation can be controlled from a single entry point.
However, the decision about what kind of input validation to perform is still left up to the individual code segments that use domplate constructors. I would suggest that all your string constructs call the escapeHTML function automatically, instead of having to specify it manually in each instance.
I did not get to read your comment until after I had written my follow up post, so my apologies if it causes you any concern.
You’re right, that was dumb of me, I should automatically escape everything. I’m going to release a new version, hopefully within the hour, with this fixed.