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
haha this is just funny. I found like 10 bugs the day I installed it and was like hell no I ain't using this.
I have spoken to their development team months ago and they expressed zero interest in replacing the templating system any time soon.
No, they're not. Pentesting is a very labour-intensive process, as is the patching. Even more so when the vulnerabilities are of such a nature that it requires replacing a core component entirely (such as the templater) to remove them.
Again. Fixing this vulnerability requires a full rewrite of the entire templating system.
cPanel is not open-source, it just has a readable source (or at least, some versions do). That's something very different.
I'm actually not a skilled pentester at all, the vulnerabilities in ZPanel are just blatantly obvious.
Use addslashes there and use stripslashes while outputting? I'm not saying it's pretty, but it works.
I also agree that implementing your own templating system is quite stupid. First of all, PHP is a templating language. Second, there's plenty of templating systems already out there who have fixed all theses problems. Finally, if you do it, make sure you fix security.
On the other hand, injection is possible via templates. Which means that you either cause this yourself (as a site owner) or don't check 3rd party templates before you add them (which is worse). So, only people with access to the server (and thus the data) would be able to abuse this, if I understand it correctly. So, it's not that critical, but it does need to be fixed.
What? No, it doesn't. Please read the description of the vulnerability and the templater code again.
It's not necessarily stupid, it's only stupid if you have no idea what you're doing (which is the case here).
Aside from that being a disputable claim, PHP is unsuitable as a 'template language' if you allow for untrusted templates to be uploaded.
Correct.
Actually, no. If there is even a need to 'fix security', that means you're doing it wrong. The only reasonable way to write a templater that handles untrusted templates, is by writing an actual parser, tokenizer, etc. That is a model that can't be exploited, because it simply never runs any code.
Resellers can use custom templates for their panel.
I just ran a minimal test with the example injection code you have and line 71 of their code. If you use addslashes, the array key becomes an actual string (rather then executing code there) and eventually, when output, becomes a normal-looking string again. So unless there is a context that wasn't in my minimal test case, it should work.
True. There's way too many arguments about that. The only thing that stands in the way of PHP becoming a usable templating language is probably sand-boxing (including limiting the availability of functions/methods).
What I meant with 'fix security' is 'make sure you keep security in mind'. I should have added quotes around it to prevent people taking it this literally. I think most people got what I meant though ;-)
Ouch...
Found the culprit, bro?
Wut?
I use zpanel in some servers for personal projects and it worked well so far. Are there any tips on how to harden the environment except not using it.
Well, not using resellers right now and manually checking all templates. But that's just for this issue. According to @joepie91 there's a lot more. Maybe he can give you some more pointers.
I deleted the download.php, locked phpmyadmin, changed default paths, changed some default passwords ,,, any other ideas
You know, the use of untested non-official templates and third party plugins
Really. Switch to another panel.
The problem with ZPanel is not a specific set of vulnerabilities, it's that the developers are not dealing with security responsibly. They laugh off any warnings that don't come with an explicit example of an exploit, refuse to fix known vulnerabilities, and more importantly, are not doing what should be done with the current codebase: rewriting it from scratch.
While expecting them to rewrite it from scratch may seem ridiculous, you have to realize that the current codebase was written almost entirely without security in mind - there are numerous poor practices, vulnerabilities, and other nastiness.
This is also why 'hardening' it won't have any effect - I could go through the code right now and pick out every vulnerability I can find, and I'd probably still be missing things that are going to be exploited in the future. You are effectively running a "ticking time bomb meets hydra" on your servers, and you're cutting off wires constantly in the hope that it won't explode. Eventually you're going to miss a wire, and the whole thing will go boom.
There are quite a few free panels available that are more secue. Use those.
Ah, yes :-) Not that anybody should do that anyways, but they do.
I found a fix that fixes ALL zPanel issues.
rm -rf /etc/zpanelThen you can hire one to fix it for you.
Or you can hope someone else fixes it: as happened with the SQLedger/Ledger SMB fork for exanple.
Thanks a lot @joepie91. I take your advice very seriously. I will move everything ....
@goexodus you might try ISPConfig
Froxlor is my next maybe. At least until Neon is done because its awesome
Yes, a good choice, moreover ISPConfig 3 is capable of controlling websites across several VPSes.
@jarland I'm also waiting for Froxlor V.1.0
lol, I just upgraded their demo :P
Looks decent, though :-)