6 ms·

The interface looks very nice but no thanks, I'm not going to install PHP on my servers to have it. I'd totally set it up if it weren't for PHP. The risk is jus

by jdiez17 13y ago

The interface looks very nice but no thanks, I'm not going to install PHP on my servers to have it. I'd totally set it up if it weren't for PHP. The risk is just too great to ignore.

kodablah 13y ago
Some server side code is required to obtain the data. Out of curiosity, what would it have to be written in to make you feel safe?
- jdiez17 13y ago
  In anything that is not PHP. Bash would have been perfect for this use case, for example. The correct way to do this is to obtain the data separately and merely show it on the interface. I haven't audited the code, so I don't know what's being passed to the shell commands, but the fact that an attacker MIGHT be able to influence the commands being executed (see register_globals, etc (yes, I know this has been disabled by default in recent versions of PHP)) is enough for me to completely write it off as an unnecesary risk. By collecting the data periodically (i.e a cron job) you eliminate most possible vulnerabilities.
  - kodablah 13y ago
    First you say anything not PHP then you don't mention one. While I agree that off-request collection may be wiser, I fail to see anything mentioned better than PHP unless you're seriously mentioning Bash to write a webapp like this. Mentioning an old security concern that is no longer an issue seems like an easy way to discount every possible language.
    - jdiez17 13y ago
      I said that a bash script would be perfect for collecting data periodically and saving it to a file, I wasn't suggesting that you use it to write a web app. I thought that was clear; apologies if it wasn't. However, you say that this is an easy way to discount every possible language: can you point me to a vulnerability on the same level as register_globals in any other language?
- bradleyland 13y ago
  Server monitoring applications, by their nature, have to interact with the system by issuing the commands that will collect data. The most common solution is to separate the application in to two parts: Back-end: a daemon process that runs at an interval, collecting data and writing it to a data store. Front-end: connects to the data store, processes statistics, and formats for display. By constructing your application in this way, the data store acts as a firewall between the system calls required to collect the data and the interface used to view the data. Your daemon application needn't listen on any network ports if it is running locally. Your web application still needs to be secure, but you don't have the additional risk of many calls to system/shell exec commands that are a honey pot for exploitation.
rschmitty 13y ago
Have you even looked at the (trivial amount) of PHP source code? Where is PHP going to be attacked? Perhaps I am missing something obvious but it seems like PHP is running some linux commands and parsing the results, not sure how this would be different/safer in another language? Also you can put it behind http auth or restrict the vhost by IP etc
- jdiez17 13y ago
  It's not how much PHP is running, it's that PHP is running _at all_. It makes me feel very, very uneasy that every time that web interface is hit PHP executes a shell command. There's something inherently wrong about that, to me.
  - deanclatworthy 13y ago
    Unless the script accepts parameters, which it doesn't, there's nothing to worry about.
    - jdiez17 13y ago
      Like I said in a previous reply, see register_globals and company. Sure, that was some time ago. Sure, the defaults are better now. But at some point in time the people in charge of PHP thought "yes, this is a good idea, let's do it". ... It's not like the attitude has changed, though. There are many, many things deeply wrong with PHP when it comes to security. PHP is supposed to cater to unexperienced programmers. An unexperienced programmer might see "mysql_escape_string" and think that it will escape strings, making them suitable for use in SQL queries. The programmer will think the code is secure. WRONG. Because you have to use mysql_REAL_escape_string. Also, look at the `e` flag in preg_replace. WHAT THE FUCK. Like, seriously. What. Why. There are no words to describe how gobsmacked I am. And FOUR people in the PHP committee (or whatever it's called) voted __AGAINST__ deprecating it. FOUR. [1] -- The point is that I can't audit (and would rather not waste my time doing so) this PHP code. The fact that it uses shell_execute when a HTTP request demands it is enough of a red flag. [1] https://wiki.php.net/rfc/remove_preg_replace_eval_modifier https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
condiment 13y ago
I had the same attitude, so I forked it and rewrote the PHP endpoints as a Python script, which I execute outside of the context of the application via a cronjob. https://github.com/arbuckle/linux-dash https://github.com/arbuckle/linux-dash
- jdiez17 13y ago
  Thanks, that's how it should be done. I don't care if the collection script is written in Python, Ruby, Node JS or Brainfuck; it shouldn't execute shell commands when it receives a HTTP request.
- itsderek23 13y ago
  Checkout https://github.com/scoutapp/server_metrics https://github.com/scoutapp/server_metrics (Ruby - gem install server_metrics). Grabs all the key server + process metrics, handles Linux memory cache, etc. Requires a distro w/ "proc" functionality for the most metrics.
- e12e 13y ago
  Thanks, this architecture makes more sense imnho. Between this and the other thread on monitoring solutions, I wonder if it would be worth it to write a snippet that takes data from sar [ed:sar/sysstat or perhaps conky] and dumps out json that works with this dash...
