[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: proposed fix for CVE-2018-19518 in uw-imap

Hi Roberto

I have checked your patch and the described problem and I think it looks good. As I understand the reason why you count the number of tokens instead of checking for a space in the hostname is that is easier to do that way as you do not need to make an advanced parse mechanism.

To my knowledge a hostname is almost any string that do not contain a white-space. There are some exceptions but they are very few, but space is not allowed in a hostname, so I think your patch is good.

Best regards

// Ola 

On Sun, 23 Dec 2018 at 04:27, Roberto C. Sánchez <roberto@debian.org> wrote:
[note: I am not subscribed to debian-security; please keep me or
debian-lts addressed on replies]

Hello all,

I have been working on trying to reproduce CVE-2018-19518 in uw-imap.  I
had already prepared PHP updates for jessie and wheezy to address that
aspect of the vulnerability, though neither of those required an
understanding of the underlying issue since the PHP team went the route
of disabling rsh/ssh functionality in uw-imap.

As it happens, alpine embeds the uw-imap code and that happened to serve
as a useful testbed for reproducing the vulnerability, understading the
underlying issue, and then developing/testing a fix.  I would appreciate
comments on my analysis and proposed patch.

To start, I downloaded the source for alpine 2.20+dfsg1-7 in stretch.  I
then tried to reproduce CVE-2018-19518 using a variety of the approaches
which were described on the web (especially the metasploit example from
Exploit DB).  However, as best I can tell all of the examples are
focused on the PHP route and none of them worked when specified in a
~/.pinerc file.  So, I simplified and settled on this simple
configuration directive in ~/.pinerc:

inbox-path={x -oProxyCommand=`date>ohai`}inbox

After placing that directive in ~/.pinerc and launching alpine I ended
up with a file ('ohai') in the current working directory with the
current system date/time.  That was enough, I thought, to consider that
I had something which resembled the reported vulnerability.

After I had that, I began to consider the nature of the problem more
deeply.  In particular, I wondered whether it was possible to answer the
question, "is this is a valid host name?"  I also wondered whether it
was possible to cause the vulnerability without a space in the hostname
(somewhat related to the first question).  In any event, I concluded
that the question of whether something is a valid hostname might be a
bit complex to tackle and despite numerous attempts I was not able to
exploit the vulnerability without the space between the host name and
the command switch '-'.

It did not seem sensible to consider attempting to detect the
ProxyCommand options since that seems like it would leave the door open
for other related vulnerabilities.  For example, might there be an as
yet unexplored opening with LocalCommand or ProxyJump?

After digging into the code in uw-imap that parses the configuration
file value into the rsh or ssh command line (the tcp_aopen function in
tcp_unix.c), and further considering the necessity of the space to
making the exploit work, I decided that checking to ensure that the
parsed command line has the same number of tokens as the command
template string would be enough to tell me that there was an attempt at
a command injection.

Based on that, I came up with the attached patch.  If anyone wishes to
try this out, all that is needed is to install the stretch version of
alpine and create ~/.pinerc to contain the above directive.  I have also
built and uploaded a version that contains my candidate fix here:


If this seems like a sensible approach, I propose to apply the attached
patch to uw-imap 8:2007f~dfsg-5 (the current stretch/buster/sid version)
to create version 8:2007f~dfsg-6 for upload to sid and eventual
inclusion in stretch (perhaps via a point release) and then also in
parallel create a 8:2007f~dfsg-4+deb8u1 package for upload to jessie.

Please reply with your comments.  In particular, feedback from the
security team on the appropriateness of this for a stable point release
and my suggested route for the update to take to get there would be very



Roberto C. Sánchez

 --- Inguza Technology AB --- MSc in Information Technology ----
/  ola@inguza.com                    Folkebogatan 26            \
|  opal@debian.org                   654 68 KARLSTAD            |
|  http://inguza.com/                Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /

Reply to: