Bug#760385: Fix for CVE-2014-5256

[Thomas Viehmann]

Hi Jean Baptiste,

thank you for looking into this.
Note that the changelog entries for nodejs 0.10.31 and .32 include
v8: backport CVE-2013-6668
v8: fix a crash introduced by previous release
If libv8 in Debian is affected by those, you might also consider also
backporting those fixes when preparing a new v8 package.

(Elsewhere in NodeJS .33 there is "crypto: Disable autonegotiation for
SSLv2/3 by default", not sure whether the release team would let
something like that through.)

Best regards

Thomas

[Jean Baptiste Favre]

Hello Thomas,
Thanks for your update.

I decided to have a look on this bug because it seemed quite easy to fix
it: upstream patch was available and small anough for me.
Unfortunatly, I'm sure I'll be able to deal with lib8-3.14. The more I
dig into, the less I understand (more or less) :)

I'll try anyway,
Regards,
Jean Baptiste

Post by Thomas Viehmann
Hi Jean Baptiste,
thank you for looking into this.
Note that the changelog entries for nodejs 0.10.31 and .32 include
v8: backport CVE-2013-6668
v8: fix a crash introduced by previous release
If libv8 in Debian is affected by those, you might also consider also
backporting those fixes when preparing a new v8 package.
(Elsewhere in NodeJS .33 there is "crypto: Disable autonegotiation for
SSLv2/3 by default", not sure whether the release team would let
something like that through.)
Best regards
Thomas

[Michael Gilbert]

Hi Mike,
On Fri, 19 Dec 2014 21:11:10 -0500 Michael Gilbert

control: severity -1 important
There is no security support for libv8 in jessie, so security issues aren't RC.

Could you please add some links to explain that?
I was about to fix this issue in an NMU after double-checking the fix.

Severity doesn't say anything about whether or not a bugs can be
fixed, so you can still do that. Anyway it was decided recently on
the security team ml.

Best wishes,
Mike

[Jonas Smedegaard]

[sent again, cc correct list address this time]

Quoting Michael Gilbert (2014-12-20 11:06:47)

Post by Michael Gilbert

control: severity -1 important
There is no security support for libv8 in jessie, so security issues aren't RC.

Could you please add some links to explain that?
I was about to fix this issue in an NMU after double-checking the fix.

Severity doesn't say anything about whether or not a bugs can be
fixed, so you can still do that. Anyway it was decided recently on
the security team ml.

I find it sensible for the security team to give up on maintaining some
packages - and I find it great to try communicate that to our users by
use of the debian-security-support package.

Just now I learned from above bugreport that the security team also
actively *lower* bugreports to avoid them being treated as release
candidate, for packages not maintained by the security team. That I
find a horrible approach: Severity of a bug is independent on whether it
will be fixed or not. The more proper tag to use is *-ignore, IMO.

Please let us not hide problems!


- Jonas

[Adam D. Barratt]

Post by Jonas Smedegaard
[sent again, cc correct list address this time]
Quoting Michael Gilbert (2014-12-20 11:06:47)

Post by Michael Gilbert

control: severity -1 important
There is no security support for libv8 in jessie, so security issues aren't RC.

Could you please add some links to explain that?
I was about to fix this issue in an NMU after double-checking the fix.

Severity doesn't say anything about whether or not a bugs can be
fixed, so you can still do that. Anyway it was decided recently on
the security team ml.

I'm not aware of it having been decided that the security team were the
arbiters of release criticality in such situations.

Post by Jonas Smedegaard
I find it sensible for the security team to give up on maintaining some
packages - and I find it great to try communicate that to our users by
use of the debian-security-support package.
Just now I learned from above bugreport that the security team also
actively *lower* bugreports to avoid them being treated as release
candidate, for packages not maintained by the security team. That I
find a horrible approach: Severity of a bug is independent on whether it
will be fixed or not. The more proper tag to use is *-ignore, IMO.

The setting of -ignore by people other the Release Team (or those who
have previously discussed doing so, e.g. for certain classes of bug in
stable) is still wrong.

Regards,

Adam

[Michael Gilbert]

Post by Adam D. Barratt

Post by Jonas Smedegaard
[sent again, cc correct list address this time]
Quoting Michael Gilbert (2014-12-20 11:06:47)

Post by Michael Gilbert

control: severity -1 important
There is no security support for libv8 in jessie, so security issues aren't RC.

Could you please add some links to explain that?
I was about to fix this issue in an NMU after double-checking the fix.

Severity doesn't say anything about whether or not a bugs can be
fixed, so you can still do that. Anyway it was decided recently on
the security team ml.

I'm not aware of it having been decided that the security team were the
arbiters of release criticality in such situations.

The severity was bumped to grave by Moritz about a month ago, likely
to get the libv8 maintainers to actually pay attention to their vast
volume of unaddressed security issues.

Now that it's been decided that libv8 won't get security support in
jessie, it seems perfectly reasonable to move back to the original
severity, which is important.

Post by Adam D. Barratt

Post by Jonas Smedegaard
I find it sensible for the security team to give up on maintaining some
packages - and I find it great to try communicate that to our users by
use of the debian-security-support package.
Just now I learned from above bugreport that the security team also
actively *lower* bugreports to avoid them being treated as release
candidate, for packages not maintained by the security team. That I
find a horrible approach: Severity of a bug is independent on whether it
will be fixed or not. The more proper tag to use is *-ignore, IMO.

