MCCodes v2.0.4 Released & Security Doc

[Dabomstew]

After a bit of a delay in programming & testing, MCCodes have finally released the v2.0.4 security & bugfix patch for MCCodes v2 users.

Also released is a security document, which allows users to fix the security problems which were fixed in 2.0.4 in their own games if they are heavily modified or not v2.

The changelog is attached to this post. The security advisory is available to ALL paying customers in their customer area, underneath the engine license section.

Please report bugs through our bug tracker, or here if you prefer (though reporting them to our official bug tracker is much better for us)

If you want to just place the 2.0.4 files over your (UNMODIFIED) 2.0.3 ones you can do so and have it function correctly by executing the following SQL queries:

 

INSERT INTO `settings` (`conf_name`, `conf_value`) VALUES('jquery_location', 'js/jquery-1.7.1.min.js');
ALTER TABLE `userstats` ADD PRIMARY KEY ( `userid` ) ;
ALTER TABLE `forum_posts` CHANGE `fp_text` `fp_text` TEXT CHARACTER SET latin1 COLLATE latin1_swedish_ci NOT NULL DEFAULT '';
ALTER TABLE `fedjail` ADD UNIQUE (`fed_userid`);
ALTER TABLE `users` ADD `pass_salt` VARCHAR( 8 ) CHARACTER SET latin1 COLLATE latin1_swedish_ci NOT NULL ;

 

This is highly unrecommended for all but those who are just starting out on their game, since you will lose all your mods.

changelog_204.txt

[Dabomstew]

We feel that we have to inform customers of the two engines which do not yet have a patch of the potential issues in their games. This is mainly why the security advisory was released. v2 users should download the new files and work from there.

The code does address a bit more than the security advisory does, I believe - though it was prepared with the changelog of the patch in mind.

If there are further security issues which neither the patch nor the advisory cover at all, we would very much like to hear them so follow-ups can be made.

EDIT: Also, contacting our entire customer base and waiting for a reply from every single customer would have seriously extended the time taken to release the patch. We therefore felt that this was not a practical option.

EDIT2: We have reconsidered slightly, and moved the security document to only be accessible to paying customers. The changelog is still public.

[H4x0r666]

I've readed the first attachment but after that,

the second attachment failed to open..?

http://makewebgames.io/attachment.php?attachmentid=280&d=1329568659 <-- o.0 ?

hmm

Edited February 18, 2012 by H4x0r666
Posting attachment url that failed to open

[Dabomstew]

Read above. The security notice has been moved to our customer area. If you have a license, it's just a few clicks away still.

[a_bertrand]

Congratulations for the release! Any security patch is welcome in my opinion ;)

[Mystical]

Probably a stupid question but is ?> not needed at the end of each file? Just asking because almost all of the files are missing it.

[Djkanna]

Probably a stupid question but is ?> not needed at the end of each file? Just asking because almost all of the files are missing it.

No it's not needed, in some cases it's also beneficial to omit the closing tag.

[Danny696]

INSERT INTO `settings` (`conf_name`, `conf_value`) VALUES('jquery_location', 'js/jquery-1.7.1.min.js');
ALTER TABLE `userstats` ADD PRIMARY KEY ( `userid` ) ;
ALTER TABLE `forum_posts` CHANGE `fp_text` `fp_text` TEXT CHARACTER SET latin1 COLLATE latin1_swedish_ci NOT NULL DEFAULT '';
ALTER TABLE `fedjail` ADD UNIQUE (`fed_userid`);
ALTER TABLE `users` ADD `pass_salt` VARCHAR( 8 ) CHARACTER SET latin1 COLLATE latin1_swedish_ci NOT NULL ;

Ok, Why not just use an external jquery file. Also, is there any check to see if the jQuery has been included, sometimes it may get deleted by accident, updated, down-dated, or a folder structure may cause it not too load?

Also, adding the users pass salt in their users table, doesnt make it as hard to hack. I did research this for my engine, as I did the same as yourself, I found that - of which sounds silly once you know - if they access to the games database, then they have access to the salt, so can just be added to the password when they are trying to convert it back to plain text.

[Neon]

Also, adding the users pass salt in their users table, doesnt make it as hard to hack. I did research this for my engine, as I did the same as yourself, I found that - of which sounds silly once you know - if they access to the games database, then they have access to the salt, so can just be added to the password when they are trying to convert it back to plain text.

Its still a salted hash though. Unless you have a rainbow table of that hash then your outta luck.

[Spudinski]

Its still a salted hash though. Unless you have a rainbow table of that hash then your outta luck.

 

@Neon

I think you're reading it wrong.

The salt, is stored alongside the password within the same table, within the same database, using the same user for authentication. 0_o,

