4 ms·

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 P

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
    - SnacksOnAPlane 13y ago
      But you can totally audit the PHP code. There honestly isn't that much of it, and absolutely none of it takes user input. I'd be way more concerned if this was a Rails or Django app, because then there would be lots of library code to worry about.
      - anglebracket 13y ago
        It doesn't take input from the user, but it does use untrusted input in a way that allows XSS. See https://news.ycombinator.com/item?id=7128442 https://news.ycombinator.com/item?id=7128442 .
    - anglebracket 13y ago
      > WRONG. Because you have to use mysql_REAL_escape_string. Using mysql_real_escape_string is almost a sign you're doing something wrong. You should be using prepared statements with PDO or mysqli. > The point is that I can't audit (and would rather not waste my time doing so) this PHP code. I wasn't going to bother, but this post is pretty high up on the front page. There's some XSS issues with the JSON output, the Content-Type header isn't set to 'application/json' so PHP decides to set it to 'text/html'. Now anyone that controls ipecho.net[0] or can execute commands as any user on the server[1] can XSS users of the panel. If you'd like to confirm, go to /sh/ps.php and notice where the page breaks due to strings in the JSON being interpreted as HTML. [0] https://github.com/afaqurk/linux-dash/blob/master/sh/ip.php#L6 https://github.com/afaqurk/linux-dash/blob/master/sh/ip.php#... [1] https://github.com/afaqurk/linux-dash/blob/master/sh/ps.php#L4 https://github.com/afaqurk/linux-dash/blob/master/sh/ps.php#...
      - deanclatworthy 13y ago
        But the XSS issues have nothing to do with the language choice. Python, ruby and any other langauge do nothing by default to protect you against such things either. I agree this is a poor choice of code, and an attack vector, but the language used here is not to blame.

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
  - SnacksOnAPlane 13y ago
    But you can totally audit the PHP code. There honestly isn't that much of it, and absolutely none of it takes user input. I'd be way more concerned if this was a Rails or Django app, because then there would be lots of library code to worry about.
    - anglebracket 13y ago
      It doesn't take input from the user, but it does use untrusted input in a way that allows XSS. See https://news.ycombinator.com/item?id=7128442 https://news.ycombinator.com/item?id=7128442 .
  - anglebracket 13y ago
    > WRONG. Because you have to use mysql_REAL_escape_string. Using mysql_real_escape_string is almost a sign you're doing something wrong. You should be using prepared statements with PDO or mysqli. > The point is that I can't audit (and would rather not waste my time doing so) this PHP code. I wasn't going to bother, but this post is pretty high up on the front page. There's some XSS issues with the JSON output, the Content-Type header isn't set to 'application/json' so PHP decides to set it to 'text/html'. Now anyone that controls ipecho.net[0] or can execute commands as any user on the server[1] can XSS users of the panel. If you'd like to confirm, go to /sh/ps.php and notice where the page breaks due to strings in the JSON being interpreted as HTML. [0] https://github.com/afaqurk/linux-dash/blob/master/sh/ip.php#L6 https://github.com/afaqurk/linux-dash/blob/master/sh/ip.php#... [1] https://github.com/afaqurk/linux-dash/blob/master/sh/ps.php#L4 https://github.com/afaqurk/linux-dash/blob/master/sh/ps.php#...
    - deanclatworthy 13y ago
      But the XSS issues have nothing to do with the language choice. Python, ruby and any other langauge do nothing by default to protect you against such things either. I agree this is a poor choice of code, and an attack vector, but the language used here is not to blame.