Bug 1063853
| Summary: | XSS vulnerability in changePasswordMsg | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] oVirt | Reporter: | Tomas Jelinek <tjelinek> | ||||
| Component: | ovirt-engine-userportal | Assignee: | Yair Zaslavsky <yzaslavs> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Petr Beňas <pbenas> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 3.4 | CC: | acathrow, awels, bazulay, ecohen, gklein, iheim, oourfali, pbenas, pmatouse, pstehlik, tjelinek, yeylon, yzaslavs | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 3.4.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | infra | ||||||
| Fixed In Version: | ovirt-3.4.0-beta3 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-03-31 12:27:00 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Tomas Jelinek
2014-02-11 14:31:19 UTC
its XSS if you don't trust the ovirt admin, or possible to inject by another site somehow? becuse the ovirt admin can send whatever they want to the clients... (In reply to Itamar Heim from comment #1) > its XSS if you don't trust the ovirt admin, or possible to inject by another > site somehow? only if you are able to manipulate the vdc_options > becuse the ovirt admin can send whatever they want to the clients... well, it is not a serious security vulnerability and I can hardly imagine an attack done using it. But I still think that we should handle it properly because this kind of mistakes do not really fill the user with trust... an admin can simply change the entire website for anything they want... also, what if the admin does want to have some javascript in that message, etc? (In reply to Itamar Heim from comment #3) > an admin can simply change the entire website for anything they want... > also, what if the admin does want to have some javascript in that message, > etc? Is this a meant use case? If yes, we should probably document it at least in the engine-manage-domains help otherwise it looks like a bug. But in that case we should support it a bit better because it is not that simple to make a javascript executable nor to reference something external (like an image). (In reply to Itamar Heim from comment #3) > an admin can simply change the entire website for anything they want... > also, what if the admin does want to have some javascript in that message, > etc? I agree with Itamar. It looks like you need to be highly privileged to perform the attack and when you are, you have other means to do the same (or even worse things). (In reply to Petr Matousek from comment #5) > (In reply to Itamar Heim from comment #3) > > an admin can simply change the entire website for anything they want... > > also, what if the admin does want to have some javascript in that message, > > etc? > > I agree with Itamar. It looks like you need to be highly privileged to > perform the attack and when you are, you have other means to do the same (or > even worse things). So, what the outcome from this discussion is? - is it a bug not worth fixing because the consequences are too small? - is it a bug worth fixing because the fix is a one liner and it is simply not correct to trust that string? - is it a feature and so we will document it? - will we let it as an undocumented feature? (In reply to Tomas Jelinek from comment #6) > So, what the outcome from this discussion is? I solely commented on the potential security impact this issue might have. Alexander, IMHO change-id I6c78c9e6d6dc9417e22c71dab66ae4507ea5c191 [1] should handle these issues , am I correct? [1] http://gerrit.ovirt.org/#/c/24282/ http://gerrit.ovirt.org/#/c/24006/ Yair, Yes I created those patches specifically to stop any potential XSS attacks. The application should not trust anything coming from an external resource (in this case the database is an external resource). If the XSS exists after those patches are applied, then that is a bug that should be fixed. I am going to test right now if master still shows this behaviour. Yair, I just confirmed that those patches do solve the XSS vulnerability and they have been backported to 3.4 already. So we can move this to modified after I add the links to the patches to this bug? (In reply to Alexander Wels from comment #10) > Yair, > > I just confirmed that those patches do solve the XSS vulnerability and they > have been backported to 3.4 already. So we can move this to modified after I > add the links to the patches to this bug? Yes please Setting target release to current version for consideration and review. please do not push non-RFE bugs to an undefined target release to make sure bugs are reviewed for relevancy, fix, closure, etc. Verified in ovirt-engine-userportal-3.4.0-0.11.beta3.el6.noarch. Image is not dispalyed, tags gets escaped as: Cannot Login. User Password has expired. Use the following URL to change the password: http://%22%3E%3C/a%3E <img src="http://www.empireonline.com/images/uploaded/chuck-norris-uzis.jpg" /> <a href="" this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released |
