Attention: SMF bug warning - CLOSED

[TrinitronX]

After a recent search on secunia, I realized that the forum software is currently vulnerable to a session fixation bug.  It's still unpatched as of now, but there is a workaround.  It's probably a good idea to make sure people don't click on forum links given by others which set a PHPSESSID parameter.

Read more about it and the workaround here: http://www.majorsecurity.de/index_2.php?ma...rls=major_rls47

(VaKo: +5 for reporting this)

[Sparda]

That requires minor social engineering. The Microsoft style fix is to just set the param to blank every time the script runs. This of course forces the need for cookies.

[VaKo]

Ok, I'll have a look at applying the workaround. Exactly how serious is this?

[Sparda]

Ok, I'll have a look at applying the workaround. Exactly how serious is this?

All that's at stake is forum accounts, and you can't change some ones password with this flaw. So some one might pretend to be some one else in a couple of posts. I dought any one on this forum will fall for it now it's been broth to attention.

[VaKo]

We've been caught with our pants down before though. This is in the 1.1.3 patch thats due soon but I'm interested in applying the work around as a temporary fix. Just need to work out where the code goes now.

[Shaun]

Yes. Anyway, I recommend people click on this link and login there (won't work if you already have a cookie set with a PHPSESSID for this domain, so make sure you clear those first).

[VaKo]

"If someone logs in straight after clicking that link and they have cookies disabled then anyone else who clicks that link will be logged in as them."

[TrinitronX]

[me=TrinitronX]clicks on link and logs in... oh no!  you tricked me :P[/me]

Just figured I'd make this known, even though it's not an extreme red alert type issue.  Lately I've been getting interested in PHP and web security for my new job coding in PHP.

[VaKo]

I should have a patch for this sometime on friday.

[digip]

People could get duped into this, say with a DiGG re-direct, but how serious is this. So many people log on, how would you direct an attack to get a specific users session? It seems almost like a crap shoot to get the person your targetting, even if there is a flaw based on the current release. Just curious, but has anyone even had their session taken over yet? Or taken someone else's?

[VaKo]

http://secunia.com/advisories/25139/

[digip]

http://secunia.com/advisories/25139/

Probably a dumb question, but what about the other advisories at the bottom of that page...

[Shaun]

Probably a dumb question, but what about the other advisories at the bottom of that page...

Those aren't in 1.1.2.

[VaKo]

http://secunia.com/product/5285/?task=advisories

This has been added, we should be ok. Beyond this, i need to learn more about how this works. If someone could expand on the subject it would be useful.

if ( ! isset( $_SESSION['SERVER_GENERATED_SID'] ) ) {

session_destroy(); // destroy all data in session

}

session_regenerate_id(); // generate a new session identifier

$_SESSION['SERVER_GENERATED_SID'] = true;

[Shaun]

How what works? The vulnerability or the patch?

[VaKo]

Well the patch seems to destroy all session data if it didn't generate the session ID. And as far as I can tell the session vulnerability is limited to people who relie on session id's instead of cookies to use the forums. So if you login to the server using a session ID someone else tricks you into using, the other person can use that same link to take over you account and post messages. But since you need your password to change login details you can't do much more than impersonate someone and read there PM's.

[Shaun]

Well the patch seems to destroy all session data if it didn't generate the session ID. And as far as I can tell the session vulnerability is limited to people who relie on session id's instead of cookies to use the forums. So if you login to the server using a session ID someone else tricks you into using, the other person can use that same link to take over you account and post messages. But since you need your password to change login details you can't do much more than impersonate someone and read there PM's.

Yes, although the session ID is what's in the cookie, so they still rely on session IDs, just not in the URL. The patch creates a new session if the current session doesn't have the variable SERVER_GENERATED_SID set to something that evaluates as true, that's an arbitrary variable name which sessions now have to have set, obviously if someone just makes up a session ID it won't have had that variable set so the forum won't use it.

[Deveant]

Well the patch seems to destroy all session data if it didn't generate the session ID. And as far as I can tell the session vulnerability is limited to people who relie on session id's instead of cookies to use the forums. So if you login to the server using a session ID someone else tricks you into using, the other person can use that same link to take over you account and post messages. But since you need your password to change login details you can't do much more than impersonate someone and read there PM's.

though they will also gain the same permisions as u, so depending on the Board, the *may* get admin panel access (though normaly requirs password again), and they have permisiion to delete and lock all topics as well as see hiden. (can cause trobles).