Jump to content

Release security patches outside of normal release schedule


insectdude

Recommended Posts

Over 3 weeks ago, on 23 September, I reported a critical cross-site scripting bug involving the %7Boption%7D tag that allowed any user to inject arbitrary Javascript into a post that would be executed when the page was viewed.

A fix was created for this shortly afterwards and incorporated into the upcoming 3.2.3 release. At the time I asked for details of the fix to be posted so that I could manually patch my board. I never got a response. I asked Matt directly on Twitter too, and was told the fix was included in the latest pre-release build (which is of no use of course, as I'm not about to install pre-release software on my live site).

I thought at the time that the 3.2.3 release was imminent, but it still hasn't been released. I understand and agree with not rushing releases out until you are confident they are stable. But security patches should be dealt with separately, they cannot wait for the regular release cycle.

A quick Google just now for some obvious keywords revealed someone else detailing a variant of the same exploit, this time involving the [twitter] tag. It doesn't work here on 3.2.3, but does work on my live 3.2.2 board.

So there are now at least two publicly-known XSS flaws in the current release of IPB. By not releasing a patch you are leaving all your customers' sites vulnerable. Please correct this.

(By the way, if anyone is wondering why they can't see my original bug report in the tracker, it was marked as private - the details had already been reposted on at least one other site by the time this happened though.)

Link to comment
Share on other sites

  • Management

Thanks for bringing this up.

I am aware of the issue you reported and I fixed it that same day. We do take XSS seriously although we do take precautions against this type of attack. For those that don't know, XSS allows someone to inject malicious javascript code into the page HTML. This type of attack is usually used to extract cookies or to redirect the user to a page they didn't specify.

How IP.Board protects against XSS in the core

  • We make use of HTTP only cookies in IP.Board, so the session, member_id and member_hash cookies are not readable by javascript. This drastically reduces the risk of XSS being used fake a session or to be used to log in as the user.
  • We make use of IP address and user-agent matching to further reduce the ability of a hacker to fake a session or to gain access.
  • We use a MD5 key that is unique to each user to validate forms that are posted (log in / log out / post reply / moderation tasks). This means that unless the hacker knows your MD5 key, they cannot force you to perform an action without your implicit knowledge.

These things work in the core to protect you against basic XSS attacks and means that any XSS attack possible has a diminished affect. You can still 'break' the page layout via XSS by manipulating the DOM and force alert messages to annoy users, but any real damage to your board is almost entirely superficial.

Now, we generally patch and release updates for any XSS spotted as soon as they are reported. In this case, however, the fix was quite involved. I actually re-worked how entities are encoded and displayed in IP.Board for 3.2.3 to overcome many different issues including this particular bug you posted. This means that the fix is very involved and would mean many different file edits that is almost beyond the scope of a quick security update.

When I fixed the issue and replied to your bug report, the release of 3.2.3 was only a few days away. However, we decided to delay it for a few more weeks to really iron out all the reported issues. This has meant that the fix for this issue has been pushed back with the release but up until very recently it was not a published attack and as mentioned in this post, the affect is greatly diminished.

The fix has been in 3.2.3 Beta since its first release and we did mention that to you and I believe a few others who have asked. We are aiming for a full release of 3.2.3 early this week which completely resolves this issue.

We have continually monitored this situation and we do take security very seriously.
Link to comment
Share on other sites

You can still 'break' the page layout via XSS by manipulating the DOM and force alert messages to annoy users, but any real damage to your board is almost entirely superficial.



You can also redirect the user to an externally-hosted phishing page designed to look like the real site's login page, asking the user to login again. If users fall for that - and I bet many would - all the protections are rendered meaningless as the attacker can simply login with the user's details.

To my mind, this issue was serious enough to warrant releasing as an emergency fix once you realised 3.2.3 was going to be delayed. If that meant releasing 3.2.3 as it stood, making clear that 3.2.4 would be following shortly afterwards so that those who dislike frequent upgrades could wait, then so be it.

The fix being available in the beta release doesn't really help since:

1) there is no upgrade path from the beta to the final release
2) installing the beta would render the board unsupported

No sensible admin is going to install a beta in light of those issues. Your pre-release section has very prominent warnings against doing such a thing in fact.

I am glad to hear that the 3.2.3 release is due very soon though.
Link to comment
Share on other sites


You can also redirect the user to an externally-hosted phishing page designed to look like the real site's login page, asking the user to login again. If users fall for that - and I bet many would - all the protections are rendered meaningless as the attacker can simply login with the user's details.



To my mind, this issue was serious enough to warrant releasing as an emergency fix once you realised 3.2.3 was going to be delayed. If that meant releasing 3.2.3 as it stood, making clear that 3.2.4 would be following shortly afterwards so that those who dislike frequent upgrades could wait, then so be it.



The fix being available in the beta release doesn't really help since:



1) there is no upgrade path from the beta to the final release


2) installing the beta would render the board unsupported



No sensible admin is going to install a beta in light of those issues. Your pre-release section has very prominent warnings against doing such a thing in fact.



I am glad to hear that the 3.2.3 release is due very soon though.




3.2.3 in fact is out now although it hasn't been announced. It's available from the client area so I assume it's the release version.

3DKiwi
Link to comment
Share on other sites

  • 2 weeks later...
  • Management

The secure hash isn't the users pass hash or member key. To use CSFR you need a blind attack, you wouldn't be able to scrape the page first.

The session key on its own is of limited use. You'd need to execute JavaScript on the page to read it.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...