[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:
https://people.debian.org/~roberto/alpine_2.20+dfsg1-7~0.dsc
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
useful.
Regards,
-Roberto
--
Roberto C. Sánchez