Re: RFC: proposed fix for CVE-2018-19518 in uw-imap
Hi Salvatore, On Sun, Dec 30, 2018 at 09:38:57AM +0100, Salvatore Bonaccorso wrote: > > There is an alternative approach wich was raised by Magnus in the > respective bug: https://bugs.debian.org/914632#12 (and see followup > from Moritz). > I suppose I should have looked more carefully at the bugs associatd with CVE-2018-19518 and subscribed to this one. Thank you for pointing it out to me. The suggestion from Magnus is certainly less likely than mine to allow for a future exploit of the same mechanism via different means. Magnus, Would you prefer to handle the jessie update? If not, I will wait until you have patch ready and I can build/upload for jessie and release the corresponding advisory. Regards, -Roberto -- Roberto C. Sánchez
Re: RFC: proposed fix for CVE-2018-19518 in uw-imap
Unsubscribe me please On December 30, 2018 1:38:57 AM MST, Salvatore Bonaccorso wrote: >Hi Roberto, > >On Sat, Dec 29, 2018 at 10:24:40AM -0500, Roberto C. Sánchez wrote: >> On Sat, Dec 22, 2018 at 10:27:18PM -0500, Roberto C. Sánchez wrote: >> > [note: I am not subscribed to debian-security; please keep me or >> > debian-lts addressed on replies] >> > >> > 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. >> > >> >> Hi all, >> >> Since Tomas and Ola have reviewed the patch and we have had some >> discussion which makes it seem like this is the most sensible >approach >> to the vulnerability given the constraints, I wonder if the Security >> team could weigh in. >> >> I have forwarded my initial message and the patch to Magnus Holngren >> (the uw-imap maintainer) and also added him as a recipient of this >> message, as he may wish to be the one to upload to unstable and >> coordinate the future point release inclusion. >> >> I ask for some indication now from the security team and/or the >> maintainer since I don't think it makes sense to fix this only in >jessie >> and not in stretch/buster/sid. > >There is an alternative approach wich was raised by Magnus in the >respective bug: https://bugs.debian.org/914632#12 (and see followup >from Moritz). > >Regards, >Salvatore -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: RFC: proposed fix for CVE-2018-19518 in uw-imap
Hi Roberto, On Sat, Dec 29, 2018 at 10:24:40AM -0500, Roberto C. Sánchez wrote: > On Sat, Dec 22, 2018 at 10:27:18PM -0500, Roberto C. Sánchez wrote: > > [note: I am not subscribed to debian-security; please keep me or > > debian-lts addressed on replies] > > > > 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. > > > > Hi all, > > Since Tomas and Ola have reviewed the patch and we have had some > discussion which makes it seem like this is the most sensible approach > to the vulnerability given the constraints, I wonder if the Security > team could weigh in. > > I have forwarded my initial message and the patch to Magnus Holngren > (the uw-imap maintainer) and also added him as a recipient of this > message, as he may wish to be the one to upload to unstable and > coordinate the future point release inclusion. > > I ask for some indication now from the security team and/or the > maintainer since I don't think it makes sense to fix this only in jessie > and not in stretch/buster/sid. There is an alternative approach wich was raised by Magnus in the respective bug: https://bugs.debian.org/914632#12 (and see followup from Moritz). Regards, Salvatore
RE: RFC: proposed fix for CVE-2018-19518 in uw-imap
Unsubscribe pls -Message d'origine- De : Roberto C. Sánchez Envoyé : samedi 29 décembre 2018 16:25 À : debian-lts@lists.debian.org; debian-secur...@lists.debian.org; Debian Security Team Cc : holmg...@debian.org Objet : Re: RFC: proposed fix for CVE-2018-19518 in uw-imap On Sat, Dec 22, 2018 at 10:27:18PM -0500, Roberto C. Sánchez wrote: > [note: I am not subscribed to debian-security; please keep me or > debian-lts addressed on replies] > > 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. > Hi all, Since Tomas and Ola have reviewed the patch and we have had some discussion which makes it seem like this is the most sensible approach to the vulnerability given the constraints, I wonder if the Security team could weigh in. I have forwarded my initial message and the patch to Magnus Holngren (the uw-imap maintainer) and also added him as a recipient of this message, as he may wish to be the one to upload to unstable and coordinate the future point release inclusion. I ask for some indication now from the security team and/or the maintainer since I don't think it makes sense to fix this only in jessie and not in stretch/buster/sid. Regards, -Roberto -- Roberto C. Sánchez
Re: RFC: proposed fix for CVE-2018-19518 in uw-imap
On Sat, Dec 22, 2018 at 10:27:18PM -0500, Roberto C. Sánchez wrote: > [note: I am not subscribed to debian-security; please keep me or > debian-lts addressed on replies] > > 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. > Hi all, Since Tomas and Ola have reviewed the patch and we have had some discussion which makes it seem like this is the most sensible approach to the vulnerability given the constraints, I wonder if the Security team could weigh in. I have forwarded my initial message and the patch to Magnus Holngren (the uw-imap maintainer) and also added him as a recipient of this message, as he may wish to be the one to upload to unstable and coordinate the future point release inclusion. I ask for some indication now from the security team and/or the maintainer since I don't think it makes sense to fix this only in jessie and not in stretch/buster/sid. Regards, -Roberto -- Roberto C. Sánchez
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 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:
>
> 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
>
--
--- Inguza Technology AB --- MSc in Information Technology
/ o...@inguza.comFolkebogatan 26\
| o...@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 /
---
Re: RFC: proposed fix for CVE-2018-19518 in uw-imap
Ciao Roberto,
On 12/28/18 5:20 AM, Roberto C. Sánchez wrote:
> Hi Tomas,
>
> On Mon, Dec 24, 2018 at 08:47:55PM +, Tomas Bortoli wrote:
>>Hi Robert,
>>
>>Your patch seems not to be definitive against CVE-2018-19518.
>>This because checking for spaces won't be enough if an attacker uses some
>>"bash trick" to get a space...
>>In fact you can get a space by not typing it, with something like this:
>>
>> a=`date`;echo${a:3:1}asd
>>
>>Will print "asd".. it gets the space from a substring of "a".
>>
> I tried this along with a few different variants and none of them
> produced the vulnerability described in the CVE. I am confident that an
> actual space is required in order to exploit the vulnerability.
Yeah, it makes sense. I agree.
>
> On Tue, Dec 25, 2018 at 07:12:38PM +, Tomas Bortoli wrote:
>> Hi Roberto,
>>
>> On 12/24/18 10:40 PM, Roberto C. Sánchez wrote:
>>> There are two command templates involved in this section of code:
>>> rshcommand and sshcommand. The two for loops each operate on a
>>> different command template.
>> Ah ahn.. I missed that single byte difference, thanks.
>>
>>> Yes, the description could certainly use more detail. That said, I did
>>> include this in my original post:
>>>
>>> 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 '-'.
>>>
>>> I suppose it would be possible to apply the approach of counting tokens
>>> to the host variable to ensure that it only contains a single token.
>>> However, I do not think that is any better or worse than the approach I
>>> came up with.
>>>
>> What about "shell escaping" the host name? Not sure about escaping the
>> other parameters too..but that shouldn't harm.
>> It should be the best security practice against command injection, AFAIK.
>>
> You have lost me here. First, I am not certain what you mean by "shell
> escaping" in this context. Second, would this be something that is done
> when the configuration is read or when the rsh/ssh command is to be
> executed? Third, is the shell escaping you describe possible without
> introducing additional library dependencies?
>
> Without knowing for certain what you mean, I would think that shell
> escaping (like URL encoding/decoding, for instance) would best be
> handled by a purpose-built library. However, if there is a way to
> accomplish what you describe without such an additional component, I
> would interested to know.
>
By shell escaping I meant to escape all the special shell characters
within the input. That'd probably need additional dependencies or a neat
sanitizer function.
But I was wrong, it's unnecessary as there's no shell interpreter there
but it's just using `execv` to get rsh/ssh running.
I agree that preventing the injection of spaces will prevent the
injection of additional parameters and therefore the execution of
unexpected commands.
Br,
Tomas
Re: RFC: proposed fix for CVE-2018-19518 in uw-imap
Hi Tomas, On Fri, Dec 28, 2018 at 12:53:00PM +, Tomas Bortoli wrote: > > By shell escaping I meant to escape all the special shell characters > within the input. That'd probably need additional dependencies or a neat > sanitizer function. > > But I was wrong, it's unnecessary as there's no shell interpreter there > but it's just using `execv` to get rsh/ssh running. > > I agree that preventing the injection of spaces will prevent the > injection of additional parameters and therefore the execution of > unexpected commands. > Thanks for the feedback and confirmation. Regards, -Roberto -- Roberto C. Sánchez
Re: RFC: proposed fix for CVE-2018-19518 in uw-imap
Hi Tomas,
On Mon, Dec 24, 2018 at 08:47:55PM +, Tomas Bortoli wrote:
>Hi Robert,
>
>Your patch seems not to be definitive against CVE-2018-19518.
>This because checking for spaces won't be enough if an attacker uses some
>"bash trick" to get a space...
>In fact you can get a space by not typing it, with something like this:
>
> a=`date`;echo${a:3:1}asd
>
>Will print "asd".. it gets the space from a substring of "a".
>
I tried this along with a few different variants and none of them
produced the vulnerability described in the CVE. I am confident that an
actual space is required in order to exploit the vulnerability.
On Tue, Dec 25, 2018 at 07:12:38PM +, Tomas Bortoli wrote:
> Hi Roberto,
>
> On 12/24/18 10:40 PM, Roberto C. Sánchez wrote:
> > There are two command templates involved in this section of code:
> > rshcommand and sshcommand. The two for loops each operate on a
> > different command template.
>
> Ah ahn.. I missed that single byte difference, thanks.
>
> > Yes, the description could certainly use more detail. That said, I did
> > include this in my original post:
> >
> > 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 '-'.
> >
> > I suppose it would be possible to apply the approach of counting tokens
> > to the host variable to ensure that it only contains a single token.
> > However, I do not think that is any better or worse than the approach I
> > came up with.
> >
>
> What about "shell escaping" the host name? Not sure about escaping the
> other parameters too..but that shouldn't harm.
> It should be the best security practice against command injection, AFAIK.
>
You have lost me here. First, I am not certain what you mean by "shell
escaping" in this context. Second, would this be something that is done
when the configuration is read or when the rsh/ssh command is to be
executed? Third, is the shell escaping you describe possible without
introducing additional library dependencies?
Without knowing for certain what you mean, I would think that shell
escaping (like URL encoding/decoding, for instance) would best be
handled by a purpose-built library. However, if there is a way to
accomplish what you describe without such an additional component, I
would interested to know.
Regards,
-Roberto
--
Roberto C. Sánchez
Re: RFC: proposed fix for CVE-2018-19518 in uw-imap
Hi Roberto, On 12/24/18 10:40 PM, Roberto C. Sánchez wrote: > There are two command templates involved in this section of code: > rshcommand and sshcommand. The two for loops each operate on a > different command template. Ah ahn.. I missed that single byte difference, thanks. > Yes, the description could certainly use more detail. That said, I did > include this in my original post: > > 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 '-'. > > I suppose it would be possible to apply the approach of counting tokens > to the host variable to ensure that it only contains a single token. > However, I do not think that is any better or worse than the approach I > came up with. > What about "shell escaping" the host name? Not sure about escaping the other parameters too..but that shouldn't harm. It should be the best security practice against command injection, AFAIK. Happy Christmas, Tomas
Re: RFC: proposed fix for CVE-2018-19518 in uw-imap
Hi Robert,
Your patch seems not to be definitive against CVE-2018-19518.
This because checking for spaces won't be enough if an attacker uses some "bash
trick" to get a space...
In fact you can get a space by not typing it, with something like this:
a=`date`;echo${a:3:1}asd
Will print "asd".. it gets the space from a substring of "a".
Regarding the code, there is a bit of redundancy as the "for" in the if-else is
repeated in both branches, it could be therefore placed after the if-else and
achieve the same semantic result without redundancy.
About the bug, as far as I understand the injection is, eventually, possible in
the server name...shouldn't that be the "host" variable in the patch? [1]
I am not sure...CVE description is quite smallish..
[1] http://cve.circl.lu/cve/CVE-2018-19518
Best regards,
Tomas
On 12/23/18 4:27 AM, Roberto C. Sánchez 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:
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
Re: RFC: proposed fix for CVE-2018-19518 in uw-imap
Hi Tomas,
Thanks for the feedback.
On Mon, Dec 24, 2018 at 08:47:55PM +, Tomas Bortoli wrote:
>Hi Robert,
>
>Your patch seems not to be definitive against CVE-2018-19518.
>This because checking for spaces won't be enough if an attacker uses some
>"bash trick" to get a space...
>In fact you can get a space by not typing it, with something like this:
>
> a=`date`;echo${a:3:1}asd
>
>Will print "asd".. it gets the space from a substring of "a".
>
I tried numerous different such tricks and every one that I tried
between 'x' and '-o' in the host specification resulted in the
vulnerability not manifesting itself.
That said, I did not try this specific trick and I will investigte to
determine if it results in the vulnerability manifesting itself.
>Regarding the code, there is a bit of redundancy as the "for" in the
>if-else is repeated in both branches, it could be therefore placed after
>the if-else and achieve the same semantic result without redundancy.
>
There are two command templates involved in this section of code:
rshcommand and sshcommand. The two for loops each operate on a
different command template.
>About the bug, as far as I understand the injection is, eventually,
>possible in the server name...shouldn't that be the "host" variable in the
>patch? [1]
>I am not sure...CVE description is quite smallish..
>
Yes, the description could certainly use more detail. That said, I did
include this in my original post:
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 '-'.
I suppose it would be possible to apply the approach of counting tokens
to the host variable to ensure that it only contains a single token.
However, I do not think that is any better or worse than the approach I
came up with.
Regards,
-Roberto
--
Roberto C. Sánchez
