Advanced search  

News:

cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.
[more]

Pages: [1]   Go Down

Author Topic: 1.4.21 update does *not* fix the CSRF hole!  (Read 2023 times)

0 Members and 1 Guest are viewing this topic.

Mreimer

  • Coppermine newbie
  • Offline Offline
  • Posts: 1
1.4.21 update does *not* fix the CSRF hole!
« on: March 18, 2009, 05:20:52 pm »

Hello,

I'm searching for a gallery application to host a photo gallery for a open source project. The first thing, I look at, are the last few security patches, and so I came to your 1.4.21 update and the linked exploit.

You call the issue to be "serious", but the fix doesn't really fix the hole. In fact, you keep the hole open and just make it impossible to exploit it using the exploit, someone posted to milw0rm. It's trivial to do bad things with just a minimal change in the way, the hole gets exploited:

- The bad image URL could be placed into a HTML mail and sent to the admin.
- The bad image URL could be posted to some other web application, owned by the same admin (forum, blog, ...)

Just to clarify the issue with CSRF holes: The problem is *not*, that it's possible to place URLs or Images to a coppermine gallery. Those links or images could also be placed to somewhere else, where the chance, the admin visits them, is high. The problem is, that it's possible to do bad things, just by tricking the admin to visit URLs. This should be impossible. To get to the wikipedia link, you also have in your advisory: http://en.wikipedia.org/wiki/Cross-site_request_forgery#Prevention

I planned to use coppermine, as it seems to fit best for my needs, but if I see how you "fixed" (or not fixed) this hole, I'm getting unsure if this is a good idea. Did you know, that your fix doesn't close the hole? If so, why didn't you publish a real fix?
Logged

Nibbler

  • Guest
Re: 1.4.21 update does *not* fix the CSRF hole!
« Reply #1 on: March 18, 2009, 06:00:38 pm »

The real fix is too major for a point release. It will be in the next major release.
Logged

Joachim Müller

  • Dev Team member
  • Coppermine addict
  • ****
  • Offline Offline
  • Gender: Male
  • Posts: 47843
  • aka "GauGau"
    • gaugau.de
Re: 1.4.21 update does *not* fix the CSRF hole!
« Reply #2 on: March 19, 2009, 09:06:46 am »

We understand how the exploit works. As Nibbler pointed out: a real fix would mean that the way forms work in coppermine need to be made more secure. We have discussed this already both openly in other threads as well as privately among the devs (dev-only board). We're aware that the fix in cpg1.4.21 doesn't cure the initial vulnerability, but only doctors the symptoms. The likelihood of an attack decreases dramatically if it relies on a cross-media attack. Most email clients block images in emails, so it's less likely that an attack with a made-up HTML email will suceed. That's all we could do as a quick fix. In the long run, we'll close the vulnerability.

I planned to use coppermine, as it seems to fit best for my needs, but if I see how you "fixed" (or not fixed) this hole, I'm getting unsure if this is a good idea. Did you know, that your fix doesn't close the hole? If so, why didn't you publish a real fix?
Sounds very confrontational to me. Yes, we know. We haven't published a "real fix" because that takes time to come up with the fix, implement it, test it, package and release it. We're only human, and we do that in our spare time. Given that the exploit was published on milwOrm on 2009-02-26, we learned about it on 2009-02-27 and released cpg1.4.21 on 2009-03-04 that was pretty fast. If you think that you can do this any faster or if you have a working permanent fix, we're all ears. However, if you can not contribute, I suggest to review your attitude a bit.

Joachim
Logged
Pages: [1]   Go Up
 

Page created in 0.018 seconds with 19 queries.