damiongrimfield 13y ago
"The risk is just too great to ignore." Can you elaborate on this? I'm looking for you to clarify which other dynamic languages would be considered less risky in this specific application and why.
- jdiez17 13y ago
  Other dynamic languages have similar risks but at least they don't have a history[1,2] of making completely stupid decisions when it comes to security. However, I'd rather not have a program execute a shell command when it receives a PHP request. Written in PHP or not. It's just wrong. [1] http://www.php.net/manual/en/security.globals.php http://www.php.net/manual/en/security.globals.php [2] https://bugs.php.net/bug.php?id=47796 https://bugs.php.net/bug.php?id=47796
  - nivla 13y ago
    Register Global has been depreciated since two versions ago and even completely removed since the last version. Follow your own posted link [1] and it says it right on top with a big ass banner. >Other dynamic languages have similar risks but at least they don't have a history[1,2] of making completely stupid decisions when it comes to security. Yes like Ruby and Active Records SQL injection debacle where Github was pwned and the developers din't seem to care? I can't argue that PHP is better than other languages, but holding it to f*ck ups from over 5+ years ago, most of which have been fixed, is a low. If you can find something vulnerable within this open source coded, then I happy to hear you out and would prefer that than your unregistered paranoia. Also, sorry for being harsh but this kind of attitude just deters people from contributing to open source unless they follow the 'elite' practices of the hivemind.
    - jdiez17 13y ago
      >Register Global has been depreciated since two versions ago and even completely removed since the last version. Follow your own posted link [1] and it says it right on top with a big ass banner. Well, the vast majority of people would not consult the documentation for register_globals when it was the default. Sure, it's deprecated now, but... what the hell, who thought it was a good idea in the first place? Oh yeah, the same people who built PHP as a hack designed for a very specific purpose that grew out of proportion too quickly. > Register Global has been depreciated since two versions ago and even completely removed since the last version. Follow your own posted link [1] and it says it right on top with a big ass banner. The Active Record stuff was a vulnerability in a LIBRARY. The register_globals stuff was a vulnerability in THE CORE LANGUAGE. Those are two very, very different things. Also, it's a bug rather than a design decision. >Also, sorry for being harsh but this kind of attitude just deters people from contributing to open source unless they follow the 'elite' practices of the hivemind. I encourage as many people as I can to contribute to open source. I also consider myself an experienced software developer, so I feel like it is my responsibility to educate people and prevent them from shooting themselves in the foot. PHP makes it very easy to do this.

by jdiez17 13y ago

The interface looks very nice but no thanks, I'm not going to install PHP on my servers to have it. I'd totally set it up if it weren't for PHP. The risk is just too great to ignore.

kodablah 13y ago

Some server side code is required to obtain the data. Out of curiosity, what would it have to be written in to make you feel safe?

jdiez17 13y ago
In anything that is not PHP. Bash would have been perfect for this use case, for example. The correct way to do this is to obtain the data separately and merely show it on the interface. I haven't audited the code, so I don't know what's being passed to the shell commands, but the fact that an attacker MIGHT be able to influence the commands being executed (see register_globals, etc (yes, I know this has been disabled by default in recent versions of PHP)) is enough for me to completely write it off as an unnecesary risk. By collecting the data periodically (i.e a cron job) you eliminate most possible vulnerabilities.
- kodablah 13y ago
  First you say anything not PHP then you don't mention one. While I agree that off-request collection may be wiser, I fail to see anything mentioned better than PHP unless you're seriously mentioning Bash to write a webapp like this. Mentioning an old security concern that is no longer an issue seems like an easy way to discount every possible language.
  - jdiez17 13y ago
    I said that a bash script would be perfect for collecting data periodically and saving it to a file, I wasn't suggesting that you use it to write a web app. I thought that was clear; apologies if it wasn't. However, you say that this is an easy way to discount every possible language: can you point me to a vulnerability on the same level as register_globals in any other language?
bradleyland 13y ago
Server monitoring applications, by their nature, have to interact with the system by issuing the commands that will collect data. The most common solution is to separate the application in to two parts: Back-end: a daemon process that runs at an interval, collecting data and writing it to a data store. Front-end: connects to the data store, processes statistics, and formats for display. By constructing your application in this way, the data store acts as a firewall between the system calls required to collect the data and the interface used to view the data. Your daemon application needn't listen on any network ports if it is running locally. Your web application still needs to be secure, but you don't have the additional risk of many calls to system/shell exec commands that are a honey pot for exploitation.

rschmitty 13y ago

Have you even looked at the (trivial amount) of PHP source code? Where is PHP going to be attacked? Perhaps I am missing something obvious but it seems like PHP is running some linux commands and parsing the results, not sure how this would be different/safer in another language? Also you can put it behind http auth or restrict the vhost by IP etc

