Summary: | www-apps/horde: 3.x, 2.x, XSS vuln (CVE-2006-2195) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Raphael Marichez (Falco) (RETIRED) <falco> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | tcort, web-apps |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2195 | ||
Whiteboard: | B4 [glsa] Falco | ||
Package list: | Runtime testing required: | --- |
Description
Raphael Marichez (Falco) (RETIRED)
2006-06-14 15:43:26 UTC
I've made a patch, based off the Debian 3.1.1-3 patchset (where they fixed it) and checked Horde's CVS too for confirmation. Patch available at http://overlays.gentoo.org/dev/chtekk/browser/horde/www-apps/horde/files/horde-3.1.1-xss.diff?rev=4&format=txt Updated ebuild available at http://overlays.gentoo.org/dev/chtekk/browser/horde/www-apps/horde/horde-3.1.1-r1.ebuild?format=raw This also requires a minor change to the horde.eclass, since it patches test.php, in the horde.eclass test.php is chmod'ed 000 before the patches are applied, which leads epatch to fail with a permissions error. The simple solution is just to invert the order: first apply all needed patches, then chmod 000 test.php. Updated eclass can be found at http://overlays.gentoo.org/dev/chtekk/browser/horde/eclass/horde.eclass?format=raw Best regards, CHTEKK. Added vapier (the maintainer) to CC. Best regards, CHTEKK. Updated ebuild is in the tree as www-apps/horde-3.1.1-r1, ready to be marked stable. Best regards, CHTEKK. Thx Luca. Arches please test and mark stable. ppc stable sparc stable. stable on hppa x86 done alpha and amd64 stable. Heya it's done then, time to make a glsa decision. Find a voting booth and then insert your ballot in the urn : __|__ | | |___| I vote a half-yes-ballot and i won't be worried if you vote no. Unless we somehow agree to put a marker "web apps are generally unsafe" somewhere prominent and change policy accordingly, I vote 'yes', too, without enthusiasm, of course. > Unless we somehow agree to put a marker "web apps are generally unsafe"
> somewhere prominent and change policy accordingly,
that sounds a rather good idea as for me
Alternate solution (I _guess_ that's how it was done with phpBB) is to hardmask stuff that hits > n GLSAs per 3 months, where n needs to be determined. i hate XSS stuff - but we issued a GLSA for something like this in the past and debian issued an advisory, too: So i tend to a very weak yes here let's have a glsa then :( GLSA 200606-28 |