Bug 619637 (CVE-2010-4569)

[SECURITY] XSS in user autocomplete due to lack of encoding by YUI

RESOLVED FIXED in Bugzilla 4.0

Status

()

Bugzilla
User Interface
--
major
RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: reed, Assigned: reed)

Tracking

(Blocks: 1 bug)

3.7.1
Bugzilla 4.0
Dependency tree / graph
Bug Flags:
approval +
approval4.0 +
blocking4.0 +
blocking3.6.4 -

Details

(Whiteboard: [infrasec:xss][ws:critical])

Attachments

(1 attachment)

(Assignee)

Description

7 years ago
If a user's real name field happens to contain XSS, the user autocomplete UI will happily execute it, as it does no escaping of any potential valid HTML.

http://yuilibrary.com/forum/viewtopic.php?p=12923 talks about the problem somewhat.
Flags: blocking4.0?
Flags: blocking3.6.4?

Comment 1

7 years ago
WTF YUI! Man.

Autocomplete doesn't exist in 3.6.x, so it's not affected. But this should block 4.0 if you can get a patch to me ASAP.
Flags: blocking4.0?
Flags: blocking4.0+
Flags: blocking3.6.4?
Flags: blocking3.6.4-

Updated

7 years ago
Target Milestone: Bugzilla 3.6 → Bugzilla 4.0
(Assignee)

Comment 2

7 years ago
Note that bmo is affected by this, even though it's running 3.6.x. I backported the user autocomplete stuff.
(Assignee)

Comment 3

7 years ago
I filed http://yuilibrary.com/projects/yui2/ticket/2529228 upstream about this.
Summary: [SECURITY] XSS via real_name field in user autocomplete → [SECURITY] XSS in user autocomplete due to lack of encoding by YUI
(Assignee)

Comment 4

7 years ago
Created attachment 498073 [details] [diff] [review]
patch - v1
Attachment #498073 - Flags: review?(mkanat)

Comment 5

7 years ago
Isn't there some built-in HTML escaper in YUI?

What happens when YUI fixes this bug upstream, as they appear to intend to do?
(Assignee)

Comment 6

7 years ago
(In reply to comment #5)
> Isn't there some built-in HTML escaper in YUI?

Not that I can see from poking around.

> What happens when YUI fixes this bug upstream, as they appear to intend to do?

We override the formatter anyway, so we'd still be vulnerable. I'll just modify our code to use their util function or whatever they offer.

Comment 7

7 years ago
CC'ing pyrzak as he knows YUI pretty well.

Updated

7 years ago
Blocks: 620540
(Assignee)

Updated

7 years ago
Whiteboard: [infrasec:xss][ws:high] → [infrasec:xss][ws:critical]
CVE-2010-4569
Alias: CVE-2010-4569

Updated

7 years ago
Attachment #498073 - Flags: review?(guy.pyrzak)
Comment on attachment 498073 [details] [diff] [review]
patch - v1

This looks good and works for me until the proper upstream fix is implemented. r=dkl
Attachment #498073 - Flags: review+
(Assignee)

Updated

7 years ago
Flags: approval?
Flags: approval4.0?

Comment 10

7 years ago
Does /regex/g work in IE?

Comment 11

7 years ago
(In reply to comment #10)
> Does /regex/g work in IE?

code-error.html.tmpl uses it, so I guess so, yes.
(Assignee)

Comment 12

7 years ago
(In reply to comment #10)
> Does /regex/g work in IE?

Yes, since IE 4, I believe.

Comment 13

6 years ago
This patch does what reed wants it to do, which is escape incoming HTML, however, i'm not an XXS attack expert and I feel uncomfortable saying that this solution will stop all possible XXS attacks. But the attached patch (patch - v1), does escape incoming text that he lists in his code. Not sure if this is helpful or not. 

Basically the code looks good, my knowledge of the numerous ways to do a XXS attack are to limited to know if this patch is enough to stop the behavior in question.

Updated

6 years ago
Attachment #498073 - Flags: review?(guy.pyrzak)

Comment 14

6 years ago
Comment on attachment 498073 [details] [diff] [review]
patch - v1

This does look correct and it's the same as what YUI does, so at the least we will be just as secure as the DataTable text formatter.
Attachment #498073 - Flags: review?(mkanat) → review+

Updated

6 years ago
Version: 3.6.3 → 3.7.1

Updated

6 years ago
Flags: approval?
Flags: approval4.0?
Flags: approval4.0+
Flags: approval+
(Assignee)

Comment 16

6 years ago
Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/
modified js/field.js
Committed revision 7671.
Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/4.0/
modified js/field.js
Committed revision 7528.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 17

6 years ago
Security advisory sent. Removing the security flag.
Group: bugzilla-security

Updated

4 years ago
Blocks: 835424
You need to log in before you can comment on or make changes to this bug.