Bug 470989 - (CVE-2008-5646) trac: security fixes in 0.11.2 (CVE-2008-5646, CVE-2008-5647)
trac: security fixes in 0.11.2 (CVE-2008-5646, CVE-2008-5647)
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-11 04:24 EST by Tomas Hoger
Modified: 2013-01-09 23:55 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-23 22:48:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2008-11-11 04:24:08 EST
Secunia reports in SA32652:

  http://secunia.com/advisories/32652/

  Some vulnerabilities have been reported in Trac, which can be exploited by
  malicious people to cause a DoS (Denial of Service) or to conduct phishing
  attacks.

  1) An unspecified error in the HTML sanitiser filter can be exploited to
  conduct phishing attacks.

  2) An unspecified error when processing wiki markup can be exploited to cause
  a DoS.

  The vulnerabilities are reported in versions prior to 0.11.2.

  Solution:
  Update to version 0.11.2.

Upstream changelog:
http://trac.edgewall.org/wiki/ChangeLog#a0.11.2
Comment 1 Tomas Hoger 2008-11-11 04:28:02 EST
Upstream patches:

1) http://trac.edgewall.org/changeset/7658/branches/0.11-stable
   (use of html sanitize in 0.10.x seems to be a bit different)

2) http://trac.edgewall.org/changeset/7657/branches/0.11-stable
   (in 0.10.x, affected code is in trac/wiki/formatter.py)
Comment 2 Tomas Hoger 2008-12-18 05:19:17 EST
CVE ids assigned to these issues:

CVE-2008-5647:
Unspecified vulnerability in the HTML sanitizer filter in Trac before
0.11.2 allows attackers to conduct phishing attacks via unknown attack
vectors.

CVE-2008-5646:
Unspecified vulnerability in Trac before 0.11.2 allows attackers to
cause a denial of service via unknown attack vectors related to
"certain wiki markup."
Comment 3 Vincent Danen 2010-04-21 17:44:39 EDT
Current Fedora provides trac 0.11.7.  EPEL4, however, provides 0.9.3, while EPEL5 provides 0.10.5.

Do we have no intention to correct this EPEL at all?  Fedora is taken care, but EPEL would still be vulnerable.
Comment 4 Jesse Keating 2010-04-21 18:41:29 EDT
Hrm, taking another look, there doesn't seem to be an upstream fix for 0.9.x, so this would take some backporting, which is beyond the time I have right now.
Comment 5 Jesse Keating 2010-04-21 18:53:24 EDT
IN fact, looking at the issues, I'm not finding similar code in the 0.9.x sets, so I'm not so sure these effect 0.9.x.  Do you have other data?
Comment 6 Vincent Danen 2010-04-21 20:55:03 EDT
I haven't really looked to see if this affects 0.9.x, but it doesn't look as though it's at all supported upstream any longer, so even if it did, I doubt upstream would put much effort into it.

Considering how dated it is, and that that series is no longer supported upstream, is it feasible to update EPEL4 to what EPEL5 provides (0.10.x)?  At least that series is still supported.

I don't know how serious this is, so if worse comes to worse and we can't update to 0.10.x in EPEL4, I'd be tempted to just WONTFIX it there.  If the code isn't similar, then perhaps this is not an issue there.  I don't know that anyone ever tested against such an old release, or it could be new code in 0.10.x.
Comment 7 Jesse Keating 2010-04-21 21:58:54 EDT
I'm pretty sure a change from 0.9.x to 0.10.x would require on-disk format changes, just like 0.10 to 0.11, and that's something I'd avoid on EPEL.  I think it's safe to CLOSE-NOTABUG as the effected code doesn't seem to exist in 0.9.x, until somebody cares enough to point out the flaw still exists.

