Tiny MCE Editor "crash" on News Posting

New Member Joined: Jan 21, 2005 Posts: 14

I've tried several versions of the Tiny MCE editor in Nuke Patched, 7.9.3.2

Most News stories post fine. Every once in a while some of them "crash" back to the index.php page without any warning and no error messages.

Recently I went through testing the MCE editor on my site and discovered that some phrases trigger this crash.

For example, on my site if I enter an article that contains the words

"a union of" (without the quotes)

Entering the News "crashes" back to the index.php page without saving or previewing the News story.

~~~~~~~~~~~~~~~~~~~~

the words "a union" don't crash, and the words "union of" don't crash, but all three words together "a union of" crashes.

~~~~~~~~~~~~~~~~~~~~

I'm also running Nuke Sentinel 2.4.2pl5 and don't know if there is anything related to the Union Tap modification...

HELP!!!!

Posted: Tue Apr 11, 2006 3:52 pm

And, I just tried to post this SAME MESSAGE over at Nuke Cops and their forum does not accept this text.

When I have the "a union of" included in the text of my message to try to explain the problem, the Nukecops.com forum "crashes" back to the index.php page.

So, I can't even post a message there to tell them about the issue because I can't describe it without typing in the phrase...

Laughing

Posted: Tue Apr 11, 2006 4:05 pm

That is because, depending on it's use and the circumstances, when the word -union- is seen, it is interpreted as an attmpted sql injection attempt and gets blocked.
I agree there should be some form of error reporting to let the user know what has happened and why and we are looking into this issue for a future RN release.

Posted: Tue Apr 11, 2006 4:20 pm

Maybe there is some way, in the News, Content, and Bulletin Board messages when the word or phrase -union- is encountered that it is reformatted with an extra space front or back.

Maybe there is some other way to be able to post the word to the MySQL backend so that it can't be easily hacked, but so that articles and content with the word -union- can be submitted.

I'd rather see the word in an article with an extra space than just crash to the index page.

Also, the extra space SHOULD (I'm guessing here because I haven't checked in my SQL database yet) be able to stop the Union Injection...???

Posted: Tue Apr 11, 2006 4:53 pm

I don't think adding spaces will have any affect as the security check, if I understand it correctly looks for the sequence of characters - hence as the word will naturally have a space before and after it when it is used in a sentence but still gets blocked.
Both 'union city blues' and 'unionstation' would be interpreted as an attack.
I am not certain but inserting a space within thw rod itself like 'uni-on' might work but the it would look rather silly and you would have to be carefulr to ensure it did not affect other legitimate words such as 'trunnion' etc.

Raven did post a work around I think a while ago but I couldnt find it.

Posted: Wed Apr 12, 2006 5:36 am

Guardian2003 wrote:

I don't think adding spaces will have any affect as the security check, if I understand it correctly looks for the sequence of characters - hence as the word will naturally have a space before and after it when it is used in a sentence but still gets blocked.
Both 'union city blues' and 'unionstation' would be interpreted as an attack.
I am not certain but inserting a space within thw rod itself like 'uni-on' might work but the it would look rather silly and you would have to be carefulr to ensure it did not affect other legitimate words such as 'trunnion' etc.

Raven did post a work around I think a while ago but I couldnt find it.

I can probably fix it then by inserting a dummy character in front and behind the -union- word that is formatted with the same color as the background. That way it doesn't "appear" in the message.

There are ways to fix this. Where can I find change documentation that shows where the injection fixes are coded? I'll fix the code myself so that the security is still there but it allows the posts.

Posted: Wed Apr 12, 2006 5:54 am

Sentinel checks for that word and so does nuke itself.
I do not know if or how the tinyMCE editor checks for that word as like many others I simply refuse to use it due to its numerous security related problems.

I am sure there may be some who use your version of nuke who may offer assitance. If you search the forum here, you will no doubt find the post in which Raven posted a work around.

Posted: Wed Apr 12, 2006 12:54 pm

Guardian2003 wrote:

Sentinel checks for that word and so does nuke itself.
I do not know if or how the tinyMCE editor checks for that word as like many others I simply refuse to use it due to its numerous security related problems.

I am sure there may be some who use your version of nuke who may offer assitance. If you search the forum here, you will no doubt find the post in which Raven posted a work around.

Haven't found any workarounds. But the problem does exist in mainfile.php.

I added a custom error message to this section of code to test it and sure enough, this is where it is coming from.

Here's the chunk of code that's causing the trouble. It is related to the Nuke Sentinel installation which I plan on keeping. In the short term, I'm going to code an error message response that tells them what the problem is.

In the longer term, as I get time, I'm going to work on a permanent solution that still leaves the -union-injection security protection still in place.

Code:

// this is where the coding issue is with the union values


$postString = "";


foreach ($_POST as $postkey => $postvalue) {


    if ($postString > "") {


     $postString .= "&".$postkey."=".$postvalue;


    } else {


     $postString .= $postkey."=".$postvalue;


    }


}


str_replace("%09", "%20", $postString);


$postString_64 = base64_decode($postString);


if (stripos_clone($postString,'%20union%20') OR stripos_clone($postString,'*/union/*') OR stripos_clone($postString,' union ') OR stripos_clone($postString_64,'%20union%20') OR stripos_clone($postString_64,'*/union/*') OR stripos_clone($postString_64,' union ') OR stripos_clone($postString_64,'+union+')) {


header("Location: index.php");


die();

Posted: Sun Oct 08, 2006 7:46 am

Try changing the posted code to:

Code:

$postString = "";


foreach ($_POST as $postkey => $postvalue) {


    if ($postString > "") {


     $postString .= "&".$postkey."=".$postvalue;


    } else {


     $postString .= $postkey."=".$postvalue;


    }


}


str_replace("%09", "%20", $postString);


$postString_64 = base64_decode($postString);


if ((!isset($admin) OR (isset($admin) AND !is_admin($admin))) AND (stristr($postString,'%20union%20')) OR (stristr($postString,'*/union/*')) OR (stristr($postString,' union ')) OR (stristr($postString_64,'%20union%20')) OR (stristr($postString_64,'*/union/*')) OR (stristr($postString_64,' union ')) OR (stristr($postString_64,'+union+'))) {


header("Location: index.php");


die();

It's not a fix but at least it should allow you to use the string while logged in as an admin user.

Posted: Sun Oct 08, 2006 8:21 am

I can't absolutely guarantee that this will work with Nuke 7.9 or that the circumstances are the same there, but we have fixed the problem for the upcoming release of RN 2.10 and posted the solution previously at:

http://www.ravenphpscripts.com/posts11081-highlight-.html

The problem was due to a logic error in mainfile. In the upcoming release the entire check is commented out in mainfile and sentinel is REQUIRED but you might be safest for the time being with the fix posted in the above thread.

Posted: Sun Oct 08, 2006 8:28 am

If using NukeSentinel you don't need the filter as NS already includes code for this.

Posted: Sun Oct 08, 2006 8:37 am

Correct. And the current mainfile logic doesn't work properly to "exclude" the check for Sentinel or for Admin users and that's what the patch in the other thread fixes. And, since the new release of RN will REQUIRE Sentinel the whole section of code is not really needed in mainfile at all.

Not to get into the grisly details here but there was a missing parenthesis around a complicated section of logic in previous mainfiles.