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
Great and all patches are welcomem! This is what I had been calling over guys come on give great input.
over zsudo as I said before, we use it mainly only to restart/reload apache and bind. So it would be easily replaced by a bash script with 3 lines and no more offer full sudo feature.
MB
Not really, he is up there for a reason.
The owner really isn't taking this seriously, at all.
I'm quite shocked he isn't taking this seriously, I was hoping he would. Oh well, here we will witness another ZPanel Train Wreck. I had to speak up about that image there,
It's in-excusable to willingly and purposefully ignore a security hole, and put your users at risk.
I Don't agree. You got the wrong person from the team and I will ask that any security issues raised would be handled from today in different way. On the forum I'm already pro-active and doing my best, as I seem the most paranoid in the team. You emailed [email protected] but you can see the forum is there open and were replying daily at dozen requests:
http://forums.sentora.org/
Since you started your thread over in WHT and it got reported in the forum I replied in WHT and here and asked for more infos. We got many email exchanges and thanks for your input, you can't say we are not willing to make any improvement.
But let's put a name over the issue, it's privilege escalation here. Not an RCE. That doesn't mean we want fix and I'm not doing PR here. I'm asking for recommendation. We tried to get a security audit with other firms. So great to see experienced people nailing down sentora I Don't take it as badly as long you point the issues and provide facts so we can fix it.
I would be offended by the stance you use but it's not an issue as long I get what I want: serious feedback so we can improve the product and beside that in next fix you might even get credit (not for zsudo).
Again my call If you are an experienced developer with security all feedback is welcome. The project is open source and we still think it have a place and all hosting industry might more help us instead of only blaming us. We don't even ask for money or donation but only VALID input.
PS: I'm only a member of the team and this expose only my opinion and the whole team opinion.
M B
They've sent POC, I posted some issues on your Sentora forums. I'm pretty sure that's considered valid input, correct?
Solid input received.
No one should be using Sentora right now on any public facing system.
??
You wanted a chance to rise above zPanel's reputation and I can only speak for myself @Me_B but I am interested to see what's next. You should pull the easy installation instructions and download links so that no one mistakenly installs it and get to work. You've got the opportunity, now the rest is up to you.
This is zPanel all over again, stupid mistakes and ignorant developers that don't want to hear anything.
@Me_B is just a support monkey, probably the only one that actually cares from his whole team.
Patrick I'm not the only one caring believe me and I'm forwarding input. Thanks again.
So expect a patch soon for all the issues raised we will level down all the issues they raised.
M B
Let's hope it's actually patched and not another train wreck.
We can't do it alone. We need your feedback and you can help over that more seriously. I don't care for our ego. I care more for all those using sentora, as with my knowledge I can secure and lock down my own install.
We need to validate the patches and test installs on 4 different os's and that require more work. In sentora 1.0 we took time to unify the installer ( we got 2 different installers and added ubuntu 14 and centos 7 support). It's a long story... Any way thanks and you can reach me at the forum and PM me if you had any concern.
M B
Have you considered getting developers who know what they're doing then? If Sentora needs help developing, I wouldn't mind helping take on development, as long as it's conditional it's security focused, and not just going to leave tons of bugs out in the wind and ignore the risks.
People have stopped bothering looking for vulnerabilities, due to the rotten attitude towards them. It's simply not worth their time, and it's much easier to just discourage people from using it altogether - why would you keep putting time into a codebase with absolutely horrible code quality, when the developers are not going to take your reports seriously anyway?
It has now been, what, 2 years since the
zsudoissue was reported? I don't care what your excuse is, that is an unacceptable patch window. Trust is easy to lose, and hard to earn back.You're still going to need
sudo. And using it incorrectly will still result in a security problem.The problem is that almost your entire team seems to misunderstand how security works. "If you can't show a vulnerability, there's no problem" is not a sustainable attitude, and it is what leads people to not even bother. There are structural design issues with Sentora - some of them can be classified as "vulnerabilities", some cannot - that have to be resolved to turn this into a secure panel. Whether an explicit vulnerability has been found or not.
Finally; at the very least take down your installation instructions like @Jar suggested, until you have your security in proper order. Doing otherwise is simply asking for trouble.
You are welcome and we can coordinate dev. Currently we try to split work and depend on availability of dev's. Github is open for bug fixing but it's always better once you coordinate with the team. It's always hard to find commited users who have the right knowledge, you know most of the users want it NOW and for free :-( and blame us if install fails because they didn't have the basic admin knowledge.
M B
Message me via my account on Sentora.
Damn! do they even basic web
That looks totally crazy but that's half of the story each virtual host runs with suhosin and gets openbase_dir lockdown with function disable like below:
php_admin_value open_basedir "/var/senttora/hostdata/user/public_html/domain:/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, symlink"
This way you can't using PHP access any file outside your folder unless you find a way to blow suhosing jailing/openbase_dir.
Let's place each information in it's context.
M B
Suhosin is no longer maintained. Upgrading to PHP 5.4 or higher will result in all of your security vanishing completely.
I also want to point out that I'd be completely willing to provide you with a list of things that need to be fixed, on the condition that they will be taken seriously, and not waved away as "not a vulnerability".
There's a reason cPanel uses suPHP. It isn't always the best at all things, but it serves a strong purpose and it works.
FALSE suhosin is maintained and works fine in PHP 5.4/5.5. We took time to test it.
Last release in dec 2014
https://github.com/stefanesser/suhosin/releases
If you think it's not working with php 5.4 / 5.5 you can try our suhosin patch and it WORKS
https://github.com/sentora/sentora-installers/blob/master/suhosin_patch.sh
I Didn't wave it as not a vulnerability. I just tried to say permission have no real impact here as we don't rely on them really. This is why I mean "Let's place each information in it's context."
I was not aware of that. Apparently the maintainer has resumed work on it, then?
Regardless, it has been unmaintained for a good while some time ago, without prior announcement. What are you going to do if/when that happens again?
I wasn't refering to Suhosin. I was refering to...
... which applies to the project in general. I have repeatedly tried to address architectural and code quality issues in the past, and they have been consistently waved away as "not a vulnerability, therefore not important", which is completely misguided. I'm simply pointing out that I am still willing to provide such a list, provided I'm not met with that bullshit again.
If I have to spend three times as much time to defend my points, as it takes to make them, then it isn't worth my time anymore.
That is not how security works.
Security isn't a 'checklist', and only having a single line of defense against something is almost never enough.
All the feedback is being processed despite all your previous thought's! All I say we must prioritize importance as we prepare for a patch soon to address some concerns.
For suhosin not maintained this had been discussed in internal and we decided we will move on and change the panel design an use suEXEC as second layer in case suhosin fails or we can't use it any more. This is under work and require more time and in-depth testing as the changes are important VS old design.
And arguing here I try to explain the issues once raised and place them in their context. My main focus now I see Patrick pointed CGI could be enabled again and we will change the installer/patch so it's totally disabled. Then you won't have any way to use symbolic links or try to bypass openbase_dir. I argue here mainly to get facts and issues challenging you so you point the issue and move on over free bashing without any facts.
If you want to say how low your respect for sentora team no issue, as long you give us input so we can improve it!
That's good news.
You have to understand that this bashing is largely a result of the past attitude of the ZPanel team - an attitude that has largely remained the same throughout the years, despite promises that it's "really going to change now". You can't expect people to just forget about it the moment you say you're turning things around - it will take time for people to trust you again, as a team.
Here are a few big points that need fixing in the Sentora codebase:
zppy. This is a hard problem, and you will need the advice from somebody who has experience with developing a secure package manager. Writing a secure package manager is not an easy task.execcalls where they are not strictly necessary - eg. inzppy, you should simply use the PHP cURL extension.robots.txt. It's pointless, and doesn't give you any actual security - just a false sense of it.randormt_randfor this. This is an example of how to do it correctly.Whether I will look for any further issues, will depend on how the above list is followed up on.
EDIT: Bonus problem. You should never, ever, ever leave out the braces for a statement. Regardless of how many lines it is. This is just asking for trouble - see eg. here.
Will check it, but will require more time over that. And I Don't see why we won't have issues imported from other templaters.
Yep agree but should be easy to sort out.
zppy should some how retired as the team plan to replace with a store where you will get all modules. A central place.
Zppy here is a tool so we still need it. as modules need to do low level. Zppy is a CLI PHP Tool that should run with root privilege so sounds here non sens to disable exec in this case. But agree exec should not be used in most scripts. The panel should be even split in 2 parts.
No, I don't agree, we refuse to be indexed by google. No sense to allow bots in panel.
OK thanks will forward it.
Thanks again for the feedback.
M B
Because they have been well-tested and are widely used, and the usual issues you encounter in templaters have already been fixed in them.
Right. Many of the same security concerns will still apply, however.
You should always give things the absolute minimum permissions/privilege that they require to do their job. There may be a security risk involved in calling an external process that you hadn't foreseen, even when the tool is run as root anyway - it's just not a good idea to do it like this when a more restricted option is easily available. Again, something doesn't have to look like a vulnerability to be a security problem.
Please read the page I linked.
robots.txtis not a security measure, and it does not keep bots out. It is purely advisory, and therefore useless.Again, every single thing I pointed out is a problem that needs fixing, and this is really not a matter of discussion. While you are always free to ask for clarification if something is unclear, this is the last post I will be spending on "arguing" about anything. I have a good understanding of how security works, a good understanding of what I don't understand, and I have motivated every point I made here.
It is your choice whether you are going to do something with these points, but you need to understand that your developer team is very inexperienced in the field of security, and there's no point in trying to pretend otherwise - it is blatantly obvious to any experienced security researcher.
From your (incomplete) reasoning about
robots.txtalone, I can tell that you have no experience in threat modeling, for example - and I have seen similar statements from most of the developer team. You can either treat the criticism as a learning opportunity, or keep pretending that you understand everything there is to know about security - in the latter case, the security issues will never stop occurring, and statements like "stay away from Sentora" will keep coming.Security is a constant learning experience, like many other things, and that is something you'll need to learn to accept. You will be notified on a regular basis of security problems that you weren't aware of before, and you will be told that something you have in place right now is useless and should thus be removed - that is perfectly normal. Asking for clarification is okay - waving points away without first fully understanding them is not.
Finally, please stop claiming your panel is "secure". It's only "secure" when security researchers or other security specialists say it is, and even then it's not a certainty - until then, you're "doing your best" at best. "Secure" is not a label you can stick on your own software, and the label doesn't really apply to the code, but to the attitude of the developers. That doesn't just go for Sentora/ZPanel, but for any project.
EDIT: Just to clarify; part of specializing in security is being able to "sniff out" when people are not as competent in security as they claim/think, and being able to motivate that observation. That is why you see both the Rack911 guys and me making such statements.
At the end of the day, nothing is 100% secure, no matter how many security specialists gave it the final OK.
This is an evolving issue, a turn-based game, where the attack always has the first move, the thief is usually more motivated than the guard and benefits from the surprise element in many cases.
Being secure means rather having a plan B, a plan C and a separate back-up plan for all of those. As in everything, disasters happen, but it is not the same having an old low dirt wall behind the bank with having a multi-layered rock and steel enforced one, drainage and pumps as the last line of defense as well as constant watch over the river flow patterns. Whenever you design a security solution you assume the usual standard defenses ARE breached, then ask yourself what is exposed after that which does not absolutely have to and how fast can you detect the attack in progress using automated alarms triggered by certain patterns in the data flow?
Let me give an example many people will understand, without being coders.
Say, you have a firewall and all systems are behind NAT with proper port-forwarding (we do not assume IPv6 for the sake of simplicity) of only what needs to be forwarded, we have DMZ and all that stuff. Looks secure, right?
But what happens if one of the listening services has an overflow type vulnerability and allows arbitrary code execution with it's maximum privileges? It may be very possible that one machine in the DMZ to be compromised, maybe even with privilege escalation and then everything on the subnet and bridges will be vulnerable.
The conclusion is that every machine must have firewalls in place, be allowed to talk with only the minimum necessary machines there on only the necessary ports by EXTERNAL firewalls which cannot be accessed in any way from the machines on the DMZ. Also, all applications must run with the lowest privileges possible, be updated regularly, including hte OS (kernel) which should always run with the minimum modules and libraries, have no development tools such as compilers or be allowed to go out on the internet other than the minimum way required to function for their purpose.
There can be many other measures in place, alarms from various patterns detected during DPI as well as for larger than expected outgoing flows, in short, a really secure system can still be broken into, but, as with any locked door, a successful defense depends not really on the locked door which will only stop kids and animals, but on the time the attack will take and how well are the alarms setup to make the operator focus on any anomaly and mitigate the threat before anything was leaked/stolen.
An attitude like: "but the door was locked!" will always fail, it depends only on luck and scale of adoption if sooner or later.
Not strictly true, provably secure code is possible. It's just not practical in many cases.
I agree with your post otherwise.
EDIT: And a large part of practical security comes down to making it easy to do the right thing, and hard to do the wrong thing - this is ultimately why practically everything using unmanaged code (eg. C) gets owned eventually.
While secure code is possible, it is very improbable, and that is only one element that can be attacked. Hardware signalling can now be intercepted from some distance, for example.
If everything fails, there is always social-engineering and corruption which probably works in most cases given the right incentives and risk mitigation.
But it is true this thread is only about insecure code at start, so, I will agree with you here.