vulnerability on SMF forums

[apetersson]

i have not looked in-depth into this, but this might be relevant:

http://www.reddit.com/r/netsec/comments/178z09/admin_password_reset_in_all_versions_of_simple/
http://raz0r.name/vulnerabilities/simple-machines-forum/

[1714170927]

1714170927

[1714170927]

1714170927

[1714170927]

1714170927

[1714170927]

1714170927

[1714170927]

1714170927

[1714170927]

1714170927

[greyhawk]

I for one welcome our new overlords.

[deepceleron]

Official response: http://www.simplemachines.org/community/index.php?topic=495809.0 - delete the bug report.

I moved a topic like this before. Removed content and lock. Refrain from posting a topic like this again.

and

Hello Raz0r,

> This time I found a more interesting vulnerability however at Positive Technologies we didn’t manage to raise awareness of SMF developers.

May I ask you when did you send the report?

Raz0r, 26. Янвapь 2013, 1:57

Hello! We sent it in August 2012

[Raize]

GD it. I just tested this on one of my lower-traffic forums. It is a real exploit. It does require some programming skill to exploit, but it's a very real threat unfortunately. It's actually easier to do on SMF 1.X than 2.X, but it still requires a boatload of custom programming. Basically it comes down to attempting a ton of hex codes.

The faulty code is this:

Code:

if (empty($_POST['code']) || substr($realCode, 0, 10) != substr(md5($_POST['code']), 0, 10))

It should be found in /Sources/Reminder.php, though the line # is going to vary based on mods. Changing it to !== should do the trick, as one of the redditors pointed out.

Just FYI, it's always better to PM theymos with these sorts of things so he can apply custom patches/edits. Making a thread about it does increase the likelihood it will be patched, but it kind of assists anyone wanting to target this forum in particular.

[theymos]

inbox informed me of this previously and I fixed it.

[theymos]

I'm sure there are more exploits like this. SMF was not carefully designed. Authentication stuff is spread all over the place.

I found another possible vulnerability a while ago (and fixed it here), though it'd be very difficult to exploit. When the session ID is compared to the one in the database, the comparison ends at the first differing character. So a session ID that is partially correct takes longer to be rejected than one that is entirely incorrect. I was able to measure a noticeable time difference, but the difference is small enough that the attack may be impractical.

[🏰 TradeFortress 🏰]

I'm sure there are more exploits like this. SMF was not carefully designed. Authentication stuff is spread all over the place.

I found another possible vulnerability a while ago (and fixed it here), though it'd be very difficult to exploit. When the session ID is compared to the one in the database, the comparison ends at the first differing character. So a session ID that is partially correct takes longer to be rejected than one that is entirely incorrect. I was able to measure a noticeable time difference, but the difference is small enough that the attack may be impractical.

Really?

Did the SMF devs loop through every single character and compare them individually?

[theymos]

Really?

Did the SMF devs loop through every single character and compare them individually?

Not explicitly, but that's what happens when you compare strings normally.

[dree12]

Really?

Did the SMF devs loop through every single character and compare them individually?

Not explicitly, but that's what happens when you compare strings normally.

How would you circumvent this? Perhaps compare the remaining characters anyways, even though it's not computationally optimal? Store a hash of the session id instead of the actual session id?

[theymos]

How would you circumvent this? Perhaps compare the remaining characters anyways, even though it's not computationally optimal? Store a hash of the session id instead of the actual session id?

Those are both good solutions. The easiest way, which I did, is to hash each side of the comparison before comparing.

[🏰 TradeFortress 🏰]

Perhaps === in PHP should compare the remaining characters anyways in cause of a failure.

[dree12]

Perhaps === in PHP should compare the remaining characters anyways in cause of a failure.

That would be inconsistent in a short-circuited language. If I'm not mistaken, the following in PHP:

Code:

1 && ($var = 1);
if (isset($var)) echo "Set.";
else echo "Unset.";

produces the output:

Code:

Unset.

String comparison should also be similarly short-circuited for consistency's sake.

[ldrgn]

How would you circumvent this? Perhaps compare the remaining characters anyways, even though it's not computationally optimal? Store a hash of the session id instead of the actual session id?

This is called a timing attack and the usual way to beat it is to subtract the two hashes and test to see if the result is zero.