Edgewall Software
Modify

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#4049 closed defect (fixed)

CSRF vulnerabilities in trac

Reported by: dkg-debian.org@… Owned by: jonas
Priority: high Milestone: 0.10.2
Component: general Version: 0.10
Severity: critical Keywords: CSRF security
Cc: dkg-debian.org@…
Release Notes:
API Changes:

Description

Despite [1701], trac appears to still be vulnerable to a fairly widespread class of Cross Site Request Forgery attacks.

These attacks require minimal action by the user: All the user needs to do is:

  1. be logged into a targeted trac installation, and
  2. visit a malicious remote web site (or click a malicious remote link) with the same browser

Because these attacks make use of the browsers' cached credentials, and they are launched from the browser (not from the malicious remote site), firewalls and other perimeter restrictions are not useful against them.

I've put a demonstration of this attack up here, along with details of how trac might be modified to protect against such an attack.

Please let me know if i can be of any help fixing this.

Attachments (6)

trac-csrf.patch (3.0 KB) - added by jonas 7 years ago.
A proof of concept patch for trunk
trac-csrf.2.patch (2.9 KB) - added by jonas 7 years ago.
An updated version of the patch
trac-csrf.3.patch (2.9 KB) - added by jonas 7 years ago.
A safer and cleaner version of the patch.
trac-0.10-csrf.patch (4.9 KB) - added by jonas 7 years ago.
A version for 0.10-stable, by far not as elegant.
trac-0.10-csrf.2.patch (5.1 KB) - added by jonas 7 years ago.
An updated version of the 0.10-stable patch.
trac-0.10-csrf.3.patch (5.1 KB) - added by jonas 7 years ago.
An updated version of the 0.10-stable patch.

Download all attachments as: .zip

Change History (33)

comment:1 Changed 7 years ago by dkg-debian.org@…

Assuming the conditions above are met, the remote malicious site can perform any actions on the targeted trac installation that the browsing user is authorized to do. I believe this is a serious security concern.

comment:2 Changed 7 years ago by dkg-debian.org@…

I should add that i've tried this and tested it successfully using a fairly standard Firefox 1.5 installation, and konqueror 3.5.5, on a different trac installation. The exploit was tuned to the other installation.

I just made a couple changes to the exploit to make it function with this trac installation so that it is more apparent. If you tried it already but it failed and you want to see it in action, refresh the linked page (perhaps with your cache cleared).

sigh. even my bug reports have bugs!

comment:3 Changed 7 years ago by anonymous

  • Keywords security added
  • Priority changed from normal to high
  • Severity changed from normal to critical
  • Summary changed from CSRF vulnerabilities in trac to Test Ticket for CSRF on Trac

I got burned by this exploit.

comment:4 Changed 7 years ago by cmlenz

I got burned by this exploit.

comment:5 Changed 7 years ago by cboos

  • Summary changed from Test Ticket for CSRF on Trac to CSRF vulnerabilities in trac

I got burned by this exploit.

comment:6 Changed 7 years ago by dkg-debian.org@…

OK, that's two more: Firefox/2.0 and Safari/419.3

Let me know if you want me to take down the exploit itself.

comment:7 Changed 7 years ago by anonymous

I got burned by this exploit.

comment:8 Changed 7 years ago by anonymous

I got burned by this exploit.

comment:9 Changed 7 years ago by cboos

  • Milestone set to 0.10.1

Well, I've got the php source, so yes you can take it down ;)

As you said, there's nothing special to do in it… so this is indeed a bit scary.

comment:10 Changed 7 years ago by anonymous

I got burned by this exploit.

comment:11 Changed 7 years ago by dkg-debian.org@…

i've taken down the exploit

Changed 7 years ago by jonas

A proof of concept patch for trunk

comment:12 Changed 7 years ago by jonas

  • Status changed from new to assigned

The patch above automatically adds a form token to every method="post" form. The token generation might not be strong enough. It's probably better to use the session id instead of the username to build the token.

Changed 7 years ago by jonas

An updated version of the patch

Changed 7 years ago by jonas

A safer and cleaner version of the patch.

Changed 7 years ago by jonas

A version for 0.10-stable, by far not as elegant.

Changed 7 years ago by jonas

