Re: Wheezy update of ncurses?
On 2017-07-20 22:32 +0200, Emilio Pozuelo Monfort wrote:
> On 11/07/17 20:58, Sven Joachim wrote:
>> On 2017-07-11 10:17 -0400, Roberto C. Sánchez wrote:
>>> On Sun, Jul 09, 2017 at 03:14:33PM +0100, Chris Lamb wrote:
>>>> The Debian LTS team would like to fix the security issues which are
>>>> currently open in the Wheezy version of ncurses:
>>> All the open ncurses issues are marked no-dsa for jessie and stretch.
>>> Should we do the same for wheezy?
>> That would be logical. The bugs only affect the tic program and the tic
>> library which is used by about three programs in the world (tic, infocmp
>> and tack), and most of our users never run any of these programs.
>> Anyway, I have attempted to backport the patches I sent to the release
>> team (bugs #867814 and #867817). The changes to the library applied
>> cleanly, but I had to edit progs/dump_entry.c by hand since two hunks
>> failed to apply there. If anybody wants to upload a fixed package to
>> wheezy (I won't), please review carefully.
> Thanks. I have taken a look at this. I have noticed the regression you mentioned
> on the pu bugs, and so I have tried to backport the termcap-fix.diff.
> Unfortunately most hunks fail to apply, and applying it manually I noticed the
> code has changed quite a bit, and as I don't know the code well, I'm worried we
> may not fix the regression properly or we may cause other issues.
You are not the only one, I have struggled with this code myself for the
Jessie upload, in vain so far :-(. The problem is that the regression
fix relies on additions made in the 20161001 and 20161113 patchlevels,
and those are pretty large.
My hope is that a fix might come from Opensuse whose users are already
suffering from the regression.
> I wanted to get this fixed as it will be fixed in stretch and jessie, and we
> don't have a wheezy-proposed-updates suite, and given the comments from the
> reporter about one bug leading to arbitrary code execution.
Upstream mentioned that the stack protection would probably prevent such
an exploit, but I am not a security expert. Attackers would also
have to trick a victim into running an affected program on their input
files, not exactly the most profitable social engineering compared to
sending them (say) a crafted Word or PDF document.
> But given the risk of not fixing this properly, the few users of the
> library, the disputed severity of that bug, and that this was tagged
> no-dsa in the first place, I'm tempted to do that for wheezy too and
> move on.
Looks reasonable to me.