Re: Bug#851612: CVE-2017-0381
On Sun, Jan 29, 2017 at 04:39:59PM +0100, Salvatore Bonaccorso wrote:
> On Tue, Jan 17, 2017 at 01:25:27AM -0500, Jean-Marc Valin wrote:
> > Hi,
> >
> > CVE-2017-0381 states that:
> > "A remote code execution vulnerability in silk/NLSF_stabilize.c in
> > libopus in Mediaserver could enable an attacker using a specially
> > crafted file to cause memory corruption during media file and data
> > processing."
> >
> > Now I'm not sure who did the analysis of this bug, but the analysis we
> > did concluded that the very worst that could happen was a slightly out
> > of bounds *read* 256 bytes before a constant table. What this means in
> > practice is that the value is read from another table and the decoded
> > data audio will sound bad (which was already going to happen if you're
> > decoding garbage data).
> >
> > The worst case that could happen is a plain crash. This would happen if
> > the code is compiled with assertions (the code would assert before
> > making the read), or -- if you're really unlucky -- if the table is
> > placed just after some unreadable memory.
> >
> > So while the bug definitely needed to be fixed -- and was fixed back in
> > July -- we don't consider it to be a severe security issue. If you
> > disagree with our analysis, could you point out what we missed?
>
> Apologies for the long delay, Jean-Marc. Thanks a lot for your
> analysis.
>
> Ron, would it be possible that you fix that issue via an upcoming
> point release for jessie? It would not warrant a DSA on it's own.
We could cherry pick that patch back into 1.1 that's in Jessie, but
unless someone does find a more serious hole in the upstream analysis,
the interesting question would be what do we actually want to achieve
with a point release update?
After we decided to tag 1.2-alpha2 as the best candidate for Stretch,
Jean-Marc also applied this to the 1.1 branch, now tagged as 1.1.4,
for people who did want the fix, but didn't want to jump to the 1.2
changes yet - since there was some amount of hysteria growing attached
to it based on the original CVE claims.
Between 1.1 and 1.1.4 there have actually been a number of patches
to fix things of approximately this severity (this code is continually
being fuzzed and subjected to new analysis, and that does shake out
new corner cases with numeric precision and the like from time to time).
So if we're going to update Jessie because this is "severe enough" to
warrant that (but not so serious to do as a DSA), it would seem a bit
silly to not pull in all of the fixes in that category, or to prioritise
them purely on "how much publicity someone else gave them".
The downside of that is the diff between 1.1 and 1.1.4 isn't something
I expect the SRMs will find a delight to review. And cherry picking
all of them individually will probably be a significant amount of
error prone work, that personally I'd have a lot less faith in not
introducing an accidental regression. I don't yet know how many of
them are significantly linked to prior patches in the series.
This patch is the only diff between 1.1.3 and 1.1.4, and 1.1.3 spent
a few months in Stretch without incident before this update.
In "normal use", most people are unlikely to hit any of these issues,
but if we want a stable update where we can honestly say "fixes all
known corner cases where corrupt or maliciously crafted input can do
Something Bad", we probably do want to consider pulling in significantly
more of 1.1.4 than just this patch. And if we want what we pull in to
have been tested, then pulling in 1.1.4 verbatim would be the safest bet
by a fair margin.
If there's a real regression to that, it would be an upstream bug and
there'll be a 1.1.5 to fix it as soon as it's known ... This is now
a 'serious' bugfix only branch. New work is all for 1.2.
I've CC'd -release, to see what they'd prefer we do for Jessie.
It might be that the best option here is to just put something later
in -bpo, and if people are paranoid, they can choose to use that?
Cheers,
Ron
Reply to: