On January 26, 2012 2:50 , Tarzan Jane
<lapierre62@xxxxxxxxxxx> wrote:
If you use binary executable instead of interpreted scripts, it's true that you eliminate some security concerns. For example, the attacker cannot provide high level code for the binary to interpret at runtime unless the binary contains its own interpreter for some reason (or invokes an external interpreter, which you may not be aware of in all cases). However, there are still many security concerns which still exist. And there are types of attacks that binary executables are *more* vulnerable to than scripts -- for example, buffer overflow and/or stack smashing attacks. If you have your web server run binaries as root, it is critical that you pay extra attention to security. Completely audit the source code for these binaries, looking for security vulnerabilities. Pay particular attention to completely sanitizing all input that the binaries receive from untrusted sources (at a minimum, all input received from the web server, but depending on what your binary does, potentially input from files, IO pins or other sources too). If an attacker has the ability to replace an executable, you have a *huge* security hole in your web server configuration that is in no way related to the binary itself. But hopefully you have explicitly configured your system to disallow this. However, it is *very* possible to inject code into a running binary. This is how a buffer overflow attack (as well as several other types of attacks) works. It's true that you need to know what type of processor is being used, but if you have someone who is looking to compromise your system in particular (as opposed to a "script kiddie" who is merely looking for vulnerable MS Windows machines), then this is very easy to determine experimentally, and there are also situations in which Apache HTTP Server itself (and/or other services running on your machine) can provide this information to the attacker. In addition to buffer overflows, watch out for integer overflows, format string attacks, directory traversal attacks, injection into inputs of other services used by the binary (e.g., SQL injection, if your binary uses a SQL database, or shell injection if your binary uses the system() function from the C standard library), cross-site scripting, HTTP header injection or splitting, and race conditions (including but not limited to filename or symlink races), among others. Bottom line: using a compiled binary does not improve security per se, it merely reduces the need to worry about one class of attacks while increasing the need to worry about others. And running a CGI as root is very dangerous regardless of whether the CGI is compiled or interpreted, which is why you should grant the necessary privileges to read the IO pins (and *only* those privileges) to the www-data user, if possible. -- Mark Montague mark@xxxxxxxxxxx |
|