Basically, once you know what hashing function the script uses(I'll guess md5 or sha1), your in(dictionary attack, basically).

@Danny:

But at that point, your better off just altering the database to suit your form of attack. I'm pretty sure MCCodes runs some database extracted content with PHP, or even if not, you could modify unfiltered database content like mail and inject an XSS worm into an admin's message to gain whatever you need.

The admin should have an HTML5 and Javascript compliant browser, so you could, theoretically, store all the admin's actions within a client-side database and simply use Ajax to send yourself a neat little message. Would take days if not weeks to discover the breach if you don't alter anything in an obvious manner.

But, also theoretically, one could just use MySQL to upload yourself a w4cking-c99 if they run with escalated user privileges. Wouldn't be very smart, but I've seen people owned using this method.

 

No it's not needed, in some cases it's also beneficial to omit the closing tag.

There's no "benefits" towards omitting the closing tag. It's purely preference.

The <?php & ?> tags(or more formally, escape characters) mean you are either escaping into or out of, PHP... similar to XML syntax.

If you do not plan on producing HTML/output after the PHP syntax, there is no need to escape out of PHP, some developers just think it's cleaner to use closing tags with each script.

On the other hand, C( # / ++ ) developers will omit it(eg. a_bertrand, see his scripts) simply because they're used to not having to escape their code.

PHP is designed this way, since it's original usage is within HTML, text, etc...

Edited February 18, 2012 by Spudinski

[sniko]

@Spud; What's w4cking-c99?

Good to see you've released a patch! Great stuff! I'm with Alain, a patch is welcome in my eyes!

[Spudinski]

@Spud; What's w4cking-c99?

Some rather long while ago, there was an InfoSec forum named W4cking. Members there made an improved version on the original C99 shell.

It's formally named "W4cking Shell", but w4cking-c99 is more descriptive.

Edit:

Ref: http://en.wikipedia.org/wiki/Shell_(computing)

Edited February 18, 2012 by Spudinski

[Djkanna]

[...]There's no "benefits" towards omitting the closing tag. It's purely preference.[...]

<?php
//Perhaps do some form of config/db/some other crap here...
$var = 123;
?>
<!--/Now the highlighter omits whitespace here, so lets just put a html comment. [imagine whitespace]-->

<?php
include ('include.php');
header('Location: tosomewhere.php');
?>

Pretty extreme and over used example, I understand not many will do such a thing, but as I said "[...]in some cases it's also beneficial to omit the closing tag.", this is one of those cases.

The PHP closing tag on a PHP document ?> is optional to the PHP parser. However, if used, any whitespace following the closing tag, whether introduced by the developer, user, or an FTP application, can cause unwanted output, PHP errors, or if the latter are suppressed, blank pages. For this reason, all PHP files should OMIT the closing PHP tag, and instead use a comment block to mark the end of file and it's location relative to the application root. This allows you to still identify a file as being complete and not truncated. --- Source: CodeIgniter.

Edited February 19, 2012 by Djkanna

[a_bertrand]

Salted MD5 or whatever other one way crypting technique does improve the security even if you know the salt. The reason is the following:

To "decrypt" an MD5 password (without salts) you need to have a table of all the possible MD5 and their results. Now of course all the possible one is... simply too big. So what you do is a huge list of common passwords and variations. With that you can decrypt common passwords and their variations. I did a test and I can tell you it's really not that difficult to setup. Now if you add a salt, instead of simply a password you will have something like "a text"+password, so unless your "decrypt" table uses as well the same salts you will not find anything back. Common MD5 decrypt sites works ONLY for pure strings not salted one (known or unkown salts). Therefore giving away the salt doesn't make it less secure. Anyhow you need to have a way to find back the salt, so anybody could read the code and find the salt or the salt algorithm you use. So that would change nothing.

Also, shall I point out that MD5 or SHA1 or SHA256 (or any other one way crypt function) will have exactly the same kind of issues against per-calculated tables. So choosing one over the other will not make you safe against such attacks. That's why using a salt is nearly mandatory.

As DJK said for the ending PHP tag, it has a couple of effects. Beside reducing a bit the size of the files and the time needed to parse them, the main real effect is that if you include a file which contains some non visible characters (tabs, spaces and returns) after the closing PHP tag, you may end up having them on your page. Normally it doesn't have much effect, yet if it's on a lib which you include before sending cookies or session, you could end up with an error message like "Warning: Cannot modify header information - headers already sent" therefore not closing the file do have little advantages.

[Spudinski]

Salted MD5 or whatever other one way crypting technique does improve the security even if you know the salt. The reason is the following:

To "decrypt" an MD5 password (without salts) you need to have a table of all the possible MD5 and their results. Now of course all the possible one is... simply too big. So what you do is a huge list of common passwords and variations. With that you can decrypt common passwords and their variations. I did a test and I can tell you it's really not that difficult to setup. Now if you add a salt, instead of simply a password you will have something like "a text"+password, so unless your "decrypt" table uses as well the same salts you will not find anything back. Common MD5 decrypt sites works ONLY for pure strings not salted one (known or unkown salts). Therefore giving away the salt doesn't make it less secure. Anyhow you need to have a way to find back the salt, so anybody could read the code and find the salt or the salt algorithm you use. So that would change nothing.

Also, shall I point out that MD5 or SHA1 or SHA256 (or any other one way crypt function) will have exactly the same kind of issues against per-calculated tables. So choosing one over the other will not make you safe against such attacks. That's why using a salt is nearly mandatory.

As DJK said for the ending PHP tag, it has a couple of effects. Beside reducing a bit the size of the files and the time needed to parse them, the main real effect is that if you include a file which contains some non visible characters (tabs, spaces and returns) after the closing PHP tag, you may end up having them on your page. Normally it doesn't have much effect, yet if it's on a lib which you include before sending cookies or session, you could end up with an error message like "Warning: Cannot modify header information - headers already sent" therefore not closing the file do have little advantages.

Salt: I think you're not getting the point.

If I know the salt, and I know the hashing algorithm, it's just the "bits in between" I need to figure out. It's not secure if the salt is revealed, even if you do quadrupole hashing.

Eg.: concat(x, 'mysalt') = '69c509c5b5a375a20c789caa3df2fb46'

All I'd have to do is compare sequences of alpnum characters to the hash.

match = (concat('helloworld', 'mysalt') == '69c509c5b5a375a20c789caa3df2fb46') ? true : false;

In my honest opinion, it's like giving the private encryption key of your data, and keep the rest "safe". It's not as secure as it could be.

PHP end tag:

A debate about 16 bits(assuming utf-8) or 2bytes of a file isn't worth it.

As for white space, see my post, I did say: "If you do not plan on producing HTML/output after the PHP syntax, there is no need to escape out of PHP".

[a_bertrand]

Salts or any other kind of security are nothing against dictionary or pure brute force attacks. Why? Simply because you could go via a script against the login page till you succeed to find the password. A salt provide security only against per-calculated tables like rainbow tables. So knowing the slat or not change little actually. Sure you could think that if you don't know the salt and don't know the algorithm you are more safe. Sure but how do you plan to do such thing on an engine you deliver to the public? The best solution then would be to a static salt stored in the config which is site specific + a salt per user. That may improve a bit the safeness if somebody hack the player table. But overall it's not adding all that much.

http://en.wikipedia.org/wiki/Salt_(cryptography)

For the end tag, never said it should be left off. I just said why it could help not having it there. Does it change much? No... but it could have some impact. Yet this has nothing to do with C#, Java or other kind of coders. Simply it's a code style you can adopt or not. Check what the zend framework code style says:

http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html

You like to close yourself the PHP? Fine. Simply there is a couple of advantages not closing it, where actually there is none closing it if there is nothing after the closing tag.

[Danny696]

For the end tag, never said it should be left off. I just said why it could help not having it there. Does it change much? No... but it could have some impact. Yet this has nothing to do with C#, Java or other kind of coders. Simply it's a code style you can adopt or not. Check what the zend framework code style says:

http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html

You like to close yourself the PHP? Fine. Simply there is a couple of advantages not closing it, where actually there is none closing it if there is nothing after the closing tag.

After reading that, I came across a comment;

 

Omitting the closing tag to prevent the accidental injection of trailing white space? When there is an opening tag, there is *always* a closing tag. That is how proper formatting is done. Zend is trying to solve a mere technical problem by breaking syntax. A very bad idea. And for crying out loud, how come there is a trailing white space? I have been writing php scripts for over 10 years now, since the days of php/fi. Trailing white space was never an issue for me. If it happened, I removed it. That's it. All you need is a good editor and a good ftp program. (BTW, proper editors can automatically remove trailing white spaces for you.)

So really, the end tag should be there, as adam said, for proper formatting.

[Dabomstew]

This discussion on ending tags has drifted away from the point of this topic, so I'll say this: The fact that there is no trailing ?> in the files is controlled by one line of code in our release builder. If you really want a copy of MCCodes v2 with a matching ?> for every <?php, contact us and we'll be happy to provide if you're a customer. Otherwise, it's rather irrelevant.

[Spudinski]

@alian:

hash: In theory, a login form should take longer to break than a simple hash. Assuming you know nothing about the username/email/possible passwords.

php: I think were actually talking about the same aspect of it.

 

So really, the end tag should be there, as adam said, for proper formatting.

So really, the creators of PHP doesn't know better than a random idiot who posted in their comments section?

I don't care if you know a language for 10 or even 20 years, you're an idiot if you go against it's creators.

[Mystical]

This discussion on ending tags has drifted away from the point of this topic, so I'll say this: The fact that there is no trailing ?> in the files is controlled by one line of code in our release builder. If you really want a copy of MCCodes v2 with a matching ?> for every <?php, contact us and we'll be happy to provide if you're a customer. Otherwise, it's rather irrelevant.

I was just asking a question because it looked strange to me. If you are trying to learn this stuff it is probably not irrelevant. Like any other thing on the internet you get 500 answers to one question and then you have to sift through them and find the correct answer. Looks like there is no correct answer for this question... I for one would love a copy with the closing tags added. I wasn't trying to hijack your thread. Just trying to learn.

[Danny696]

So really, the creators of PHP doesn't know better than a random idiot who posted in their comments section?

I don't care if you know a language for 10 or even 20 years, you're an idiot if you go against it's creators.

It was posted on a zend site. Im actually agreeing with your here spud, a php script should have a ?> at the end of the file. You go through the PHP manual, all the examples have ?> at the end, even if its just

<?php
echo 'Hello World';
?>

 

This discussion on ending tags has drifted away from the point of this topic, so I'll say this: The fact that there is no trailing ?> in the files is controlled by one line of code in our release builder. If you really want a copy of MCCodes v2 with a matching ?> for every <?php, contact us and we'll be happy to provide if you're a customer. Otherwise, it's rather irrelevant.

Dabs, I actually think this is very relevant, were taking about something that is sometimes included, and sometimes excluded, in the McCodes script. If we do reach an agreement, which is very unlikely, as it is mainly personal preference, or just laziness on the developers part, on weather there are benifits or drawbacks of the ?>, then you should include/remove the tag in all files, for the benefit of your paying customers surely?

Edited February 19, 2012 by Danny696

[Dabomstew]

Dabs, I actually think this is very relevant, were taking about something that is sometimes included, and sometimes excluded, in the McCodes script. If we do reach an agreement, which is very unlikely, as it is mainly personal preference, or just laziness on the developers part, on weather there are benifits or drawbacks of the ?>, then you should include/remove the tag in all files, for the benefit of your paying customers surely?

Ok, fair enough. To clarify:

Pretty much every php file released by MCCodes until the release of 2.0.4 has had a trailing ?> at the end of every file. Unfortunately, they were also littered with inconsistent code style, different opening tags (<?php vs <?) and a fair amount of trailing whitespace after ?>s.

The new standard, which will be followed from the release of 2.0.4 onwards and for each patch/version following it, will be that there will be no ending ?> where it is unnecessary. This, along with a set of other coding standards to be followed consistently are part of our efforts to improve the understandability of the MCC scripts.

It is true that whether MCCodes scripts should have ?> or not is a valid talking point, but the war of whether it is "better" to have them or not from a standpoint of best practice appears to not have a clear winner. It is this part which is getting offtopic, not how it applies to MCCodes.

[Spudinski]

It is true that whether MCCodes scripts should have ?> or not is a valid talking point, but the war of whether it is "better" to have them or not from a standpoint of best practice appears to not have a clear winner. It is this part which is getting offtopic, not how it applies to MCCodes.

There is a clear winner. But that's not what we're discussing.

We're talking about the benefits between having, and not having a closing tag present.

But, kudos for following a coding style.

@Danny, I'm not biased. Though I prefer to use closing tags, I don't see why it's needed or not needed.

It's down to preference in my eyes, nothing else. Except of course other technical sides of it, as mentioned before.

[mr moon]

Well i understand that Mccodes Developers have put up an downloadable copy of the secured/bug fixed etc. version, well 1 thing i do not like is the text file as Mccodes have not put an fix, they just tell us what to do and i honestly dont understand what they are trying to say etc. as i am not that experienced so would it not be better if Mccodes could have actually put the fix instead of telling us how to fix it or even tell us both. Thanks

[Nickson]

Well i understand that Mccodes Developers have put up an downloadable copy of the secured/bug fixed etc. version, well 1 thing i do not like is the text file as Mccodes have not put an fix, they just tell us what to do and i honestly don't understand what they are trying to say etc. as i am not that experienced so would it not be better if Mccodes could have actually put the fix instead of telling us how to fix it or even tell us both. Thanks

Well in all honesty, they can't do much more than that. They have made a v2.0.4 available from the client area so you can download it, and replace all old files. As other option they have provided a document on how to upgrade manually from v2.0.3 to v2.0.4. I don't think they can do much more since, if you have touched the code, a replacement is void, and they can never know what you have edited in what way to make the upgrade happen. With a good document - I don't know how it looks like though - any game owner should be able to upgrade his codes if preferred. If you can't do this, then I'm afraid that the fault is with you. You can always contact them and ask whether they want to do the upgrade for you freely, but I don't think that will happen either.