Array index error in the insertItemBefore method in WebKit, as used
in Safari before 3.2.3 and 4 Public Beta, Google Chrome Stable before
126.96.36.199, and possibly other products allows remote attackers to
execute arbitrary code via a document with a SVGPathList data
structure containing a negative index in the (1) SVGTransformList,
(2) SVGStringList, (3) SVGNumberList, (4) SVGPathSegList, (5)
SVGPointList, or (6) SVGLengthList SVGList object, which triggers
The reproducer crashes with 0_p42162, but not with 1.1.7.
var p = document.createElementNS("http://www.w3.org/2000/svg","path");
What do we do here? 1.1.7 has been in portage for barely a week, and the older snapshots are far too old for backporting the fix.
If it doesn't break API against the existing stable, let's stable 1.1.7.
Please go ahead. Arch teams should be able to make sure the webkit-gtk using packages on their architecture continue to work. I believe there was an ABI version bump (soname from .so.1 to .so.2 or some such) between latest stable and 1.1.7, btw, but maybe that was with 1.1.8, not sure.
Sorry, it occurred to me that webkit-gtk-1.1.7 and later currently have a >=gnome-keyring-2.26 dependency with USE=gnome-keyring, and that is not ready for stabilization. I'll need to think what to do, maybe we can make a revision without gnome-keyring USE flag (it currently provides http authentication support), as earlier versions didn't have that feature either. Or maybe to lower the dependency requirement to 2.22 if possible - the requirement when introduced was told to be because only since 2.26 gnome-keyring headers are possible to include from C++ (extern "C" namespacing), but we could patch earlier versions too if that's the only need for so new keyring.
I'll personally have to sleep now, I hope to do something about it after I wake up and have some coffee (poke on IRC please).
Alright, I checked with upstream webkit-gtk currently uses gnome-keyring only for http basic auth, and this feature wasn't present in the old snapshot so it can be disabled in 1.1.7 with glee.
Doing so now, you can gleefully continue with your security-thingies soon after.
Alright, I was too optimistic. Libsoup-2.26 is also needed, which will pull in libproxy, and hence a ton of other deps. Stabling webkit-gtk-1.1.7 is NOT an option unless we're willing to wait for gnome-2.26 to go stable too.
So the options we have are:
1. Try to backport the fix(es) for the bug to the last stable version (sounds like a job for... the security team!)
2. Drop webkit support from gimp-2.6.4 (the only stable version depending on webkit). Gimp only uses webkit for it's documentation browser.
(In reply to comment #8)
> 1. Try to backport the fix(es) for the bug to the last stable version (sounds
> like a job for... the security team!)
I think this is the more desirable option, however it means we need to get access to patch information from upstream. We are in contact with Apple, let's hope this progresses as planned.
> 2. Drop webkit support from gimp-2.6.4 (the only stable version depending on
> webkit). Gimp only uses webkit for it's documentation browser.
This would mean to drop stable on WebKit. Let's give this bug some more time and hope for (1).
Created attachment 195867 [details, diff]
Backported patch. With that applied, the reproducer does no longer crash.
Patch added in webkit-gtk-0_p40220-r1
Arches, please proceed with stabilisation
Stable on alpha.
amd64/x86 stable, all arches done.
<net-libs/webkit-gtk-1.1.7 is no longer in portage.
GLSA with 287494.
Not sure if has much sense to continue with this (affected versions were fixed and removed so much time ago :/). Well, I guess it will depend on security team policy
Fixed in 1.1.10 that was fixed in bug 271865