devZing

From time to time we’ve had people wonder if the XML-RPC API is turned on for their Bugzilla installation. The answer is yes in all cases. Nevertheless it is difficult to verify as Bugzilla will not give you a meaningful response if you go to https://<mybugzilla>/xmlrpc.cgi in your browser.

Other clients want to verify some off error message they are getting from a tool that integrates with Bugzilla through the XML-RPC API.

To solve these questions we have deployed our online XML-RPC client.

By default it has the URL and credentials for our Bugzilla demo, but you can point it to any Bugzilla with XML-RPC enabled (even https://bugzilla.mozilla.org/).

The tricky bit is the parameter XML.

Bugzilla XML-RPC expects a single <struct> element. The names of the parameters listed in the API docs for each function are the <name> element for the struct <member>s. See Bugzilla::WebService::Server::XMLRPC and Bugzilla::WebService for more information.

For example

<param>
 <struct>
 <member>
 <name>Bugzilla_login</name>
 <value>demo@devzing.com</value>
 </member>
 <member>
 <name>Bugzilla_password</name>
 <value>password</value>
 </member> 
 </struct>
</param>

This is the minimum set of parameters for Bugzilla 4.4.x as almost all methods require authentication.

To retrieve a bug you need to set the method to Bug.get and parameter XML to something like the following:

<param>
 <struct>
 <member>
 <name>Bugzilla_login</name>
 <value>demo@devzing.com</value>
 </member>
 <member>
 <name>Bugzilla_password</name>
 <value>password</value>
 </member>
 <member>
 <name>ids</name>
 <value>
   <array>
     <data>
       <value><i4>12</i4></value>
     </data>
   </array>
</value>
 </member>
</struct> 
</param>

For more information on how to represent various data types see the XML-RPC specification.

Bugzilla 4.4.5 is a security release which addresses the following issue:

Adobe does not properly restrict the SWF file format, which allows remote attackers to conduct cross-site request forgery (CSRF) attacks against Bugzilla’s JSONP endpoint, possibly obtaining sensitive bug information, via a crafted OBJECT element with SWF content satisfying the character-set requirements of a callback API.

For more details see: https://bugzilla.mozilla.org/show_bug.cgi?id=1036213

Interestingly this bug only seems to affect Firefox users.

The Bugzilla team has released a security fix for Bugzilla 4.0.x.

• A CSRF vulnerability in the implementation of the XML-RPC API when running under mod_perl could be used to make changes to bugs or execute some admin tasks without the victim’s knowledge.

This defect does not affect any devZing customers. However, all new devZing hosted Bugzilla installs will be created with Bugzilla 4.0.5.

All Bugzilla hosting customers have been upgraded to Bugzilla 4.0.4.

You can read more about the release at the Bugzilla site.

A number of changes were released to address this http://www.bugzilla.org/security/3.4.13/:

• When a user creates a new account, Bugzilla doesn’t correctly reject email addresses containing non-ASCII characters, which could be used to impersonate another user account. Such email addresses could look visually identical to other valid email addresses, and an attacker could try to confuse other users and be added to bugs he shouldn’t have access to.
• Due to a lack of validation of the Content-Type header when making POST requests to jsonrpc.cgi, a possible CSRF vulnerability was discovered. If a user visits an HTML page with some malicious JS code in it, an attacker could make changes to a remote Bugzilla installation on behalf of the victim’s account by using the JSON-RPC API. The user would have had to be already logged in to the target site for the vulnerability to work.