I'd be surprised if anybody is still using trac on EL4 in any public fashion, the feature set of newer releases is just much better, and requires newer python, and thus newer RHEL.  So close how you will, but I won't be touching EL-4 for this matter.  Thanks!
Comment 8 Vincent Danen 2010-04-22 10:29:59 EDT
I can close it after EPEL5 is updated.  =)  You still intend to do that, I'm assuming?
Comment 9 Jesse Keating 2010-04-22 14:46:45 EDT
Damn, I thought I was getting way easy.  So, I looked at this in the context of 0.10.x, and the wiki formatter one is pretty easy to fix, I ported the patch from 0.11.  The sanitizer looks much more difficult, as the parser used for sanitation is from a completely different module, well sortof.  In 0.10.x trac makes use of HTMLParser directly from python, but in 0.11.x it makes use of HTMLParser by way of genshi, which modifies python's version of the same.  Since the vulnerability is unspecified, I don't know if it's in the content from python, or the modifications genshi has made to it.  Add to that the "fix" would involve starting to use genshi, which could go terribly terribly wrong.

Do we have any more information about the flaw, and where it lives, and if 0.10.x and it's use of HTMLParser directly is effected?
Comment 10 Vincent Danen 2010-04-22 15:40:35 EDT
The formatter is with this patch?

http://trac.edgewall.org/changeset/7207/branches/0.10-stable/trac/wiki/formatter.py

I can't see any fixes to 0.10.x for the phishing issue, but I'm wondering if we could backport the sanitize_css function (or relevant parts of it) into Markup.sanitize() in util/html.py.  That's what's getting called to do the cleanup anyways.

I also think out of the two issues, the phishing one is the less severe.

But I can't see much other information.  Looking at the Markup.sanitize() function, it looks like css element 'position' is the problematic one (also looks to be checking for safe URIs and an 'expression' value).
Comment 11 Jesse Keating 2010-04-22 18:07:04 EDT
(In reply to comment #10)
> The formatter is with this patch?
> 
> http://trac.edgewall.org/changeset/7207/branches/0.10-stable/trac/wiki/formatter.py

No, there are changes beyond that to be backported.  0.10.x is dead upstream so there haven't been anything committed in ages.

> 
> I can't see any fixes to 0.10.x for the phishing issue, but I'm wondering if we
> could backport the sanitize_css function (or relevant parts of it) into
> Markup.sanitize() in util/html.py.  That's what's getting called to do the
> cleanup anyways.

I don't think we can without pulling in genshi
> 
> I also think out of the two issues, the phishing one is the less severe.
> 
> But I can't see much other information.  Looking at the Markup.sanitize()
> function, it looks like css element 'position' is the problematic one (also
> looks to be checking for safe URIs and an 'expression' value).    

I honestly don't think I can fix this without making things worse than they are now.  I'm more inclined to fix the DOS issue and leave this one alone.
Comment 12 Vincent Danen 2010-04-22 19:03:59 EDT
(In reply to comment #11)
> (In reply to comment #10)
> > The formatter is with this patch?
> > 
> > http://trac.edgewall.org/changeset/7207/branches/0.10-stable/trac/wiki/formatter.py
> 
> No, there are changes beyond that to be backported.  0.10.x is dead upstream so
> there haven't been anything committed in ages.

Oh, ok.  Glad you caught that, I was looking at the note in comment #1.

> > I can't see any fixes to 0.10.x for the phishing issue, but I'm wondering if we
> > could backport the sanitize_css function (or relevant parts of it) into
> > Markup.sanitize() in util/html.py.  That's what's getting called to do the
> > cleanup anyways.
> 
> I don't think we can without pulling in genshi

I imagine we could, but it might be quite painful.

> > I also think out of the two issues, the phishing one is the less severe.
> > 
> > But I can't see much other information.  Looking at the Markup.sanitize()
> > function, it looks like css element 'position' is the problematic one (also
> > looks to be checking for safe URIs and an 'expression' value).    
> 
> I honestly don't think I can fix this without making things worse than they are
> now.  I'm more inclined to fix the DOS issue and leave this one alone.    

Of the two, the DoS is the worst.  The sanitizing to prevent phishing would be nice, if it was realistic to put in the time and effort.  Given that, I'm ok with just fixing the DoS.
Comment 13 Fedora Update System 2010-05-28 17:15:01 EDT
trac-0.10.5-3.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/trac-0.10.5-3.el5

Note You need to log in before you can comment on or make changes to this bug.