Bugzilla Privileged Bug Disclosure (CVE-2015-4499)

Blog Post created by todb Employee on Sep 18, 2015

Yesterday, PerimeterX disclosed an issue in the venerable Bugzilla bug tracker, which can allow an untrusted attacker to gain access to privileged bug reports. This includes, of course, privately reported, but still unfixed, security vulnerabilities. Operators of Bugzilla bug trackers which use e-mail based permisisons are strongly advised to patch today. This would be a good place to insert a "yo dawg" joke about bugs in bugs, but I trust you've filled in the rest yourself by the end of this sentence.

Bugzilla-ayb.png by Mozilla Foundation - Licensed under MPL 1.1 via Wikimedia Commons -

Bugzilla is one of the oldest bug trackers around, first published in 1998 and written in Perl. According to the Bugzilla project, now run by the Mozilla Foundation, there are 136 organizations running public bugzilla instances. There are undoubtedly many, many more in internal network environments.


New Perl-based web applications are a rarity today, with most people favoring more modern web application frameworks written in more modern languages such as Ruby, Javascript, or PHP. The current investigation by PerimeterX is focused on Perl applications for an upcoming sequel to the Chaos Communication Congress presentation, "The Perl Jam." Today, many applications on the Internet still running Perl could be considered both "legacy" and "mission critical."


In some long-running IT environments, especially closed environments, it is easy to fall into a "it was like that when I got here" mindset, which is one of the reasons penetration testers nearly always are able to find older, unsupported, and unpatched systems running in internal target environments. While open source is usually quick to embrace new technologies for developing applications, such as Ember, React, and Angular, often at dizzying speed, there are still plenty of mature open source projects which rely on established technologies. Upgrading and rewriting software in new languages and frameworks is a fairly major undertaking, and thus, is usually reserved for new projects where technical debt is negligible to non-existent.


Like in many other industries, newer web application technologies are generally safer. By analogy, old cars lacked crumple zones, anti-lock brakes, and airbags, which is unthinkable in today's automotive industry. Similarly, more modern web application frameworks tend to never expose problems like stack-based buffer overflows or format string vulnerabilities, and actively guard against common cross-site scripting and SQL injection bugs. Web applications can and do ship bugs, for sure, but typical usage of modern frameworks comes with some assurance that the developer won't be able to immediately shoot himself in the foot.