jdiez17 13y ago
It's not how much PHP is running, it's that PHP is running _at all_. It makes me feel very, very uneasy that every time that web interface is hit PHP executes a shell command. There's something inherently wrong about that, to me.
- deanclatworthy 13y ago
  Unless the script accepts parameters, which it doesn't, there's nothing to worry about.
  - jdiez17 13y ago
    Like I said in a previous reply, see register_globals and company. Sure, that was some time ago. Sure, the defaults are better now. But at some point in time the people in charge of PHP thought "yes, this is a good idea, let's do it". ... It's not like the attitude has changed, though. There are many, many things deeply wrong with PHP when it comes to security. PHP is supposed to cater to unexperienced programmers. An unexperienced programmer might see "mysql_escape_string" and think that it will escape strings, making them suitable for use in SQL queries. The programmer will think the code is secure. WRONG. Because you have to use mysql_REAL_escape_string. Also, look at the `e` flag in preg_replace. WHAT THE FUCK. Like, seriously. What. Why. There are no words to describe how gobsmacked I am. And FOUR people in the PHP committee (or whatever it's called) voted __AGAINST__ deprecating it. FOUR. [1] -- The point is that I can't audit (and would rather not waste my time doing so) this PHP code. The fact that it uses shell_execute when a HTTP request demands it is enough of a red flag. [1] https://wiki.php.net/rfc/remove_preg_replace_eval_modifier https://wiki.php.net/rfc/remove_preg_replace_eval_modifier

condiment 13y ago

I had the same attitude, so I forked it and rewrote the PHP endpoints as a Python script, which I execute outside of the context of the application via a cronjob. https://github.com/arbuckle/linux-dash https://github.com/arbuckle/linux-dash

jdiez17 13y ago
Thanks, that's how it should be done. I don't care if the collection script is written in Python, Ruby, Node JS or Brainfuck; it shouldn't execute shell commands when it receives a HTTP request.
itsderek23 13y ago
Checkout https://github.com/scoutapp/server_metrics https://github.com/scoutapp/server_metrics (Ruby - gem install server_metrics). Grabs all the key server + process metrics, handles Linux memory cache, etc. Requires a distro w/ "proc" functionality for the most metrics.
e12e 13y ago
Thanks, this architecture makes more sense imnho. Between this and the other thread on monitoring solutions, I wonder if it would be worth it to write a snippet that takes data from sar [ed:sar/sysstat or perhaps conky] and dumps out json that works with this dash...

damiongrimfield 13y ago

"The risk is just too great to ignore." Can you elaborate on this? I'm looking for you to clarify which other dynamic languages would be considered less risky in this specific application and why.

jdiez17 13y ago
Other dynamic languages have similar risks but at least they don't have a history[1,2] of making completely stupid decisions when it comes to security. However, I'd rather not have a program execute a shell command when it receives a PHP request. Written in PHP or not. It's just wrong. [1] http://www.php.net/manual/en/security.globals.php http://www.php.net/manual/en/security.globals.php [2] https://bugs.php.net/bug.php?id=47796 https://bugs.php.net/bug.php?id=47796
- nivla 13y ago
  Register Global has been depreciated since two versions ago and even completely removed since the last version. Follow your own posted link [1] and it says it right on top with a big ass banner. >Other dynamic languages have similar risks but at least they don't have a history[1,2] of making completely stupid decisions when it comes to security. Yes like Ruby and Active Records SQL injection debacle where Github was pwned and the developers din't seem to care? I can't argue that PHP is better than other languages, but holding it to f*ck ups from over 5+ years ago, most of which have been fixed, is a low. If you can find something vulnerable within this open source coded, then I happy to hear you out and would prefer that than your unregistered paranoia. Also, sorry for being harsh but this kind of attitude just deters people from contributing to open source unless they follow the 'elite' practices of the hivemind.
  - jdiez17 13y ago
    >Register Global has been depreciated since two versions ago and even completely removed since the last version. Follow your own posted link [1] and it says it right on top with a big ass banner. Well, the vast majority of people would not consult the documentation for register_globals when it was the default. Sure, it's deprecated now, but... what the hell, who thought it was a good idea in the first place? Oh yeah, the same people who built PHP as a hack designed for a very specific purpose that grew out of proportion too quickly. > Register Global has been depreciated since two versions ago and even completely removed since the last version. Follow your own posted link [1] and it says it right on top with a big ass banner. The Active Record stuff was a vulnerability in a LIBRARY. The register_globals stuff was a vulnerability in THE CORE LANGUAGE. Those are two very, very different things. Also, it's a bug rather than a design decision. >Also, sorry for being harsh but this kind of attitude just deters people from contributing to open source unless they follow the 'elite' practices of the hivemind. I encourage as many people as I can to contribute to open source. I also consider myself an experienced software developer, so I feel like it is my responsibility to educate people and prevent them from shooting themselves in the foot. PHP makes it very easy to do this.