
SolusVM 1.13.03 Vulnerabilities - kamaln7
http://localhost.re/p/solusvm-11303-vulnerabilities
======
kijin
The very idea of a web-based control panel for a Linux server is a recipe for
disaster, because it means giving root access to a web-accessible program.
Remember why you're never supposed to run Apache as root? Or why you should
never give PHP scripts permission to write to any location outside of the
upload folder? Root and web-access don't mix, period. In the VPS business it's
a kind of necessary evil, but that's all the more reason to check if the
survival of your business depends on a bunch of unsanitized SQL queries.

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.

------
jemka
Ramnode was hacked as a result:
[https://news.ycombinator.com/item?id=5888309](https://news.ycombinator.com/item?id=5888309)

------
ams6110
I actually fear this kind of stuff more than the NSA when it comes to cloud
services.

------
mpchlets
Oh man - failure to use a framework or they worked around it - either way this
was a big programming no no - direct use of SQL with NO sanitizing. Very bad.

I can't even call this a vulnerability - it's an open door.

~~~
noir_lord
The horrible reality is that much (possibly most, I have no figures so this is
ancedotal) of the PHP code in production was written using a) no framework b)
some in-house framework that was never audited.

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.

~~~
kijin
This is bad programming, period. It has very little to do with frameworks.

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.

------
tlongren
This is not surprising at all. In their client API for checking server status,
they can't even report memory usage correctly.

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.

------
JosephRedfern
Right now, their official fix (sent via email) is to ' rm –f
/usr/local/solusvm/www/centralbackup.php'. Great.

~~~
clone1018
Honestly the better fix is rm -f /usr/local/solusvm :(

