Serendipity Forums

Hi Garvin

Since we had this little problem with the third party software Xinha WYSIWYG-Editor, opening a potentially security hole and making Serendipity vulnerable, which was stopped with v. 1.5.5, I was wondering how this could be possible.

I understand its a Xinha Problem, but I dont really understand why it is/was? allowed to execute a script path in serendipity not meant to be opened by public at all.

Is this something we got to live with ?
or
Is it possible to avoid it simply by using the basic Serendipity settings only ?
or
Do we need some htaccess voodoo or similiar there ?

Please enlighten me concerning these questions

Regards
Ian

Hi!

I'm not sure I understand your question.

The problem is that Xinha delivered some custom PHP code with it, that stands on its own and is not related to the s9y framework at all. It's only used for Xinha filemanager stuff or spellchecking or whatever.

We simply shipped that code with ours, in the best hope that it did what it needs to do and does not contain issues. But it had issues, and it was executable from outside of s9y.

Regards,
Garvin

garvinhicking wrote:The problem is that Xinha delivered some custom PHP code with it, that stands on its own and is not related to the s9y framework at all. It's only used for Xinha filemanager stuff or spellchecking or whatever.

Yes, Garvin, I truly understand this to be a non s9y related issue. I know s9y to be very strict and secure and I am very happy with it.

garvinhicking wrote:We simply shipped that code with ours, in the best hope that it did what it needs to do and does not contain issues. But it had issues, and it was executable from outside of s9y.

What I meant to ask, if we need some securing wrapper around third party software shipping with serendipity to avoid these vulnerables and/or public access in future. (Shipping means to bear some sort of more responsibility.)

Ian

Hi!

What I meant to ask, if we need some securing wrapper around third party software shipping with serendipity to avoid these vulnerables and/or public access in future. (Shipping means to bear some sort of more responsibility.)

Ah, i see. I don't think we can do this. This would require us to know a lot about the PHP scripts we want to wrap (think of global required variables, custom database connections, specific objects, colliding function names when the s9y framework is included, memory limits, ...).

But what I've drawn from this is that in the future, we should only bundle files that cannot directly be called (like libraries etc.). Everything that really requires external executbale PHP code should be carefully evaluated, and if possible only included through plugins...

Regards,
Garvin

garvinhicking wrote:But what I've drawn from this is that in the future, we should only bundle files that cannot directly be called (like libraries etc.). Everything that really requires external executbale PHP code should be carefully evaluated, and if possible only included through plugins...

I totally agree with that
That is definitely the way I intended when asking these questions and I'm very pleased you already straightened your thoughts.

Thank you!
Ian