Sentora - General Security Warning ?

[Active8]

I saw this tread, it seems that Sentora devolpers already knowing this?

http://www.webhostingtalk.com/showthread.php?p=9399137

[Me.B]

Thanks for the heads up... I'm trying to reply there and would be happy if they have serious feedback.

M B

[TGates]

Yes, we know there are no know flaws in security right now. They have not shown any proof that the current release has any. If they do find them and post them up, we of course will jump right on it!

EDIT: They provided proof and good examples of the issues. Now we have something to work from then just 'vulnerabilities' LOL

[apinto]

Seriously, these "insecure software" will be around till the end of Sentora time and some years after that.
It's the same as for WordPress, Joomla, WooCommerce, OpenCart etc. If it's free and has good quality theres ALWAYS someone that is afraid to loose money because they can no longer sell their beloved proprietary Software.

From what I've read the Sentora security flaws that everyone talks about are related to bad configs, but who in their plain minded state does setup a Hosting Business on top of a "out of the box" software (either sentora or other one)?

Meh... Try to figure if there is really some real flaw but do never get demotivated because of articles/posts like that, they are a proof of success in my opinion.

Keep up the good work Sentora Team

[TGates]

Thanks for the encouragement apinto

[KwiceroLTD]

Yes, we know there are no know flaws in security right now. They have not shown any proof that the current release has any. If they do find them and post them up, we of course will jump right on it!

EDIT: They provided proof and good examples of the issues. Now we have something to work from then just 'vulnerabilities' LOL

I'm saddened by your immaturity on this matter. Security is very important.
There are multiple, MULTIPLE issues in this, and I don't even do auditing for a living or as a hobby.

Code:

$sql = $zdbh->prepare("INSERT INTO $database.$table_name $insert");

Just a prime example, a safer practice would be:

Code:

$sql = $zdbh->prepare("INSERT INTO ?.? ?");
$sql->execute(array($database, $table_name, $insert));

Therefore removing the possibility of SQL injection.

[Me.B]

Yes, we know there are no know flaws in security right now. They have not shown any proof that the current release has any. If they do find them and post them up, we of course will jump right on it!

EDIT: They provided proof and good examples of the issues. Now we have something to work from then just 'vulnerabilities' LOL

I'm saddened by your immaturity on this matter. Security is very important.
There are multiple, MULTIPLE issues in this, and I don't even do auditing for a living or as a hobby.

Code:

$sql = $zdbh->prepare("INSERT INTO $database.$table_name $insert");

Just a prime example, a safer practice would be:

Code:

$sql = $zdbh->prepare("INSERT INTO ?.? ?");
$sql->execute(array($database, $table_name, $insert));

Therefore removing the possibility of SQL injection.

Thanks for the input we care for security and the above statement express only the point of view of TOM. You know we are many trying here our best and we might have different expertise area.

OK I agree SQL injection might be better prevented, I've even gone further and asked we move to stored procedures!

[KwiceroLTD]

Yes, we know there are no know flaws in security right now. They have not shown any proof that the current release has any. If they do find them and post them up, we of course will jump right on it!

EDIT: They provided proof and good examples of the issues. Now we have something to work from then just 'vulnerabilities' LOL

I'm saddened by your immaturity on this matter. Security is very important.
There are multiple, MULTIPLE issues in this, and I don't even do auditing for a living or as a hobby.

Code:

$sql = $zdbh->prepare("INSERT INTO $database.$table_name $insert");

Just a prime example, a safer practice would be:

Code:

$sql = $zdbh->prepare("INSERT INTO ?.? ?");
$sql->execute(array($database, $table_name, $insert));

Therefore removing the possibility of SQL injection.

Thanks for the input we care for security and the above statement express only the point of view of TOM. You know we are many trying here our best and we might have different expertise area.

OK I agree SQL injection might be better prevented, I've even gone further and asked we move to stored procedures!

Well, I never said not everyone cared about security, it's clear ballen doesn't care about security.
It's time for Sentora to stop using fork of already vulnerable code, to spend a weekend, and just crack out a completely recoded version, otherwise you're just expanding and in-the-end creating more vulnerabilities rather than patching them.

[Me.B]

Well, I never said not everyone cared about security, it's clear ballen doesn't care about security.
It's time for Sentora to stop using fork of already vulnerable code, to spend a weekend, and just crack out a completely recoded version, otherwise you're just expanding and in-the-end creating more vulnerabilities rather than patching them.

Not so true. We can fix all the issues that were raised over permissions/CGI/Zsudo in easy way. This had been discussed in internal section and lined up plans/solutions.

It's easy to start a new project for some than fixing the existing. I don't believe that. For many reasons:

1. When you write a new panel you might make the same pitfalls same as before even if it's a different developer. You will use the same permissions, way of coding.

2. What to say to all zpanel users? Or current sentora users? Hey guys you know what panel can't be fixed run away and use another panel? No sorry it can be fixed and we will fix it despite all the bad press we could get.

Security might not be perfect but with feedback (I've been calling for feedback since month's in low end and all I got is bashing and now one able to make a serious review!).

M B

[KwiceroLTD]

Well, I never said not everyone cared about security, it's clear ballen doesn't care about security.
It's time for Sentora to stop using fork of already vulnerable code, to spend a weekend, and just crack out a completely recoded version, otherwise you're just expanding and in-the-end creating more vulnerabilities rather than patching them.

Not so true. We can fix all the issues that were raised over permissions/CGI/Zsudo in easy way. This had been discussed in internal section and lined up plans/solutions.

It's easy to start a new project for some than fixing the existing. I don't believe that. For many reasons:

1. When you write a new panel you might make the same pitfalls same as before even if it's a different developer. You will use the same permissions, way of coding.

2. What to say to all zpanel users? Or current sentora users? Hey guys you know what panel can't be fixed run away and use another panel? No sorry it can be fixed and we will fix it despite all the bad press we could get.

Security might not be perfect but with feedback (I've been calling for feedback since month's in low end and all I got is bashing and now one able to make a serious review!).

M B

As stated over at LET by a member, Sentora had a chance to change and get rid of bad ZPanel reputation, and instead got it all back again.