686995 - Calling Product.get while being logged out causes high CPU usage on the Bugzilla server

Status: RESOLVED FIXED

(Bugzilla :: WebService, defect)

Description

[Frédéric Buclin]

The problem only appears while being logged out and using 4.1.3. Doesn't appear on 4.0 or while being logged in (even as a powerless user).

Calling Product.get while being logged out never returns anything and it causes high CPU usage on the Bugzilla server. I could reproduce locally and on landfill. So all you need to do to cause trouble on the server is to call Product.get, kill your script, and call Product.get again, etc... The process will still run on the server after you killed your script, and so you can easily eat all the CPU of the server by having several processes running at the same time.

I'm filing this bug as a security bug as you could easily make a server unresponsive.

Comment 1

[Frédéric Buclin]

To be clear: high CPU usage means 100% of the CPU, even on a dual core! (found while running webservice_product.t)

Comment 2

[Max Kanat-Alexander]

Okay. Does this happen with any set of Product.get arguments or only with certain ones?

Comment 3

[Frédéric Buclin]

(In reply to Max Kanat-Alexander from comment #2)
> Okay. Does this happen with any set of Product.get arguments or only with
> certain ones?

I just tried with { ids => [1, 2, 3] }. No special hack required.

Comment 4

[Frédéric Buclin]

There seems to be some deep recursion in package Bugzilla::XMLRPC::Serializer, in _strip_undefs().

Comment 5

[Frédéric Buclin]

The problem seems to be due to 'internals'. As I see it, internals contains a product object, and due to object referencing, you can end in a deep recursion while going through an object internals, because e.g. a product object has a default assignee and QA contact, which themselves have a list of accessible products, etc.... Despite internals is here since 3.0, the checkin of bug 655229 generated this deep recursion (backing out this patch fixes the problem).

Personally, I see 'internals' as evil, because you have no control over what is returned. It should go away, as proposed in bug 655652. So fixing bug 655652 should fix this problem too.

Comment 6

[Frédéric Buclin]

My patch from bug 655652 indeed fixes the problem.

Comment 7

[Frédéric Buclin]

Blocker has been checked in. Admins on the 4.2 branch can now update their installation via bzr.