The release team will still consider important bug fixes, you just
need to ask for
a pre-unblock.

Best wishes,
Mike

[Bálint Réczey]

Control: severity -1 grave

Hi Mike,

Post by Michael Gilbert

Post by Adam D. Barratt

Post by Jonas Smedegaard
[sent again, cc correct list address this time]
Quoting Michael Gilbert (2014-12-20 11:06:47)

Post by Michael Gilbert

control: severity -1 important
There is no security support for libv8 in jessie, so security issues aren't RC.

Could you please add some links to explain that?
I was about to fix this issue in an NMU after double-checking the fix.

Severity doesn't say anything about whether or not a bugs can be
fixed, so you can still do that. Anyway it was decided recently on
the security team ml.

I'm not aware of it having been decided that the security team were the
arbiters of release criticality in such situations.

The severity was bumped to grave by Moritz about a month ago, likely
to get the libv8 maintainers to actually pay attention to their vast
volume of unaddressed security issues.
Now that it's been decided that libv8 won't get security support in
jessie, it seems perfectly reasonable to move back to the original
severity, which is important.

The proper severity of this bug is grave as set by Moritz IMO. I'm
restoring it wearing my maintainer hat.
I have also checked if the fix changed the ABI using objdump (did not
change it) and uploaded a fixed version to DELAYED/2.
The fix can be found in the usual packaging repository.

Cheers,
Balint

[Bálint Réczey]

Hi Mike,

First, I had to cancel the upload because of too strict reverse
dependencies. Dear fellow JavaScript maintainers please figure out a
less strict dependency graph because every otherwise fully compatible
libv8 update would break several packages.

Post by Bálint Réczey
The proper severity of this bug is grave as set by Moritz IMO. I'm
restoring it wearing my maintainer hat.

It's not really constructive arguing over severity, so that's fine.

I appreciate the work done by the Security Team but to work together
we have to know what actions can be taken by the Security Team.
Increasing severity of bugs is business as usual and perfectly
reasonable, but _decreasing_ the severity _based on the availability
of security support_ was crossing a line IMO. It seems the line was
there based on Jonas' and Adam's email.
To clarify my position the Security Team can and is expected to
decrease the severity in case a security bug's impact turns out to be
less than originally expected but in this particular case this rule
does not seem to be applicable.

You've saved yourself from needing to write an unblock request.
The problem still remains that the backlog of libv8 security issues
never get fixed (except for a new upstream every now and then), so
https://security-tracker.debian.org/tracker/source-package/libv8
https://security-tracker.debian.org/tracker/source-package/libv8-3.14

If there were bugs opened for those CVE-s those should have been
opened with grave severity, too.

Note that unimportant there indicates lack of security support for the package.

This is confusing. Please don't mark them as unimportant because in
this context unimportant is defined differently.

https://security-tracker.debian.org/tracker/status/unimportant :
"This page lists packages that are affected by issues that are
considered unimportant from a security perspective. These issues are
thought to be unexploitable or uneffective in most situations (for
example, browser denial-of-services)."

If there is interest in security support for libv8, that is a good
thing, but a lot more needs to be done for that to be true.

Well, there is a long way to go, I agree.

Thank you for helping the Security Team and keeping the bugs and CVE-s updated.

Cheers,
Balint

[Michael Gilbert]

Post by Bálint Réczey

The problem still remains that the backlog of libv8 security issues
never get fixed (except for a new upstream every now and then), so
https://security-tracker.debian.org/tracker/source-package/libv8
https://security-tracker.debian.org/tracker/source-package/libv8-3.14

If there were bugs opened for those CVE-s those should have been
opened with grave severity, too.

Here you go:
http://bugs.debian.org/773671

Good luck!

Best wishes,
Mike

[Balint Reczey]

Hi Mike,

Post by Michael Gilbert

Hi Mike,
On Fri, 19 Dec 2014 21:11:10 -0500 Michael Gilbert

control: severity -1 important
There is no security support for libv8 in jessie, so security issues aren't RC.

Could you please add some links to explain that?
I was about to fix this issue in an NMU after double-checking the fix.

Severity doesn't say anything about whether or not a bugs can be
fixed, so you can still do that. Anyway it was decided recently on

I beg to disagree here. According to freeze policy [1] only targeted
fixes for RC bugs are considered to be accepted without pre-approval to
testing now. Fixes to unstable which won't be accepted to testing are
also discouraged during the freeze.
Those implies that decreasing the severity _does_ affect if a bug should
be fixed.

Please restore the severity of this bug since it is about security flaw
and let the Release Team decide if they want to see a vulnerable libv8
in Jessie.

BTW the fix seems to be trivial and since I'm in the JavaScript team I
can actually fix it in a normal maintainer upload.

Post by Michael Gilbert
the security team ml.

Please provide a link to a public resource to let others understand the
reasoning.

Thanks,
Balint

[1] https://release.debian.org/jessie/freeze_policy.html

[Jonas Smedegaard]

Quoting Michael Gilbert (2014-12-20 03:11:10)

control: severity -1 important
There is no security support for libv8 in jessie, so security issues aren't RC.

Lack of support do not change severity. Seems more appropriate to then
tag as *-ignore instead.

- Jonas