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

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Roberto C. Sánchez-2
[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

91_CVE-2018-19518.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Tomas Bortoli
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


Reply | Threaded
Open this post in threaded view
|

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

Roberto C. Sánchez-2
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

Reply | Threaded
Open this post in threaded view
|

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

Tomas Bortoli
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



Reply | Threaded
Open this post in threaded view
|

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

Roberto C. Sánchez-2
In reply to this post by Tomas Bortoli
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

Reply | Threaded
Open this post in threaded view
|

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

Tomas Bortoli
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



Reply | Threaded
Open this post in threaded view
|

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

Roberto C. Sánchez-2
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

Reply | Threaded
Open this post in threaded view
|

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

Ola Lundqvist-3
In reply to this post by Roberto C. Sánchez-2
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 <[hidden email]> 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 ----
/  [hidden email]                    Folkebogatan 26            \
|  [hidden email]                   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 | Threaded
Open this post in threaded view
|

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

Roberto C. Sánchez-2
In reply to this post by Roberto C. Sánchez-2
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

Reply | Threaded
Open this post in threaded view
|

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

COSTEY Anthony
Unsubscribe

pls

-----Message d'origine-----
De : Roberto C. Sánchez <[hidden email]>
Envoyé : samedi 29 décembre 2018 16:25
À : [hidden email]; [hidden email]; Debian Security Team <[hidden email]>
Cc : [hidden email]
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

Reply | Threaded
Open this post in threaded view
|

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

Salvatore Bonaccorso-4
In reply to this post by Roberto C. Sánchez-2
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

Reply | Threaded
Open this post in threaded view
|

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

Shelby Cruver
Unsubscribe me please

On December 30, 2018 1:38:57 AM MST, Salvatore Bonaccorso <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

Magnus Holmgren-4
In reply to this post by Salvatore Bonaccorso-4
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        [hidden email]
Debian Developer

CVE-2018-19518.debdiff (1K) Download Attachment
signature.asc (849 bytes) Download Attachment