New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
You can say that zsudo will never fixed but start counting from today and you will see, the team behind changed totally it's mindset.
M B
And why only start counting today, why only start fixing when someone criticise it?
Wasn't it supposed to be fixed since long ago when it was first reported?
Because we are already preparing it. We had made an audit to get all functions using zsudo. We were also evaluating 2 solutions.
Notice I'm in support since 2 years with the team but in dev only since 6 month's and we got internal debate over zsudo and I agree it should been fixed faster.
For all those wanting a quick fix it's easy.
dump zsudo and replace it with a bash script that reload bind & apache. Those are the key core features we need ( some modules may need others but it's not my priority).
If you knew it could be exploited you shouldn't have released Sentora until you fixed it. It sounds like you are saying you knew it was a problem but you've been working on a solution. Well, work on it before you release something. You didn't have to put out a release. Just my 2c from what I'm reading.
Indeed.
Honestly, the easy solution would be an ultra-locked-down sudoers.d file allowing passwordless sudo to a very specific command.
Nobody said that. Just that it has not been fixed. And that it's taken an egregious amount of time. And that realistically, you've got a long-ass way to go before you're seen as not the insecure piece of shit that people currently see it as.
I agree, even if you didn't know the vulnerability existed before you released it, take it head-on, and put out an emergency patch for it, to prevent users data/servers from being lost/stolen.
' $sql = $zdbh->prepare("CREATE DATABASE IF NOT EXISTS $database");'
No one probably taught them it'd be much safer if...
' $sql = $zdbh->prepare("CREATE DATABASE IF NOT EXISTS ?");
$sql->execute(array($database));
'
>
Eh, they seem to be doing similar stuff elsewhere in their codebase.
Yeah, I've noticed. If I had the time for it, I'd go in and re-write the code to make it more secure, but sadly I don't have the time today. Might turn out to be my weekend project.
None of this matters. It's flawed starting at a very low level. All of the users home directories are owned by apache, they are permission 777, php runs as apache user for every account, they are hopeful that open base dir works as expected, and they rely on suhosin to restrict functions. While the other stuff sucks, it really does not matter. The product is a shit design even if the other problems didn't exist.
I thought suhosin was dead. Yeah it sounds like a lot of problems but you're better off listing them than using words like "sucks" and "shit" if you actually want people to listen to you. A mature and factual tone goes a long way. I believe you are making it increasingly difficult for people to see your facts behind your opinion @rack911. Facts up front, opinions second. Few are going to read that far through a thread to find out that you actually have data. You missed a key opportunity to educate people in that. Something to remember next time (because I know you value that). Trust your reader to interpret your data, don't just tell them "it sucks and you should believe me."
Someone really needs to come down from his throne here.
Then go back to the first few of his posts where, All reported problems have been fixed.
Anyone see a pattern.
Regarding suhosin being dead, maybe you should ask the product developer why they are using it.
Install the product for your self and look at the permissions. Since you rather debate and tell me what to do rather than "actually" being helpful... i'll do it for you. I'll tell you this, that you can either trust me or not, I honestly do not care.
Here is facts:
[root@sentora sentora]# pwd
/var/sentora
[root@sentora sentora]# ls -l
total 28
drwxrwxrwx 2 root root 4096 Mar 12 20:45 backups
drwxrwx--- 6 apache apache 4096 Mar 19 02:24 hostdata
drwxrwxrwx 6 root root 4096 Mar 12 20:40 logs
drwx-wx-wt 2 apache apache 4096 Mar 19 11:23 sessions
drwxr-xr-x 2 vmail mail 4096 Mar 11 22:34 sieve
drwxrwxrwt 2 apache apache 4096 Mar 11 22:35 temp
drwxrwx--- 2 vmail mail 4096 Mar 11 22:34 vmail
[root@sentora sentora]# cd hostdata/
[root@sentora hostdata]# pwd
/var/sentora/hostdata
[root@sentora hostdata]# ls -l
total 16
drwxrwxrwx 4 apache apache 4096 Mar 19 02:36 steven
drwxrwxrwx 4 apache apache 4096 Mar 12 01:16 user
drwxrwxrwx 4 apache apache 4096 Mar 12 20:32 user2
drwxrwx--- 3 apache apache 4096 Mar 11 22:34 zadmin
[root@sentora hostdata]# cd steven
[root@sentora steven]# pwd
/var/sentora/hostdata/steven
[root@sentora steven]# ls -l
total 8
drwxrwxrwx 2 apache apache 4096 Mar 19 02:38 backups
drwxrwxrwx 2 apache apache 4096 Mar 19 02:36 public_html
[root@sentora steven]#
As you can see 777 permissions everywhere with everything owned by apache. Folders user, user2, steven are all individual accounts.
For cronjobs they rely on suhosin and open_basedir to protect you
CRON ID: 3
0 0 1 * * php -d suhosin.executor.func.blacklist="passthru, show_source, shell_exec, system, pcntl_exec, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, escapeshellcmd, escapeshellarg, exec" -d open_basedir="/var/sentora/hostdata/steven/:/var/sentora/temp/" /var/sentora/hostdata/user/public_html/who
END CRON ID: 3
Same with the apache configuration
DocumentRoot "/var/sentora/hostdata/user/public_html/1313_com"
php_admin_value open_basedir "/var/sentora/hostdata/user/public_html/1313_com:/var/sentora/temp/"
php_admin_value suhosin.executor.func.blacklist "passthru, show_source, shell_exec, system, pcntl_exec, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, escapeshellcmd, escapeshellarg, exec"
Worst part is they use the system php version
PHP 5.3.3 (cli) (built: Oct 30 2014 20:12:53)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Suhosin v0.9.37.1, Copyright (c) 2007-2014, by SektionEins GmbH
So if someone upgrades their php version and they do NOT install suhosin they are vulnerable, and people can walk all over the server.
Someone could drop a regular cgi file and bypass all of these restrictions with a htaccess modification.
Regarding informing the reader, it doesn't really matter and you know it doesn't. People will use any product they want regardless of the impact. There could be blatant 0days in it and someone will still use it.
Here is more
Total disregard for any level of secure permissions. Like I said before, the fundamental design of it is totally flawed.
That is better
Totally shit is not.
while this is a forum where many kids lurk and language abuuse/frustration are rarely censored, the people which are actually following the tech part do not usually resort to such things and are appalled to read it even when it comes from someone who knows what they are saying.
Since we have fewer and fewer hacked zpanel installs, it means something is going in the right direction, personally I hope the user base is decreasing and kids learn to use virtualmin or vesta.
If you get appalled by a single word of profanity you should not even be on the internet. Furthermore, why is it when I use 1 word, I get flack yet several other people in this thread have used profanity and not one thing was said to them.
You people need to grow up.
@rack911 Bro, calm down a bit. I believe you missed a key opportunity and I communicated that to you. End of story. It's not that big of a deal. I think you missed a chance to communicate to the people that needed to hear it this time, and that's just done. They won't read the threads, your initial warning will read as primarily opinion, and everyone using it will learn from what happens to their servers. It's done. You have a voice, I hope you use it next time to educate better up front.
I do agree with you, however I believe @Jar was trying to communicate (at least from what I read) is that there's a time and a place. Additionally, I personally agree with you get appalled by some profanity you shouldn't travel the internet, however I also understand sometimes it's best not to use profanity, especially when representing a business.
@Jar
The reason why this community gets off track so often is because people like you derail it for no reason other than to be annoying. You introduce nothing of value into a thread like this yet you want to debate the practices of using a single word of profanity when really several other people have done it in far more perverse ways than I used it.
I don't believe I missed a key opportunity, if I was focusing on a key opportunity I would have worded my discussion differently.
My statement still stands, the entire product is SHIT and if you use it, you are a moron.
I'm sorry you feel that way @rack911. If you have a personal problem with me you can message me any time. I felt I was spot on topic and not at all derailing. Continuing this, however, would be. I'm sorry that you took it so personally, it wasn't intended that way.
@Jar
Good run away.
When you see a professional like @rack911 use that kind of language about a product you better believe that there are a lot of feelings behind those words.
Often when it goes that far there are no better words to describe a product.
I'm speaking in general terms since I never looked at the code.
I might contest the word "professional" due to an apparent emotional connection to this situation that is leading him to type more like a forum troll than a respected developer, but that's just my opinion.
Who said I am a developer? We run a division of our business finding security exploits in software. We have found over 400 security holes in hosting software everyone on this forum uses every day. We even have public proof of many of our security exploits we have found that are not under NDA. See: http://osvdb.org/affiliations/2667-rack911
To me it sounds like you are simply misinformed at who I am.
I know what you do. I really appreciate your work and I frequently distribute it. I was briefly excited that you had looked into Sentora and then disappointed that it read as though it was an opinion piece, different from everything else I've seen you publish about this kind of stuff. I really like your work and I was hoping for something I could reference. It seemed unlike you. I thought it was valuable to point that out. I'm very sorry that it offended you. I would gladly pay for your usual style of reports on these things.
Do not want.
What you have to understand is... we TRIED to work with them. They basically ignored us. I have absolutely zero respect for a product that evades us when we are trying to help. Right now I have been in discussions with them, and they are basically bolting on hack job fixes and introducing more limitations on their users rather than properly designing the panel.
I understand that now. I appreciate you doing that. Now I have things to tell my clients.