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
Yes, I'd say so. Programming language is rarely, if ever, related to stability and security, that's all in the hands of the engineer (apart from exploits that are related to e.g. JVM or the PHP process itself).
However, I do agree that programming languages that tend to more or less enforce a standard are more commonly used by capable engineers and therefore likely less prone to issues on a larger scale (e.g. C/C++/Golang/Perl). PHP enforces basically nothing, and you can do whatever you want without running into a lot of issues during compilation. That's great for some purposes, but to my experience so far, too many people that program in PHP have no clue as to what they're actually programming, they just copy/paste a bunch of snippets that use different standards and call it a program. Same for JavaScript and all the NodeJS crap that pops up nowadays.
That said, I quickly skimmed through the VestaCP source. It truly saddens me to see that they use "escapeshellarg" to escape $_SERVER['REMOTE_ADDR'], which holds the clients IP address and is set by the webserver (and therefore is safe as it is not user input). But at the same time they do not call the same function over a $_POST variable that does hold user input (in this presumed exploit, the password) but rather pass it to /bin/bash with root privileges. I guess I'm switching to a different panel, I like the simplicity of Vesta, but it comes at a cost apparently.
Probably has more to do with how Vesta was written (the actual PHP code) than with the language per se. But it may also be true that PHP applications are more often targeted nowadays than Perl applications.
Yikes, dump that shit, is not worth. At least you were smart enough to inspect the code and determine it sucks. Can't say the same for some of the clueless people in this thread.
I just assumed same reason cPanel was never copied, despite having fully available source code (copyright never bothered that many people). No one can read perl :P
Oh I read this thread too late. I was affected three or four days ago and I couldn't find the problem
. I thought I couldn't secure the system enough.
Yeah, that's interesting.
In any case, PHP is much more a go-to language for web applications than Perl ever was.
At the same time, I'll admit that I've always kind of liked webmin/usermin/virtualmin (when I've wanted to install a panel).
I would not be worried about using SSH as no one has noticed any triggered events to date. I would however download clam av, run a freshclam on it to update, and scan the whole server.
If you are unaffected, I would not do a reload or do anything else except turn the panel off and run the av scan. Wait a couple of weeks to let them sort it all out. Some level of patience is in order. And, while the Vesta team needs to put an obvious priority on security, the truth is a zero day could happen to almost any project.
For all the perl hype do realize that Webmin, Usermin, and Webmin all have had security exploits. Perl doesn't instantly fix your security.
PHP is a great tool, in the right hands.
Perl is a great tool, in the right hands.
Javascript is a great tool, in the right hands.
You can create a security exploit on; PHP, Perl, Javascript, and all the others to. It comes down to how you write your code.
i trust they will find the problem and solve it and life will continue...
and come on other bugs like any software
do I have to stop using windows if I caught virus in it one day?
Well I mean it depends. Have a look at the code. I would recommend to avoid any panel if you dont really depend on it. If you truly need a panel, go with cPanel for sure. At least they apply patches proactively and also compensate security researchers which is good for the product.
Yes, pen and paper are better!
Wow, VestaCP is so bad. I mean, so, so, so bad.
I have already found several root level exploits in LITERALLY less than 15 minutes and I'm typing with one hand while I eat with the other lol.
I'm making a list of everything, I'll send off to their developers at some point...
@Patrick!!!! Didn't know you were here
(MrGeneral here!).
You guys spent time with this? How can they afford? :P
Thank you so much for your input.
Based on your experience. Which panel would your prefer ( other than cpanel / plesk )
I understand that having no panel at all is the better option.
Amen.
They might be just reviewed the code of Vesta on their own accord, I doubt Vesta dev team got the money to get someone else to audit there code for security issue but I might be wrong.
Even though you don't use a control panel, you still use at least 10 services like exim, dovecot, nginx, etc... and even more libraries. A critical bug in any of these will also make you as vulnerable as any other control panel.
Control panels just make more room for exploits, especially open sourced ones.
This is a completely wrong yet frustratingly common belief. The design of a language and its standard library absolutely do play a significant role in the security of the code that is produced with it. Yes, competence of the developer is also a factor, but not the only one.
Simply put: the less footguns there are in a language, the more secure the resulting code will be on average - because every developer makes mistakes, regardless of their competence.
C and C++ software are notorious for memory-related vulnerabilities, and that remains one of the top vulnerability categories (if not the most common one). It's definitely not 'less prone to issues on a larger scale', it's just a different category of issues from the 'web-based vulnerabilities' that people commonly think of. Neither of these languages are likely to produce secure code.
(Perl is a more complicated topic. Go is mostly fine from that perspective.)
Free but closed-source control panel maintained by single person could be a disaster
Why "especially open sourced ones"?
What we need is L(ow)E(nd) panel, an open source control panel by LET.
When has nginx, php-fpm, or mariadb ever been the direct cause of a root exploit?
Outside of server admin stupidity.
And stupidity is aplenty.
I really don't want to move to an enitrely different control panel, but I like the ease of Let's Encrypt setup.
Is there any good suggestions on an open source web panel with good lets encrypt support, or a paid one that is reasonable cost.
I have gotten a bit lazier, as I used to just run bare bones.
Honestly, you will eventually realize a control panel just seems easier, but in the long run bare bones is easier.
I'm lazy, and I hate panels. For various reasons, first being exploits.
Been there before. They add some complications, yes. However it is still a bunch loads easier with a control panel, at least for me.
ISPConfig might be a good fit for you, it has Let's encrypt support, out of the box since v3.1 I believe.
https://roundcube.net/news/2018/04/11/security-update-1.3.6
Heh!
COBOL disagrees.
Although it could theoretically be abused to place a file on the server, you can't really do anything with just IMAP commands.