Closed Bug 686995 Opened 13 years ago Closed 13 years ago

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

Categories

(Bugzilla :: WebService, defect)

Product:
Bugzilla
Component:
WebService
Version:
4.1.3
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 4.2

People

(Reporter: LpSolit, Assigned: LpSolit)

References

Details

(Keywords: regression, Whiteboard: [blocker will fix])

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.
Flags: blocking4.2+
To be clear: high CPU usage means 100% of the CPU, even on a dual core! (found while running webservice_product.t)
Okay. Does this happen with any set of Product.get arguments or only with certain ones?
(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.
There seems to be some deep recursion in package Bugzilla::XMLRPC::Serializer, in _strip_undefs().
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.
Depends on: 655229, 655652
My patch from bug 655652 indeed fixes the problem.
Assignee: webservice → LpSolit
Status: NEW → ASSIGNED
Whiteboard: [blocker will fix]
Blocker has been checked in. Admins on the 4.2 branch can now update their installation via bzr.
Group: bugzilla-security
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.