Bugzilla patch for PerimeterX privilege problem
Have you patched Bugzilla against PerimeterX privilege-escalation vulnerability yet?
Firefox, the browser client not the crappy Clint Eastwood movie, is built upon a background of open collaboration. Mozilla, which describes itself as “a global community of technologists, thinkers and builders working together to keep the Internet alive and accessible, so people worldwide can be informed contributors and creators of the Web”, is the organisation behind Firefox.
According to Mozilla, around 40 per cent of the Firefox codebase is written by volunteers. According to Richard Barnes, the Firefox security lead at Mozilla, the Bugzilla bug tracker is “a major part of how we accomplish our mission of openness” and while much of the Bugzilla information is in the public domain “Bugzilla restricts access to security-sensitive information so that only certain privileged users can access it.”
At the start of September, Mozilla revealed that not only had Bugzilla been breached but the security-sensitive information stolen was used to attack Firefox users. It seems that a Bugzilla account was compromised and a particular vulnerability being discussed was exploited. Although Richard Barnes states that the account was closed down “shortly after Mozilla discovered that it had been compromised” there is no indication of how long it had been actively compromised. However, the version of Firefox released on 27th August is said to have fixed all of the vulnerabilities that could have been exploited using the information gleaned by the attacker.
Mozilla immediately took steps to reduce the risk of future attacks on Bugzilla, the first being the forced introduction of two-factor authentication along with a password change for all users with access to security-sensitive data. On top of that, Mozilla announced that it would be reducing the number of privileged access users and reducing what they can actually do. In the words of Richard Barnes “we are making it harder for an attacker to break in, providing fewer opportunities to break in, and reducing the amount of information an attacker can get by breaking in.”
Which is where Netanel Rubin, senior vulnerability researcher at PerimeterX, came in asking the question whether Bugzilla was actually as secure as it should be. To cut a long story short, it wasn’t. Are you sitting comfortably? Good, then the long story can begin.
Perhaps even more incredibly, was the ease with which the PerimeterX vulnerability research team were able to exploit it.
What Netanel and his research team discovered was a vulnerability related to how Bugzilla provides protected and secure access through a process of controls offering different levels of access to different users. One of these control methods relates to assigning privilege based on email the address of the user, specifically the bestowing of trust by association if a user provides an email address belonging to a recognised ‘trusted’ organisation. An organisation such as, say, Mozilla. This vulnerability effectively enabled a threat actor to perform a privilege-escalation attack to gain privileges otherwise unobtainable to them.
Incredibly, in the light of the fact that Bugzilla holds data upon security vulnerabilities that have yet to be disclosed or fixed, this allowed an attacker to create an email in any domain regardless of actually having any access to that domain. What they did have access to, as a result of successful exploitation of this vulnerability, was an ability to not only view that privileged security data but also modify it and change settings (assuming the privileges for that account group allowed it). It was, in other words, a zero-day wet dream.
Perhaps even more incredibly, was the ease with which the PerimeterX vulnerability research team were able to exploit it. Note that I say ‘ease’ and specifically for a team of experts; this was not something that the average script kid would likely get a grasp on. For the full technical description it’s probably best you go and read what Netanel says about it in his blog entry but here’s the low fat version.
Bugzilla relies upon email validation for authorisation, with an email link containing a token used to enable registration from that address and configuration of login credentials. The registration data is saved in a ‘tokens’ DB table along with the token required to activate the address, and the address is stored in a column called ‘eventdata’. When the user validates their email with the token, the email is taken from that column and used to create the account itself.
Although the Bugzilla registration process did, as you would expect, test the email address provided to ensure it didn’t contain characters or formatting that might be considered dangerous before the token was created, it didn’t validate that the token itself had been correctly created and just sent it in the confirmation email with an assumption that it had been.
What PerimeterX did was look to corrupting the email address as it was inserted into the DB, and it did this by concentrating on the ‘eventdata’ column. This, being of the ‘tinytext’ type is a 255 byte (max) text string in MySQL and Bugzilla specifies 255 bytes as an exact size for other DBs not supporting the ‘tinytext’ type. By inserting more than 255 bytes, the research team found that no exception was raised but instead the data was truncated to fit the column size.
Which means? Yep, no flies on you people are there? This means that if create an email address longer than 255 bytes, which will look like the target domain upon truncation, then the Bugzilla system would mis-identify it. By appending another domain, which the attacker has access to, the target domain becomes a sub-domain of that and enables them to get the validation link.
This vulnerability hit every version of Bugzilla going right back to 2.0 and so it’s panic stations and time to stop using Firefox right? Erm, nope, not from what IT Security Thing can gather.
For starters the details of this vulnerability are only being made public by PerimeterX now; disclosure to Mozilla was on the 7th September and the patch to fix it released on the 10th. There is no evidence to suggest that anyone else had identified the vulnerability, let alone exploited it.
However, there has now been a long enough window for the bad guys to become aware of, and start exploiting, on unpatched systems. The advice, therefore, is aimed squarely at users of Bugzilla using email based permissions in their deployment: do not use it until you have patched it. Take it down, audit your logs and identify any users that may have been created using the vulnerability. The advice for every other Bugzilla user is the same: apply the patch!