Security of Unix Pipes (with Application Details)

[David T. Ashley]

Thanks for the helpful replies on the other thread. Essentially it was
pointed out that a process with the same UID as the ones writing/reading the
pipes would be able to examine the memory of the pipe writers/readers and
figure out what data had flowed.

Here is my application (and I'd be grateful for any other advice).

I'm incorporating cryptographic FOBs into my PHP-based database application
to enhance login security.

A cryptographic FOB is an electronic device about the size of a keychain
that either displays sequential numbers to be used as one-time passwords or
else can allow you to enter a long number (the challenge) and will generate
a number in response (the reply) to be used as a password.

Here is a page with some photos of similar devices:

http://en.wikipedia.org/wiki/Security_token

The FOB contains a key (typically a 192-bit AES key) that is used for both
sequential one-time password generation and for challenge-reply.

Compromise of the FOB key is equivalent to breaking security (because with
the key one can emulate the FOB). The theory of operation of the FOB is
that one can observe a great many sequential numbers or challenge-response
cycles and the mathematical framework does not exist to use this information
to guess what the FOB will display next or how it will respond to a
different challenge, or to reverse-engineer the key.

The manufacturer of the FOB provides a Linux shared library to use in
authenticating the FOB. The library is essentially a cryptographic math
library. To determine, for example, what the FOB's response to a certain
challenge should be, one would make a call into the library with the FOB key
and the challenge, and the function will return what the FOB should answer.

I am not able to call a shared library directly from PHP. Instead, I have
to write a C program that is called (i.e. exec'd or similar) from PHP and
which uses the shared library.

Because the FOB key is one of the parameters that must be used with the
shared library, it must also be passed from PHP to the compiled C program.
Because the FOB key is so sensitive, the question is how to pass it from PHP
to the compiled program securely.

Passing the information on the command line is clearly not secure, because
program names and command-line parameters are world-visible on a Unix
system.

However, I was thinking that I could use the PHP proc_open() function:

http://us.php.net/manual/en/function.proc-open.php

to pass the information to the compiled C program's stdin and get
information back from stdout securely (without others being able to
eavesdrop).

If I've read everyone's posts correctly, the only security hole is if a
potential attacker could launch another process with the same UID.

I guess also I'd need to wipe memory before the compiled C program
terminates to get rid of any trace of the sensitive information (otherwise
the memory might be discovered by other processes later).

Any other suggestions or thoughts?

Thanks
--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

[Toby A Inkster]

David T. Ashley wrote:

I am not able to call a shared library directly from PHP. Instead, I have
to write a C program that is called (i.e. exec'd or similar) from PHP and
which uses the shared library.

Have you considered writing an extension to PHP? This is a compiled (C)
shared object that could interface between your PHP script and the library
in question.

I've not written one before, but I'm told they're easier than you'd expect.

--
Toby A Inkster BSc (Hons) ARCS
http://tobyinkster.co.uk/
Geek of ~ HTML/SQL/Perl/PHP/Python/Apache/Linux

[David T. Ashley]

"Toby A Inkster" <us**********@tobyinkster.co.ukwrote in message
news:fb************@ophelia.g5n.co.uk...

David T. Ashley wrote:

>I am not able to call a shared library directly from PHP. Instead, I
have
to write a C program that is called (i.e. exec'd or similar) from PHP and
which uses the shared library.

Have you considered writing an extension to PHP? This is a compiled (C)
shared object that could interface between your PHP script and the library
in question.

I've not written one before, but I'm told they're easier than you'd
expect.

This is an interesting idea. The only potential barrier in my case is that
I run Red Hat Enterprise Linux and I receive my PHP as packages from Red Hat
(which is great for me).

Does this involve recompiling PHP? Or does it involve some external work
that links to PHP? In other words, could I continue to use the pre-built
PHP packages from Red Hat?

Thanks.

[Rainer Weikusat]

"David T. Ashley" <dt*@e3ft.comwrites:

[...]

Because the FOB key is one of the parameters that must be used with the
shared library, it must also be passed from PHP to the compiled C program.
Because the FOB key is so sensitive, the question is how to pass it from PHP
to the compiled program securely.

Passing the information on the command line is clearly not secure, because
program names and command-line parameters are world-visible on a Unix
system.

However, I was thinking that I could use the PHP proc_open() function:

http://us.php.net/manual/en/function.proc-open.php

to pass the information to the compiled C program's stdin and get
information back from stdout securely (without others being able to
eavesdrop).

You could try something simple, like writing the key to a file only
readable by someone with the 'correct' UID and pass the name of the
file to the program via commandline argument.

[Paul Pluzhnikov]

"David T. Ashley" <dt*@e3ft.comwrites:

I am not able to call a shared library directly from PHP.

You should be able to write a PHP extension (another shared library)
which will wrap the vendor-supplied library and provide an interface
that PHP expects. You should be able to load that extension into
unmodified PHP packages you get from RedHat.

Because the FOB key is one of the parameters that must be used with the
shared library, it must also be passed from PHP to the compiled C program.
Because the FOB key is so sensitive, the question is how to pass it from PHP
to the compiled program securely.

There is no method that will be secure against debugger (even the
PHP extension is prone to debugger discovery of the secret).

If you ignore the debugger, encrypting (via plain XOR) the FOB key
with another key, which is known to your compiled C program and to
your PHP module is the answer. You can then pass the encrypted key
any way you want: on command line, via pipe, through the environment
variable, in shared memory, etc. etc.

Passing the information on the command line is clearly not secure, because
program names and command-line parameters are world-visible on a Unix
system.

And so are environment variables, and so are pipes, and so are files.
Any communication between your PHP process and your compiled C
program is very easy to "sniff" from another process with the same UID.

However, I was thinking that I could use the PHP proc_open() function:

http://us.php.net/manual/en/function.proc-open.php

to pass the information to the compiled C program's stdin and get
information back from stdout securely (without others being able to
eavesdrop).

Other processes with the same UID (or root) will be able to trivially
eavesdrop (as we told you before).

I guess also I'd need to wipe memory before the compiled C program
terminates to get rid of any trace of the sensitive information (otherwise
the memory might be discovered by other processes later).

I believe this attack is impossible on any modern UNIX -- the OS
will not give "dirty" RAM to another process.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[David T. Ashley]

"Rainer Weikusat" <rw*******@mssgmbh.comwrote in message
news:87************@fever.mssgmbh.com...

"David T. Ashley" <dt*@e3ft.comwrites:

[...]

>However, I was thinking that I could use the PHP proc_open() function:

http://us.php.net/manual/en/function.proc-open.php

to pass the information to the compiled C program's stdin and get
information back from stdout securely (without others being able to
eavesdrop).

You could try something simple, like writing the key to a file only
readable by someone with the 'correct' UID and pass the name of the
file to the program via commandline argument.

Yeah, this may be simplest of all. Now that everyone has shattered my
vision of pipes as secure, this is possible also. If you have a UID/GID
adequate to read the file, then you have a UID/GID adequate to eavesdrop on
pipes as well.

[Eric Sosman]

David T. Ashley wrote On 05/01/07 14:19,:

"Rainer Weikusat" <rw*******@mssgmbh.comwrote in message
news:87************@fever.mssgmbh.com...

>>"David T. Ashley" <dt*@e3ft.comwrites:

[...]

>>>However, I was thinking that I could use the PHP proc_open() function:

http://us.php.net/manual/en/function.proc-open.php

to pass the information to the compiled C program's stdin and get
information back from stdout securely (without others being able to
eavesdrop).

You could try something simple, like writing the key to a file only
readable by someone with the 'correct' UID and pass the name of the
file to the program via commandline argument.

Yeah, this may be simplest of all. Now that everyone has shattered my
vision of pipes as secure, this is possible also. If you have a UID/GID
adequate to read the file, then you have a UID/GID adequate to eavesdrop on
pipes as well.

Yeah, but opening and reading a named file in the
file system is noticeably easier than rummaging around
in the address space of a process. Can be done more
surreptitiously, too: I just have a little program that
sits around and waits for files to appear, then opens
and reads them as promptly as it can. Yes, some of them
will escape my notice -- but I'll get a steady trickle.

Meanwhile, attaching a debugger to a process that's
delivering a service has an unfortunate tendency to slow
down the service, or even to pause it for macroscopic
time. (The impact of truss and such isn't too bad, but
if you encrypt the traffic on the pipe the attacker is
going to need more than truss can reveal.) When your help
desk phones start ringing with folks complaining that they
can't log in, somebody's likely to take a look at what's
wrong on the authentication server, and there's the attacker
running gdb ...

As an attacker (not in real life, I hasten to add), I'd
feel lots less exposed snooping in the file system than I
would hunched over a gdb session.

Besides: I don't think I'd bother with your pipes or
temp files or shared memory or whatever else, at least not
for my first attempt. No, I'd go after the database with
which you associate user IDs to FOB keys. At least, that's
where I'd begin, until and unless it proved sufficiently
armored against my depraved schemes.

--
Er*********@sun.com

[Chung Leong]

On May 1, 4:44 pm, "David T. Ashley" <[e-mail]:

>
I guess also I'd need to wipe memory before the compiled C program
terminates to get rid of any trace of the sensitive information (otherwise
the memory might be discovered by other processes later).

If the FOB key passes through PHP, then it'll linger in memory in its
address space. I don't see any effective way you can wipe it in PHP.

[Rainer Weikusat]

Eric Sosman <Er*********@sun.comwrites:

David T. Ashley wrote On 05/01/07 14:19,:

>"Rainer Weikusat" <rw*******@mssgmbh.comwrote in message
news:87************@fever.mssgmbh.com...

>>>"David T. Ashley" <dt*@e3ft.comwrites:

[...]
However, I was thinking that I could use the PHP proc_open() function:

http://us.php.net/manual/en/function.proc-open.php

to pass the information to the compiled C program's stdin and get
information back from stdout securely (without others being able to
eavesdrop).

You could try something simple, like writing the key to a file only
readable by someone with the 'correct' UID and pass the name of the
file to the program via commandline argument.

Yeah, this may be simplest of all. Now that everyone has shattered my
vision of pipes as secure, this is possible also. If you have a UID/GID
adequate to read the file, then you have a UID/GID adequate to eavesdrop on
pipes as well.

Yeah, but opening and reading a named file in the
file system is noticeably easier than rummaging around
in the address space of a process.

[...]

As an attacker (not in real life, I hasten to add), I'd
feel lots less exposed snooping in the file system than I
would hunched over a gdb session.

If somebody is running processes with either your UID (or a more
priviledged one) on the machine that tries to 'attack' you, you are
toast. There is no need for a 'gdb session', just write a program that
attaches to the to-be-attacked process, use PTRACE_SYSCALL (Linux) to
stop it after each syscall and modifiy the running image to your
hearts content (like setting up a 'fake pipe' through the
eavesdropping program).

"I have taken great pains to be reasonably safe from stupid attackers"
doesn't sound that good.

[Toby A Inkster]

David T. Ashley wrote:

Does this involve recompiling PHP? Or does it involve some external work
that links to PHP? In other words, could I continue to use the pre-built
PHP packages from Red Hat?

I imagine that if you download and install the source RPM for PHP from Red
Hat, then you should be able to compile your extension against that source
code, without having to recompile PHP itself.

Certainly I have downloaded and compiled PHP extensions from PECL and I
didn't need to recompile the whole of PHP.

--
Toby A Inkster BSc (Hons) ARCS
http://tobyinkster.co.uk/
Geek of ~ HTML/SQL/Perl/PHP/Python/Apache/Linux