Can Unix Anonymous Pipes Be Eavesdropped On (By a Non-Root User)?
Datesfat Chicks
from a PHP script) and also to get back the output.
I didn't use command-line arguments because these are insecure.
Is an anonymous pipe secure from other UIDs?
Thanks, Datesfat
William Ahern
They're as secure as any other descriptor, such as to a socket or file.
Barry Margolin
William Ahern <wil...@wilbur.25thandClement.com> wrote:
More so. An anonymous pipe doesn't exist in the filesystem, so you
can't inadvertently chmod it incorrectly.
There's no API to access the data in an anonymous pipe, except by the
process that created it and its descendants. You'd need to read kernel
memory to do it from another process, and this requires root privileges.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
William Ahern
> In article <2a39s6-...@wilbur.25thandClement.com>,
> William Ahern <wil...@wilbur.25thandClement.com> wrote:
>
> > Datesfat Chicks <datesfa...@gmail.com> wrote:
> > > I'm using pipes to pass sensitive information to a child process (spawned
> > > from a PHP script) and also to get back the output.
> >
> > > I didn't use command-line arguments because these are insecure.
> >
> > > Is an anonymous pipe secure from other UIDs?
> >
> > They're as secure as any other descriptor, such as to a socket or file.
>
> More so. An anonymous pipe doesn't exist in the filesystem, so you
> can't inadvertently chmod it incorrectly.
>
> There's no API to access the data in an anonymous pipe, except by the
> process that created it and its descendants. You'd need to read kernel
> memory to do it from another process, and this requires root privileges.
I was hesitant to make that assertion, and too lazy to confirm it, but
you've forced my hand ;)
Compile the following and simply execute `cat $(./foo)`. Confirmed to work
on Ubuntu Linux, kernel 2.6.28-15-generic, with /proc mounted. That puts
anonymous pipes squarely in the realm of file system addressable _and_
accessible objects. I'm unable to change the mode on that file, but strictly
speaking that's beside the point. Perhaps a socket pair might be more
trouble, but I think prudence dictates that in analyzing the security of
anonymous pipes one should simply include them in the class of general file
descriptors and move on to more important concerns.
#include <stdio.h>
#include <unistd.h>
int main(void) {
int fd[2], pid, i, n;
char buf[32];
pipe(fd);
if ((pid = fork())) {
printf("/proc/%d/fd/%d\n", pid, fd[0]);
return 0;
}
close(0);
close(1);
close(2);
for (i = 0; i < 1U<<14; i++) {
n = sprintf(buf, "%d\n", i);
write(fd[1], buf, n);
}
return 0;
} /* main() */
Datesfat Chicks
news:hh0as6-...@wilbur.25thandClement.com...
You've confused me a bit. Your program does not demonstrate that a process
that is neither parent nor child can access the pipe. So Barry's comments
seem correct.
Did I miss something?
Thanks, Datesfat
William Ahern
> You've confused me a bit. Your program does not demonstrate that a process
> that is neither parent nor child can access the pipe. So Barry's comments
> seem correct.
> Did I miss something?
Yes. In this case it's neither parent nor even ancestor doing the read. With
`cat $(./foo)` the shell first forks and executes foo, which prints a file
path string, [forks again,] and blocks on the write. The string is then
passed to cat with another fork from the shell, so there's no lineal descent
between the cat process and the process which created the pipe, and
certainly no descriptor inheritance.
Anyhow, you can just skip the whole `cat $(./foo)` business; I just provided
it for completeness. Execute the program, then login in on another terminal
and cat--or otherwise attempt to open + read--the printed file path. This
worked for me as well.
Stephane CHAZELAS
[...]
> You've confused me a bit. Your program does not demonstrate that a process
> that is neither parent nor child can access the pipe. So Barry's comments
> seem correct.
$ echo this | sleep 999 &
[1] 4396 4397
$ cat /proc/4397/fd/0
this
$ sleep 999 | tr a b &
[1] 4401 4402
$ echo aaa > /proc/4401/fd/1
bbb
--
Stï¿œphane
Rainer Weikusat
<sarcasm>
Congratulations. You have just demonstrated that users are allowed to
read their own files.
</sarcasm>
Until David Woodhouse comes along and changes the default mode for
/proc-files to 0666 because security is nowadays done differently,
that's sufficiently save from eavesdroppers.
Casper H.S. Dik
For what it's worth, Solaris' proc filesystem doesn't allow you to
open such files using /proc. Ordinary files, I believe yes, but
then it works like "dup()".
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Datesfat Chicks
news:87y6mlc...@fever.mssgmbh.com...
Thanks. I believe this level of security is sufficient for my application.
My application is that I have a web script (PHP) invoking a compiled C
executable, and passing sensitive information via a pipe and getting a
non-sensitive result back via a pipe. The sensitive information is a
cryptographic device key.
The web server and the C executable will both run under the UID/GID of the
web server. No possible attacker in the system will be able to run a
process under that UID/GID. So I'm satisfied with this result.
However, other processes with the same UID/GID being able to intercept what
goes on between parent and child could, in other contexts, be a security
problem. So I'll remember what was demonstrated in this thread.
Thanks for all.
Datesfat.
William Ahern
> Stephane CHAZELAS <stephane...@yahoo.fr> writes:
<snip>
> > $ echo this | sleep 999 &
> > [1] 4396 4397
> > $ cat /proc/4397/fd/0
> > this
> >
> > $ sleep 999 | tr a b &
> > [1] 4401 4402
> > $ echo aaa > /proc/4401/fd/1
> > bbb
> <sarcasm>
> Congratulations. You have just demonstrated that users are allowed to
> read their own files.
> </sarcasm>
The sarcasm seems a little unwarranted. The point was exactly to show that
anonymous pipes could be accessible just like _files_.
> Until David Woodhouse comes along and changes the default mode for
> /proc-files to 0666 because security is nowadays done differently,
> that's sufficiently save from eavesdroppers.
You're clearly missing the point. We've gone from a system where anonymous
pipes are unique because you can't even derive a reference to them, period,
to where you're depending on mode permissions. The profile is totally
different. Whether one or the other is more or less safe is completely
beside the point of this sub-thread.
But actually, now that I think about it, you're flat wrong, anyhow.
The OP is presumably validating passwords entered into a web form and
submitted to a CGI script. Assume, arguendo, that the OP is using PHP.
Assume, arguendo, that the OP is executing a setuid utility, so that the web
server doesn't actually have direct access to the password database. Now,
let's also assume (and I know this is a big leap, because PHP has such a
stellar track record) that an attacker finds an exploit in some script that
allows him to, say, do something as simple as
"passthru(fopen(/proc/N/fd/N))". Said attacker can now collect passwords.
So, the difference is significant. This is why I use OpenBSD, which not only
has no /proc, but which chroot's Apache and randomizes PID's. Of course, the
OP could configure his Linux system to chroot his web server, and to make
sure that /proc is not mounted inside the chroot. Or, the OP could do
nothing, judging the scenario to be inconsequential. Both valid options, but
options to be considered because there really is a distinction here.
Rainer Weikusat
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>> Stephane CHAZELAS <stephane...@yahoo.fr> writes:
> <snip>
>> > $ echo this | sleep 999 &
>> > [1] 4396 4397
>> > $ cat /proc/4397/fd/0
>> > this
>> >
>> > $ sleep 999 | tr a b &
>> > [1] 4401 4402
>> > $ echo aaa > /proc/4401/fd/1
>> > bbb
>
>> <sarcasm>
>> Congratulations. You have just demonstrated that users are allowed to
>> read their own files.
>> </sarcasm>
>
> The sarcasm seems a little unwarranted. The point was exactly to show that
> anonymous pipes could be accessible just like _files_.
The subject of the thread is 'Can Unix Anonymous Pipes Be Eavesdropped
On (By a Non-Root User)?' and the answer is 'they cannot'.
>> Until David Woodhouse comes along and changes the default mode for
>> /proc-files to 0666 because security is nowadays done differently,
>> that's sufficiently save from eavesdroppers.
>
> You're clearly missing the point.
Nope. You were missing the reference to a recent 'Linux exploit' which
was only possible because the /dev/net/tun default permissions, as
nowadays set by udev for anyone who actually wants to run this
program, had been changed to 0666 'because the code is nowadays doing
capability checks'.
> We've gone from a system where anonymous
> pipes are unique because you can't even derive a reference to them, period,
> to where you're depending on mode permissions.
... which are set to a fixed value when the corresponding /proc
pseudofile is created.
[...]
> But actually, now that I think about it, you're flat wrong, anyhow.
>
> The OP is presumably validating passwords entered into a web form and
> submitted to a CGI script. Assume, arguendo, that the OP is using PHP.
> Assume, arguendo, that the OP is executing a setuid utility, so that the web
> server doesn't actually have direct access to the password database. Now,
> let's also assume (and I know this is a big leap, because PHP has such a
> stellar track record) that an attacker finds an exploit in some script that
> allows him to, say, do something as simple as
> "passthru(fopen(/proc/N/fd/N))". Said attacker can now collect
> passwords.
If 'an attacker' can execute code written by him as the user the
web server runs as, security has quite obviously been compromised and
bad things are bound to happen. But this digression is in no way
related to the question if unprivileged users can 'eavesdrop' on pipes
created by other users. They cannot.
Scott Lurndal
>William Ahern <wil...@wilbur.25thandClement.com> writes:
>> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>>> Stephane CHAZELAS <stephane...@yahoo.fr> writes:
>> <snip>
>>> > $ echo this | sleep 999 &
>>> > [1] 4396 4397
>>> > $ cat /proc/4397/fd/0
>>> > this
>>> >
>>> > $ sleep 999 | tr a b &
>>> > [1] 4401 4402
>>> > $ echo aaa > /proc/4401/fd/1
>>> > bbb
>>
>>> <sarcasm>
>>> Congratulations. You have just demonstrated that users are allowed to
>>> read their own files.
>>> </sarcasm>
>>
>> The sarcasm seems a little unwarranted. The point was exactly to show that
>> anonymous pipes could be accessible just like _files_.
>
>The subject of the thread is 'Can Unix Anonymous Pipes Be Eavesdropped
>On (By a Non-Root User)?' and the answer is 'they cannot'.
Sure they can, so long as the "non-root user"[*] has the same UID. Since
the OP was in the context of PHP, one can assume that it is running using
the apache (or apache2) UID. I think one should be concerned about this;
PHP isn't known as the most secure form of CGI.
scott
[*] OP _didn't_ say 'different non-root user'.
Barry Margolin
William Ahern <wil...@wilbur.25thandClement.com> wrote:
Since a process can read the memory of other processes belonging to the
same UID, this doesn't really give them access to anything they didn't
already have access to.
Another thing: I think reading the pipe this way is not passive.
Anything read by the interceptor will not be seen by the original reader
of the pipe, and vice versa. So you can't really eavesdrop on the
conversation, because you'll interrupt it.
Rainer Weikusat
> Rainer Weikusat <rwei...@mssgmbh.com> writes:
[...]
>>The subject of the thread is 'Can Unix Anonymous Pipes Be Eavesdropped
>>On (By a Non-Root User)?' and the answer is 'they cannot'.
>
> Sure they can, so long as the "non-root user"[*] has the same UID.
Quoting myself:
But this digression is in no way related to the question if
unprivileged users can 'eavesdrop' on pipes
created by other users. They cannot.
[...]
> [*] OP _didn't_ say 'different non-root user'.
Meanwhile, he did.
Rainer Weikusat
> In article <sgbbs6-...@wilbur.25thandClement.com>,
> William Ahern <wil...@wilbur.25thandClement.com> wrote:
>> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>> > Stephane CHAZELAS <stephane...@yahoo.fr> writes:
>> <snip>
>> > > $ echo this | sleep 999 &
>> > > [1] 4396 4397
>> > > $ cat /proc/4397/fd/0
>> > > this
>> > >
>> > > $ sleep 999 | tr a b &
>> > > [1] 4401 4402
>> > > $ echo aaa > /proc/4401/fd/1
>> > > bbb
[...]
> Another thing: I think reading the pipe this way is not passive.
> Anything read by the interceptor will not be seen by the original reader
> of the pipe, and vice versa. So you can't really eavesdrop on the
> conversation, because you'll interrupt it.
If the process which has access to the read-end of the pipe also has
access to the write-end, it can also write new data by going through
the /proc-file. In theory, that's a classic man-in-the-middle-attack
except that sufficient privileges to cause mischief to both of the
communicating processes must already be available.
Stephane CHAZELAS
[...]
>>>The subject of the thread is 'Can Unix Anonymous Pipes Be Eavesdropped
>>>On (By a Non-Root User)?' and the answer is 'they cannot'.
>>
>> Sure they can, so long as the "non-root user"[*] has the same UID.
>
> Quoting myself:
>
> But this digression is in no way related to the question if
> unprivileged users can 'eavesdrop' on pipes
> created by other users. They cannot.
>
> [...]
>
>> [*] OP _didn't_ say 'different non-root user'.
>
> Meanwhile, he did.
They can be eavesdropped by a different user with the same uid,
or any non-root user with uid 0 ;-).
--
Stï¿œphane
Rainer Weikusat
For the purpose of UNIX(*), a 'user' is an entity identified by a
particular user id. For obvious reasons, no 1:1 mapping of UNIX(*)
user IDs and 'intelligent beings on this planet' exists.
Barry Margolin
Rainer Weikusat <rwei...@mssgmbh.com> wrote:
It seems to me that it would be very difficult to make this work. If
two processes are both reading from the pipe, it's unpredictable which
one will get any particular block of data. And if the MITM tries to
write back, his write may end up out of order.
Actually, it might not be so hard, now that I think some more. Since
this MITM has to be either root or the same UID as the pipe owner, it
can also send the reader and writer processes SIGSTOP and SIGSTART. So
it can stop the regular processes, read what it wants, write it back,
then start them up again. Kind of like Hiro in Heroes....
Golden California Girls
> Actually, it might not be so hard, now that I think some more. Since
> this MITM has to be either root or the same UID as the pipe owner, it
> can also send the reader and writer processes SIGSTOP and SIGSTART. So
> it can stop the regular processes, read what it wants, write it back,
> then start them up again. Kind of like Hiro in Heroes....
Why go to this length, just become the debugger of the program and intercept the
system calls.
William Ahern
> In article <sgbbs6-...@wilbur.25thandClement.com>,
> William Ahern <wil...@wilbur.25thandClement.com> wrote:
> > You're clearly missing the point. We've gone from a system where anonymous
> > pipes are unique because you can't even derive a reference to them, period,
> > to where you're depending on mode permissions. The profile is totally
> > different. Whether one or the other is more or less safe is completely
> > beside the point of this sub-thread.
> Since a process can read the memory of other processes belonging to the
> same UID, this doesn't really give them access to anything they didn't
> already have access to.
That argument just isn't valid. In as much as there can be bugs at any
level, including at the kernel and hardware level, you can't argue that any
possible security system can be logically reduced to no security just
because there are a series of steps you can take to break every link in the
chain.
Languages such as PHP and Java are designed to _prevent_ access to
system-level calls, including signaling. You can't say that just because you
could use signals and/or process tracing that the /proc issue is
meaningless. On the contrary, the /proc issue is important because it's far
easier to use in an exploit than some other means requiring breaking out of
the interpreter and doing ad-hoc system calls. If one could simply discount
any measure in order to argue against a distinction, one could discount all
measures and nullify all distinctions.
As a practical matter, you're certainly right. Privilege separation,
including using separate UIDs to prevent interprocess signaling, is
important, and I can appreciate reducing security analyses in some contexts
to canonical scenarios that rest upon distinctions the kernel enforces. Yet
in that case, the vast majority of all web applications' security models
(which ultimately rest upon one web process UID with unfettered access to
all data) completely fail your security analysis. In fact, I completely
agree that the state of things is ridiculous. But that's a completely
unproductive way to approach the issue, in general, and in this case in
particular.
System authentication in BSD/OS and OpenBSD uses a design very similar to
the OP's--communicating to an authentication agent through an anonymous
pipe. I think people would be less inclined to discount the issue in that
context. At a minimum I would think there'd be warning messages in man pages
or elsewhere that remind people about the issue.
K-mart Cashier
wrote:
I don't think that would work if the debugging symbols got stripped
from a program. Here is what I get when I attempt to debug a stripped
program.
[cdalten@localhost oakland]$ file zero
zero: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux
2.6.9, stripped
[cdalten@localhost oakland]$ gdb zero
GNU gdb Red Hat Linux (6.5-8.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) disassemble main
No symbol table is loaded. Use the "file" command.
(gdb)
Måns Rullgård
> On Nov 6, 11:31�pm, Golden California Girls <gldncag...@aol.com.mil>
> wrote:
>> Barry Margolin wrote:
>> > Actually, it might not be so hard, now that I think some more. �Since
>> > this MITM has to be either root or the same UID as the pipe owner, it
>> > can also send the reader and writer processes SIGSTOP and SIGSTART. �So
>> > it can stop the regular processes, read what it wants, write it back,
>> > then start them up again. �Kind of like Hiro in Heroes....
>>
>> Why go to this length, just become the debugger of the program and
>> intercept the system calls.
>
> I don't think that would work if the debugging symbols got stripped
> from a program. Here is what I get when I attempt to debug a stripped
> program.
You can always intercept the system calls, debugging symbols or not.
Try running a stripped executable under strace and see for yourself.
--
M�ns Rullg�rd
ma...@mansr.com
Geoff Clare
> For the purpose of UNIX(*), a 'user' is an entity identified by a
> particular user id.
Not always. From the SUSv4 description of getlogin():
If getlogin() returns a non-null pointer, then that pointer points
to the name that the user logged in under, even if there are
several login names with the same user ID.
--
Geoff Clare <net...@gclare.org.uk>
Stephane CHAZELAS
I was looking at SUSv4 as well, and there's possible confusion
about whether there may be more than one user name per user id.
In the definition section, both user name and user id are used
to determine a user is the user database. One can read that as
- one user id determines one user
- one user name determines one user
- so there can only be one user name per user id.
The getpwuid() leaves it open whether there may be more than one
user per uid, but is not very explicit and gives no pointer on
how to retrieve the other matching users, or if 2 subsequent
calls to the function are likely to retrieve the same entry
(assuming the database has not been modified inbetween)
SUSv4's getpwnam() seems to also allow more than one user for a
user name, though I don't know of any Unix implementation where
the login name is not a unique key in the user database.
The example section has this though:
SUSv4> The following example uses the getlogin() function to
SUSv4> return the name of the user who logged in; this
SUSv4> information is passed to the getpwnam() function to get
SUSv4> the user database entry for that user.
~~~
I'd have expected "...to get a user database entry for that user
name" given that getpwnam() is only meant to retrieve _a_
matching entry.
--
Stï¿œphane
Gordon Burditt
>about whether there may be more than one user name per user id.
UID sharing seems to be done for two purposes:
- Having more than one password file entry with different parameters
(and deliberately shared file ownership)
- A throwback to early UNIX where there were only 256 distinct UIDs.
(and reluctantly shared file ownership)
The FreeBSD password file comes with two UID 0 entries, 'root' and
'toor', which differ in the shell. Occasionally I have seen a third
entry, 'shutdown', intended for the building maintenance staff to
shut down the system in an emergency (air conditioning failure,
scheduled power outage, etc.) In this case the idea is that 'shutdown'
will have a different password.
UUCP is often set up (if it's still used at all) with 'uucpmgr',
with a normal shell, for the person administering UUCP, and one or
more accounts like 'uucp', which is for other UUCP peers to log in
(using uucico as the shell). Sometimes there are individual uucp
accounts for each peer system, to avoid shared passwords. Often,
these all have the same UID.
I'd like to think that the reluctantly-shared file ownership due to
shortage of UID numbers is long gone. That might be wishful thinking.
>In the definition section, both user name and user id are used
>to determine a user is the user database. One can read that as
> - one user id determines one user
> - one user name determines one user
> - so there can only be one user name per user id.
>
>The getpwuid() leaves it open whether there may be more than one
>user per uid, but is not very explicit and gives no pointer on
>how to retrieve the other matching users, or if 2 subsequent
>calls to the function are likely to retrieve the same entry
>(assuming the database has not been modified inbetween)
You can repeatedly call getpwent() looking for entries with a matching
UID. This will retrieve the other matching users.
BSD documentation for getpwuid says you get "the first one encountered".
That suggests repeatability.
>SUSv4's getpwnam() seems to also allow more than one user for a
>user name, though I don't know of any Unix implementation where
>the login name is not a unique key in the user database.
That would seem to present problems with logging in, having multiple
different passwords, home directories, and UIDs.