Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #5504 > unrolled thread

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

Back to article view | Back to linux.debian.security

Contents

  RFC: proposed fix for CVE-2018-19518 in uw-imap Roberto C. Sánchez <roberto@debian.org> - 2018-12-23 04:30 +0100
    Re: RFC: proposed fix for CVE-2018-19518 in uw-imap Roberto C. Sánchez <roberto@debian.org> - 2018-12-24 22:50 +0100
      Re: RFC: proposed fix for CVE-2018-19518 in uw-imap Tomas Bortoli <tomasbortoli@hotmail.it> - 2018-12-26 09:50 +0100
    Re: RFC: proposed fix for CVE-2018-19518 in uw-imap Tomas Bortoli <tomasbortoli@hotmail.it> - 2018-12-25 12:30 +0100
      Re: RFC: proposed fix for CVE-2018-19518 in uw-imap Roberto C. Sánchez <roberto@debian.org> - 2018-12-28 05:30 +0100
        Re: RFC: proposed fix for CVE-2018-19518 in uw-imap Roberto C. Sánchez <roberto@debian.org> - 2018-12-28 15:30 +0100
        Re: RFC: proposed fix for CVE-2018-19518 in uw-imap Tomas Bortoli <tomasbortoli@hotmail.it> - 2018-12-28 19:30 +0100
    Re: RFC: proposed fix for CVE-2018-19518 in uw-imap Ola Lundqvist <ola@inguza.com> - 2018-12-28 21:50 +0100
    Re: RFC: proposed fix for CVE-2018-19518 in uw-imap Roberto C. Sánchez <roberto@debian.org> - 2018-12-29 16:30 +0100
      RE: RFC: proposed fix for CVE-2018-19518 in uw-imap COSTEY Anthony <a.costey@caenlamer.fr> - 2018-12-29 17:10 +0100
      Re: RFC: proposed fix for CVE-2018-19518 in uw-imap Salvatore Bonaccorso <carnil@debian.org> - 2018-12-30 09:40 +0100
        Bug#914632: RFC: proposed fix for CVE-2018-19518 in uw-imap Magnus Holmgren <holmgren@debian.org> - 2019-02-24 20:40 +0100

#5504 — RFC: proposed fix for CVE-2018-19518 in uw-imap

[Multipart message — attachments visible in raw view] — view raw

[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

[toc] | [next] | [standalone]

#5506

Hi Tomas,

Thanks for the feedback.

On Mon, Dec 24, 2018 at 08:47:55PM +0000, 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

[toc] | [prev] | [next] | [standalone]

#5510

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

[toc] | [prev] | [next] | [standalone]

#5507

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#5517

Hi Tomas,

On Mon, Dec 24, 2018 at 08:47:55PM +0000, 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 +0000, 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

[toc] | [prev] | [next] | [standalone]

#5518

Hi Tomas,

On Fri, Dec 28, 2018 at 12:53:00PM +0000, 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

[toc] | [prev] | [next] | [standalone]

#5519

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 +0000, 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 +0000, 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

[toc] | [prev] | [next] | [standalone]

#5520

[Multipart message — attachments visible in raw view] — view raw

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:
>
> 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 ----
/  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  /
 ---------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#5521

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

[toc] | [prev] | [next] | [standalone]

#5522

Unsubscribe

pls

-----Message d'origine-----
De : Roberto C. Sánchez <roberto@debian.org> 
Envoyé : samedi 29 décembre 2018 16:25
À : debian-lts@lists.debian.org; debian-security@lists.debian.org; Debian Security Team <team@security.debian.org>
Cc : holmgren@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

[toc] | [prev] | [next] | [standalone]

#5523

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

[toc] | [prev] | [next] | [standalone]

#5559 — Bug#914632: RFC: proposed fix for CVE-2018-19518 in uw-imap

[Multipart message — attachments visible in raw view] — view raw

söndag 30 december 2018 kl. 09:38:57 CET skrev  Salvatore Bonaccorso:
> 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).

So, is it OK to upload this (assuming there's no code out there that actually 
uses SET_RSHPATH or SET_SSHPATH)?

(By no longer defining RSHPATH, rshpath doesn't get set by the following code 
and tcp_aopen() will return NIL without doing anything.

#ifdef RSHPATH			/* rsh path defined yet? */
  if (!rshpath) rshpath = cpystr (RSHPATH);
#endif

)

-- 
Magnus Holmgren        holmgren@debian.org
Debian Developer 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web