|
|
|
|
Bitcoin mining is now a specialized and very risky industry, just like gold mining. Amateur miners are unlikely to make much money, and may even lose money. Bitcoin is much more than just mining, though!
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
greyhawk
|
|
January 25, 2013, 03:37:38 PM |
|
I for one welcome our new overlords.
|
|
|
|
deepceleron
Legendary
Offline
Activity: 1512
Merit: 1028
|
|
January 26, 2013, 03:16:53 PM |
|
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
Donator
Legendary
Offline
Activity: 1419
Merit: 1015
|
|
January 29, 2013, 06:49:38 AM |
|
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: 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
Administrator
Legendary
Offline
Activity: 5194
Merit: 12972
|
|
January 29, 2013, 07:06:59 AM |
|
inbox informed me of this previously and I fixed it.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
theymos
Administrator
Legendary
Offline
Activity: 5194
Merit: 12972
|
|
January 29, 2013, 07: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.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
🏰 TradeFortress 🏰
Bitcoin Veteran
VIP
Legendary
Offline
Activity: 1316
Merit: 1043
👻
|
|
January 29, 2013, 07:53:43 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
Legendary
Offline
Activity: 5194
Merit: 12972
|
|
January 29, 2013, 08:05:59 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.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
dree12
Legendary
Offline
Activity: 1246
Merit: 1077
|
|
January 29, 2013, 02:26:26 PM |
|
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
Legendary
Offline
Activity: 5194
Merit: 12972
|
|
January 29, 2013, 02:41:10 PM |
|
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.
|
1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
|
|
|
🏰 TradeFortress 🏰
Bitcoin Veteran
VIP
Legendary
Offline
Activity: 1316
Merit: 1043
👻
|
|
January 30, 2013, 12:33:53 AM |
|
Perhaps === in PHP should compare the remaining characters anyways in cause of a failure.
|
|
|
|
dree12
Legendary
Offline
Activity: 1246
Merit: 1077
|
|
January 30, 2013, 12:45:40 AM |
|
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: 1 && ($var = 1); if (isset($var)) echo "Set."; else echo "Unset.";
produces the output: String comparison should also be similarly short-circuited for consistency's sake.
|
|
|
|
ldrgn
Member
Offline
Activity: 118
Merit: 10
|
|
January 30, 2013, 03:52:46 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.
|
|
|
|
|