vulnerability on SMF forums | Bitcointalksearch.org

ldrgn

member

Activity: 118

Merit: 10

Quote from: dree12 on January 29, 2013, 10:26:26 AM

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.

dree12

legendary

Activity: 1246

Merit: 1076

Quote from: 🏰 TradeFortress 🏰 on January 29, 2013, 08:33:53 PM

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.

🏰 TradeFortress 🏰

vip

Activity: 1316

Merit: 1043

👻

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

theymos

administrator

Activity: 5222

Merit: 13032

Quote from: dree12 on January 29, 2013, 10:26:26 AM

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.

dree12

legendary

Activity: 1246

Merit: 1076

Quote from: theymos on January 29, 2013, 04:05:59 AM

Quote from: 🏰 TradeFortress 🏰 on January 29, 2013, 03:53:43 AM

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

administrator

Activity: 5222

Merit: 13032

Quote from: 🏰 TradeFortress 🏰 on January 29, 2013, 03:53:43 AM

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.

🏰 TradeFortress 🏰

vip

Activity: 1316

Merit: 1043

👻

Quote from: theymos on January 29, 2013, 03:16:59 AM

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

administrator

Activity: 5222

Merit: 13032

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.

theymos

administrator

Activity: 5222

Merit: 13032

inbox informed me of this previously and I fixed it.

Raize

donator

Activity: 1419

Merit: 1015

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.

deepceleron

legendary

Activity: 1512

Merit: 1032

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

Quote

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

and

Quote

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

greyhawk

hero member

Activity: 952

Merit: 1009

I for one welcome our new overlords.

apetersson

hero member

Activity: 668

Merit: 501

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/

Topic: vulnerability on SMF forums (Read 8371 times)