SolusVM 1.13.03 Vulnerabilities
localhost.re
localhost.re
Back in 2009, before SolusVM came along, the most popular control panel for low-end VPS hosts was called HyperVM. One day in the summer of that year, HyperVM got hacked, or more accurately, a combination of slow updates and weak passwords caused major data loss at a popular low-end VPS host. The next day, the developer of HyperVM, an Indian man, committed suicide. There was a lot of publicity surrounding the incident, and many low-end VPS hosts went looking for a less infamous control panel.
Then came SolusVM. I can't remember exactly how it came to be the primary replacement for HyperVM, but almost overnight everyone adopted SolusVM. I'm actually surprised that it lasted nearly 4 years without a major security incident like this. The low-end VPS market is so crowded with assholes and 14-year-olds looking for a quick buck, the so-called companies exchange DDoS attacks every other day. Now that the easiest route into another company's servers has been published, expect them to start hacking one another into oblivion.
Meanwhile, I'm already starting to wonder what kind of flying PHP-spaghetti-code monster whose name is /^[A-Za-z]{5}VM$/ will come to replace SolusVM for the next 4 years or so. It probably won't be much more secure, since most of the kids have budgets that are too tight to buy proper software. Developers who know how to use prepared statements cost money. Auditing a complex piece of web app costs even more money.
Writing control panels is hard. Remember, even Linode sometimes gets it wrong. If you trust your root account and therefore the fate of your business with a bundle of obfuscated code that may or may not have been audited by any competent security researcher, it's only a matter of time before something like this happens to you.
I can't even call this a vulnerability - it's an open door.
It is only in the last couple of years that the PHP community has begun properly getting it's shit together (composer, PSR, unit testing (not a universal panacea but a useful tool)).
The problem is as always the good programmers will continually seek out better ways to do things (or at least explore the available options) while the "bad" programmers will continue to program like it's 2001 and PHP4 is the new kid on the block.
This is mostly the result of PHP's origins and is unlikely to improve in the short term.
If you follow best-practices, use modern tools (as mention composer, psr autoloading) and a decent framework (Symfony 2, Zend or my favourite Laravel) then you can turn out a good, secure and well engineered product.
If somebody is inclined to stick raw POST data into an SQL query, a framework isn't going to save him. Maybe an ORM will, but ORMs are only a small part of what we call frameworks nowadays, and any ORM that allows custom SQL still leaves plenty of room for a lazy developer to shoot himself in the foot. Similarly, a framework won't prevent you from sticking raw POST data into an exec() call. Most frameworks don't even care about those shell functions, they're so heavily focused on providing a smooth CRUD experience.
On the other hand, if the argument is that someone who knows how to use a proper framework is likely to be a better programmer than someone who doesn't, I agree and I'm sure that such a correlation can be easily proven.
It's been a bug in their API for a very long time, with multiple requests for a fix. I made a new request for a fix about 2 months ago and they're still "working on it". Not difficult to look at the correct line in /proc/meminfo.