IMAP exposing /etc/passwd to iPhone?

IMAP exposing /etc/passwd to iPhone?

Post by John Murta » Thu, 19 Feb 2009 04:58:08

We try to be pretty careful with security, but this one
has us scratching our heads. We offer IMAP service to web hosting
customers and those accounts do NOT have shell access to the server.
They can only be used for IMAP or POP server access. We are
running RHEL 4 servers and authentication info is store in /etc/passwd.

We had a service call from a customer who wasn't very
technical and had seen 'strange stuff' on her iPhone. She said
a bunch of 'folders' got created that seemed to be account names.
From what we could confirm over the phone it looks like she had
a bunch of the userid's from an /etc/passwd file on the server?

She barely knows how to use the phone so it was hard
getting details on the setup. We are trying to get further details
now, but does anyone know of a way in the protocol for a client
to get the entire passwd file?

We are using a locally built version of UW-Imap; although
we are considering moving to whatever RHEL 4 packages
Customer Service Software Workshop Inc.
XXXX@XXXXX.COM "software that fits!" (TM)
Toll Free (877) 635-1968(x-211)

IMAP exposing /etc/passwd to iPhone?

Post by Sam » Thu, 19 Feb 2009 08:32:29

This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

John Murtari writes:

>> We are using a locally built version of UW-Imap; although >> we are considering moving to whatever RHEL 4 packages

UW-Imap maps IMAP namespace to the filesystem. What she probably did was
somehow get the IMAP client on her phone to send a command to the IMAP
server to open the folder directory named "..". The UW-IMAP server dutifully
obliged, and read the contents of the account's parent directory. So, if the
user account's home directory is /home/alice, she retrieved the contents of
/home, which probably contains subdirectories for all accounts on the
system, interpreted in the IMAP context as mail folder subdirectories.

UW-IMAP treats the name of an IMAP folder, or a folder directory, like an
ordinary filename/directory, and responds accordingly. The UW-IMAP server
can subsequently access anything that the process that imapd runs as can
access, according to ordinary POSIX filesystem permissions.

Version: GnuPG v1.4.9 (GNU/Linux)



IMAP exposing /etc/passwd to iPhone?

Post by Mark Crisp » Thu, 19 Feb 2009 09:53:36

On Tue, 17 Feb 2009, Sam posted:

Another way is if the client sends a leading / . If it asks to list /*
(note that the * wildcard is recursive in IMAP), imapd will dutifully list
ever path name that an unprivileged POSIX user can locate on the

By default, UW imapd's security settings are the host system's POSIX
security settings. Whether that is a bug or a feature depends entirely
upon individual point of view. It is instructive to read the old Bell
Labs UNIX papers...

You can disable UW IMAP's handling of / and .. by editing file

Look for the line which reads:
static long restrictBox = NIL; /* is a restricted box */

Change that line to:
static long restrictBox = RESTRICTROOT; /* is a restricted box */

Then rebuild.

There are other security mechanisms that you can enable in UW imapd as
well, including a chroot() jail. I personally don't recommend the use of
chroot() jails, as they often introduce more security problems than they

As for why you have to edit source code instead of just editing a config
file, there are three parts of the answer:

[1] You actually can just edit a config file. I just tell you not to do
it. You can choose to disregard that advice; the information on how to do
it is out there.

[2] The config file for UW imapd actually affects the underlying c-client
library, as opposed to just imapd. If the system is also used by other
applications that use c-client, such as Pine and Alpine, you may have
unexpected behavior.

[3] Unlike most software that has config files, UW imapd will run in a
reasonable fashion without the config file. In fact, most installations
don't have one. The problem with having your security settings depend
upon the config file in such circumstances is that if, for any reason, the
config file goes missing or is broken, it is highly likely that imapd will
continue to work just fine...but all your security settings are gone!

Anyway, answers [2] and [3] are why I tell people not to do [1]. I've
seen too many sites shoot themselves in the foot.

The lesson here for future software designers is that you can have a "zero
config setup" or you can have "configurable security settings", but you
should not attempt to have both.

-- Mark --
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

IMAP exposing /etc/passwd to iPhone?

Post by John Murta » Thu, 19 Feb 2009 20:35:55


Okay, thanks for a great explanation. We believe that was
the scenario and I assume it got its info from the passwd file on
that server since the 'folder' listing they were able to view on
the phone include account names that were on separate file systems.

We will make the change you suggested to env_unix.c and

I know we had been running imap for years and never had
this come up with other clients. It appears the iPhone defaults
to that type of access and service provides might get a scare like
we did. I thought I had read most of the install documentation.
I may have missed a mention of this config feature? Should it get
a more prominent mention?

Customer Service Software Workshop Inc.
XXXX@XXXXX.COM "software that fits!" (TM)
Toll Free (877) 635-1968(x-211)