Projects / PHP Shell

PHP Shell

PHP Shell is a shell wrapped in a PHP script. It's a tool you can use to execute arbiritary shell-commands or browse the filesystem on your remote Web server. This replaces, to a degree, a normal telnet-connection. You can use it for administration and maintenance of your Web site using commands like ps, free, du, df, and more.

Tags
Licenses
Operating Systems
Implementation

Recent releases

  •  16 Feb 2012 21:28

    Release Notes: This release fixes a bug which caused PHP Shell to stop working if the current directory was removed or made unreadable by the user or another process, some encoding problems, and Safe-mode-warning not displaying correctly.

    •  11 Dec 2011 15:07

      Release Notes: This release adds a file upload feature (not enabled by default), fixes a strange UTF-8 bug, and adds an internal history command. The prompt $PS1 is now configurable. Commands with HTML entities (e.g.: echo "ü") were displayed encoded in the output, and there are some other minor bugfixes.

      •  19 Dec 2010 14:49

        Release Notes: This version works with recent PHP versions. (PHP Shell 2.1 had a problem with PHP versions earlier than 5.3.) Navigation in the filesystem using hyperlinks is once again possible. Other small bugs were fixed.

        •  27 Dec 2005 05:10

          Release Notes: Authentication is now handled internally in PHP in an attempt to solve reported login problems. Configuration settings were moved to an ini file, and handling of PHP Safe Mode was improved with better error messages.

          •  27 Mar 2004 07:58

            Release Notes: The shell now has a command line history just like a real shell, and the design was changed to mimic a real shell more closely. The parsing of 'cd' commands was rewritten so that even more special cases are taken care of, and simple command substitution using aliases has been introduced.

            Recent comments

            26 Oct 2006 03:52 mgeisler

            Re: Potential security issue


            > Now, I'm not an alarmist. I'm also very

            > strict about backing up everything on

            > any of my own or clients' domains -

            > files, databases, and so on. So a

            > hacking isn't going to kill us.

            > Regardless, no one wants to deal with

            > the fallout!

            >

            > My point to commenting here is simply to

            > let you know this seems to be a growing

            > problem, and to suggest that there might

            > be some way you could provide some

            > limits within the program to prevent

            > this type of use. I have no idea of

            > course if that would even be possible.

            You have some good points --- it's unfortunate but correct that PHP Shell has been used for finding passwords (since database passwords are written in plain text in most PHP scripts).

            As for what one can do about it: run PHP as a CGI in which case I believe it assumes the real user ID of the user who own the script. Then the normal filesystem rules apply to the PHP process as well as to any other process on the system and it is then easy to restrict access to sensible files.

            There might be other ways to have Apache run PHP as the correct user, but it's not something I've spend a lot of time on.

            25 Oct 2006 13:31 vkaryl

            Potential security issue
            I use a variety of php scripts, including wordpress, cubecart, tolra web directory, etc.

            Several times lately, people using those scripts have been hacked by crackers using phpshell and other similar scripts. (I haven't - I just seem to be the only person around the fora who thought it might be worthwhile to contact you....)

            The modum operandum is simple: the cracker hooks up phpshell etc. to a domain on shared server space, and browses until s/he finds a database or other configuration information, then uses that from within phpshell to pry open anything they want (or so it seems from reading....)

            Now, I'm not an alarmist. I'm also very strict about backing up everything on any of my own or clients' domains - files, databases, and so on. So a hacking isn't going to kill us. Regardless, no one wants to deal with the fallout!

            My point to commenting here is simply to let you know this seems to be a growing problem, and to suggest that there might be some way you could provide some limits within the program to prevent this type of use. I have no idea of course if that would even be possible.

            Thanks.

            Screenshot

            Project Spotlight

            OpenStack4j

            A Fluent OpenStack client API for Java.

            Screenshot

            Project Spotlight

            TurnKey TWiki Appliance

            A TWiki appliance that is easy to use and lightweight.