CSRF vulnerabilities in trac

[dkg-debian.org@…]

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.

[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.

[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!

[anonymous]

I got burned by this exploit.

[cmlenz]

I got burned by this exploit.

[cboos]

I got burned by this exploit.

[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.

[anonymous]

I got burned by this exploit.

[anonymous]

I got burned by this exploit.

[cboos]

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.

[anonymous]

I got burned by this exploit.

[dkg-debian.org@…]

i've taken down the exploit

[jonas]

A proof of concept patch for trunk

[jonas]

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.

[jonas]

An updated version of the patch

[jonas]

A safer and cleaner version of the patch.

[jonas]

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

[jonas]

An updated version of the 0.10-stable patch.

[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.

[jonas]

An updated version of the 0.10-stable patch.

[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.

[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.

[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.

[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.

[ThurnerRupert]

thanks a lot, now it works.

[ThurnerRupert <rupert.thurner@…>]

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

[ThurnerRupert <rupert.thurner@…>]

i ment r4153 …

[cmlenz]

Yeah, thanks.

[Shun-ichi Goto <shunichi.goto@…>]

As side effect, #4122 is raised.

[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.

[cboos]

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.

[eblot]

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.

[jonas]

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.

[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.