Closed
Bug 237627
Opened 21 years ago
Closed 20 years ago
reports.cgi doesn't detect invalid dataset name
Categories
(Bugzilla :: Reporting/Charting, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.16
People
(Reporter: wicked, Assigned: wicked)
Details
(Whiteboard: [fixed in 2.16.6] [fixed in 2.18rc1])
Attachments
(2 files)
610 bytes,
patch
|
goobix
:
review+
|
Details | Diff | Splinter Review |
540 bytes,
patch
|
justdave
:
review+
|
Details | Diff | Splinter Review |
There is code in reports.cgi chart_image_name sub that supposedly would yell if
an invalid dataset name is specified. Unfortunately the code uses broken regexp
so it won't detect the condition correctly.
Assignee | ||
Comment 1•21 years ago
|
||
This new regexp will now correctly detect if there are other than letters,
numbers or :-characters in any of the dataset names.
Assignee | ||
Updated•21 years ago
|
Attachment #144032 -
Flags: review?(vlad)
Updated•21 years ago
|
Attachment #144032 -
Flags: review?(vlad) → review+
Updated•21 years ago
|
Status: NEW → ASSIGNED
Flags: approval?
Target Milestone: --- → Bugzilla 2.18
Updated•21 years ago
|
Flags: approval? → approval+
Comment 2•21 years ago
|
||
Let's hold this for a security advisory.
This can be exploited as an arbitrary filename path or XSS.
Group: webtools-security
Flags: approval+ → approval?
Comment 3•21 years ago
|
||
Just checked... 2.16 is affected by this, too, so we need a patch for 2.16
Whiteboard: [wanted for 2.16.6] [ready for 2.18rc1]
Comment 4•21 years ago
|
||
hmmm, okay, I can't actually find a way to actually exploit this. Chart::Base
dies with "invalid symbol reference" if you try to pass in a dataset name that
contains a /, so that eliminates pathname garbage. And it doesn't appear to
actually display the datasets that it can't actually find except as part of the
image filename, which obviously remains escaped somehow...
<img
src="graphs/-All-_NEW_ASSIGNED_REOPENED_UNCONFIRMED_%3Cscript%3Ealert%28%27foo%27%29.png">
Anyone else have any ananysis they can provide? We should probably still fix
this in 2.16, but I'm starting to think it's not an exploitable security hole now...
Assignee | ||
Comment 5•21 years ago
|
||
Tested and it seems same patch will apply to tip of 2.16 branch flawlessly.
Whiteboard: [wanted for 2.16.6] [ready for 2.18rc1] → [ready for 2.16.6] [ready for 2.18rc1]
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16
Updated•21 years ago
|
Flags: approval2.16?
Updated•21 years ago
|
Flags: blocking2.18+
Flags: blocking2.16.6+
Comment 6•20 years ago
|
||
While attachment 144032 [details] [diff] [review] is right for 2.16, this is de-bitrotted to apply
smoothly for 2.18
Updated•20 years ago
|
Attachment #152375 -
Flags: review?(justdave)
Updated•20 years ago
|
Attachment #152375 -
Flags: review?(justdave) → review+
Updated•20 years ago
|
Flags: approval2.16? → approval2.16+
Updated•20 years ago
|
Flags: approval? → approval+
Comment 7•20 years ago
|
||
checked in on both branches
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Whiteboard: [ready for 2.16.6] [ready for 2.18rc1] → [fixed in 2.16.6] [fixed in 2.18rc1]
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•