An updated version of the 0.10-stable patch.

comment:13 Changed 7 years ago by jonas

I've now committed trac-csrf.3.patch to trunk r4133.

The 0.10-stable version still needs more testing before we can commit anything to the stable branch.

Changed 7 years ago by jonas

An updated version of the 0.10-stable patch.

comment:14 Changed 7 years ago by dkg-debian.org@…

trac-0.10-csrf.3.patch seems to work when applied to 0.10 for me. my original exploit fails against it. Nice work, jonas.

comment:15 Changed 7 years ago by jonas

I've applied trac-0.10-csrf.3.patch to the 0.10-stable branch and upgraded t.e.o to get some good testing.

comment:16 Changed 7 years ago by ThurnerRupert

we get

 WARNING: 500 Internal Server Error (500 Internal Server Error
 (Missing or invalid form token Do you have cookies enabled?))

either caused by r4147, or r4145.

usually we have http://trac-hacks.org/wiki/AccountManagerPlugin enabled as well, and i thought it might be incompatible with that. trying to go back to

 trac.web.auth.LoginModule = enabled
 # acct_mgr.web_ui.LoginModule = enabled

had no effect. finally we did a roll back of the two changesets.

comment:17 Changed 7 years ago by jonas

Ok, I've committed an updated version of the CSRF patch uses a new cookie (trac_form_token) to keep trac of the token. The trac_session/auth cookie is no longer reused. I think this will solve the problem.

comment:18 Changed 7 years ago by ThurnerRupert

thanks a lot, now it works.

comment:19 Changed 7 years ago by ThurnerRupert <rupert.thurner@…>

  • Milestone changed from 0.10.2 to 0.10.1
  • Resolution set to fixed
  • Status changed from assigned to closed

shouldn't be this be closed, by #4153?

comment:20 Changed 7 years ago by ThurnerRupert <rupert.thurner@…>

i ment r4153

comment:21 Changed 7 years ago by cmlenz

Yeah, thanks.

comment:22 Changed 7 years ago by Shun-ichi Goto <shunichi.goto@…>

As side effect, #4122 is raised.

comment:23 Changed 7 years ago by dkg-debian.org@…

For those who upgraded to trac 0.10.1 to work around this bug and you are using an authz file, you probably need to apply [4201] and [4207] to your trac install to avoid #3996.

comment:24 follow-up: Changed 7 years ago by cboos

  • Resolution fixed deleted
  • Status changed from closed to reopened

Well, using the HTMLParser has its limits… see e.g. http://dog4.dyndns.org:8080/trac/wiki/AxisAngleRotation (picked from a conversation on IRC).

There, simply viewing a wiki page fails because the LaTeX formula plugin probably returns some invalid HTML.

What about adding explicitely the <input type="hidden" name="__FORM_TOKEN" value=<?cs var:__FORM_TOKEN ?>"> element in all the forms, instead of using the injector?

That would be a one time fix, as existing ClearSilver templates won't evolve anymore. Same goes for plugins, the few requiring POSTs could be easily adapted.

comment:25 in reply to: ↑ 24 Changed 7 years ago by eblot

  • Milestone changed from 0.10.1 to 0.10.2

Replying to cboos:

There, simply viewing a wiki page fails because the LaTeX formula plugin probably returns some invalid HTML.

Actually, 0.10.1 has triggered one HTML syntax issue in XmlRpcPlugin, another one in GraphvizPlugin.

comment:26 follow-up: Changed 7 years ago by jonas

  • Resolution set to fixed
  • Status changed from reopened to closed

As far as I know the XmlRpcPlugin? issue was about FORM_TOKEN validation and not HTML syntax. This should be fixed in 0.10-stable already.

The GraphvizPlugin? issue is both invalid HTML and invalid XHTML so I guess they will need to find some other way to do this. IMHO it's not important enough to block the 0.10.2 release.

comment:27 in reply to: ↑ 26 Changed 7 years ago by eblot

Replying to jonas:

The GraphvizPlugin? issue is both invalid HTML and invalid XHTML so I guess they will need to find some other way to do this. IMHO it's not important enough to block the 0.10.2 release.

+1.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The owner will remain jonas.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from jonas to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.