On January 26, 2012 2:50 , Tarzan Jane <lapierr...@hotmail.com> wrote:
Concerning the security I believe when using binary scripts, security
is increased some levels. Since the cgi binaries are no longer acsii
files, injecting or altering code is hardly possible. The only way to
breach security is to replace the binary itself. And for that you need
to know which type of processor is being used to produce the
correct executable. I can tell it's not Intel or AMD......
If I overlook something concering security please let me know.
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
m...@catseye.org