Bug 8673 - Security issues for iceape fixed in version 2.15
Summary: Security issues for iceape fixed in version 2.15
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 2
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL: http://www.mozilla.org/security/known...
Whiteboard: MGA2-64-OK mga2-32-OK
Keywords: validated_update
Depends on:
Reported: 2013-01-12 17:37 CET by Christiaan Welvaart
Modified: 2013-01-14 22:40 CET (History)
4 users (show)

See Also:
Source RPM: iceape-2.14.1-1.mga2.src.rpm
Status comment:


Description Christiaan Welvaart 2013-01-12 17:37:17 CET
Description of problem:

Several critical security vulnerabilities have been found in seamonkey
2.14.x which is the upstream of iceape 2.14.1. They have been fixed in version

This update also fixes the problem of opus HTML5 audio not playing. It was caused by enabling gstreamer for h.264 playback which also took over ogg playing, including opus. The update switches back to the mozilla ogg player and following basic security policy it uses packaged ogg, vorbis, theora, and opus libraries instead of the versions bundled with mozilla source code. Since opus was not available at the time when Mageia 2 was released it needs to be added. I do not expect any real problems for a new package even if it is a library. It may also be used by firefox 17esr.

Updated packages are ready for testing.

Source RPMs:

Binary RPMs for mga2:

Proposed Advisory:

Updated iceape packages fix security issues:

Nemory safety problems and crashes that affect Firefox ESR 10, Firefox ESR 17, and Firefox 17. (CVE-2013-0769, MFSA 2013-01)

Nemory safety problems and crashes that affect Firefox ESR 17 and Firefox 17. (CVE-2013-0749, MFSA 2013-01)

Nmemory safety problems and crashes that affect Firefox 17. (CVE-2013-0770, MFSA 2013-01)

Global-buffer-overflow in CharDistributionAnalysis::HandleOneChar. (CVE-2013-0760, MFSA 2013-02)

Heap-use-after-free in imgRequest::OnStopFrame. (CVE-2013-0762, MFSA 2013-02)

Heap-use-after-free in ~nsHTMLEditRules. (CVE-2013-0766, MFSA 2013-02)

Out of bounds read in nsSVGPathElement::GetPathLengthScale. (CVE-2013-0767, MFSA 2013-02)

Heap-use-after-free in mozilla::TrackUnionStream::EndTrack. (CVE-2013-0761, MFSA 2013-02)

Heap-use-after-free in Mesa, triggerable by resizing a WebGL canvas. (CVE-2013-0763, MFSA 2013-02)

Heap-buffer-overflow in gfxTextRun::ShrinkToLigatureBoundaries. (CVE-2013-0771, MFSA 2013-02)

Heap-based buffer overflow in the nsWindow::OnExposeEvent function in Mozilla Firefox before 17.0, Firefox ESR 10.x before 10.0.11, Thunderbird before 17.0, Thunderbird ESR 10.x before 10.0.11, and SeaMonkey before 2.14 allows remote attackers to execute arbitrary code via unspecified vectors. (CVE-2012-5829)

Stack buffer overflow with canvas. (CVE-2013-0768, MFSA 2013-03)

URL spoofing with credentials info of URL & 204. (CVE-2013-0759, MFSA 2013-04)

Heap-use-after-free in TableBackgroundPainter::TableBackgroundData::Destroy. (CVE-2013-0744, MFSA 2013-05)

Touch events are shared across iframes (CVE-2013-0751, MFSA 2013-06)

Crash [@ nsSOCKSSocketInfo::ConnectToProxy(PRFileDesc*) ] clicking "Download the rest of the message" (CVE-2013-0764, MFSA 2013-07)

The AutoWrapperChanger class fails to keep some javascript objects alive during garbage collection. This can lead to an exploitable crash allowing for arbitrary code execution. (CVE-2013-0745, MFSA 2013-08)

In com cases, jsval-returning quickstubs fail to wrap their return values, causing a compartment mismatch. This mismatch can cause garbage collection to occur incorrectly and lead to a potentially exploitable crash. (CVE-2013-0746, MFSA 2013-09)

Events in the plugin handler can be manipulated by web content to bypass same-origin policy (SOP) restrictions. This can allow for clickjacking on malicious web pages. (CVE-2013-0747, MFSA 2013-10)

Using the toString function of XBL objects can lead to inappropriate information leakage by revealing the address space layout instead of just the ID of the object. This layout information could potentially be used to bypass ASLR and other security protections. (CVE-2013-0748, MFSA 2013-11)

An integer overflow is possible when calculating the length for a Javascript string concatenation, which is then used for memory allocation. This results in a buffer overflow, leading to a potentially exploitable memory corruption. (CVE-2013-0750, MFSA 2013-12)

When using an XBL file containing multiple XML bindings with SVG content, a memory corruption can occur. In concern with remote XUL, this can lead to an exploitable crash. (CVE-2013-0752, MFSA 2013-13)

It is possible to change the prototype of an object and bypass Chrome Object Wrappers (COW) to gain access to chrome privileged functions. This could allow for arbitrary code execution. (CVE-2013-0757, MFSA 2013-14) 

It is possible to open a chrome privileged web page through plugin objects through interaction with SVG elements. This could allow for arbitrary code execution.  (CVE-2013-0758, MFSA 2013-15)

By the exposing of serializeToStream to web content, a use-after-free may occur in XMLSerializer. This can lead to arbitrary code execution when exploited. (CVE-2013-0753, MFSA 2013-16)

A use-after-free was reported within the ListenerManager when garbage collection is forced after data in listener objects have been allocated in some circumstances. This can lead to arbitrary code execution. (CVE-2013-0754, MFSA 2013-17)

Using the domDoc pointer within Vibrate library, memory may be used after being freed. This can lead to arbitrary code execution when exploited. (CVE-2013-0755, MFSA 2013-18)

A garbage collection flaw in Javascript Proxy objects can lead to a use-after-free leading to arbitrary code execution. (CVE-2013-0756, MFSA 2013-19)

TURKTRUST, a certificate authority in Mozilla\u2019s root program, has mis-issued two intermediate certificates to customers. The issue was not specific to Firefox but there was evidence that one of the certificates was used for man-in-the-middle (MITM) traffic management of domain names that the customer did not legitimately own or control. This issue was resolved by revoking the trust for these specific mis-issued certificates. (CVE-2013-0743, MFSA 2013-20)

This update also fixes HTML5 opus audio playback.

Comment 1 Bill Wilkinson 2013-01-12 21:42:29 CET
I was unable to find test cases for the security updates upstream through mozilla bugzilla.  Testing the opus codec on http://people.xiph.org/~giles/2012/opus/ was successful.  Operation on several web sites including flash showed no problems. Mail and chat work as expected.

Iceape is showing icedtea-web 1.3.1 plugin in plugin manager, but java testers (e.g. http://www.javatester.org/version.html ) are showing java as disabled.


CC: (none) => wrw105

Comment 2 Bill Wilkinson 2013-01-12 21:58:24 CET
Just double checked after an iceape restart - the plugin wasn't originally enabled, but reenabling it and restarting again showed java working, reporting 1.6.0_24.
 x86_64 working well.
Comment 3 claire robinson 2013-01-12 22:01:28 CET
Well done Bill. You just need to set the whiteboard keyword.
Bill Wilkinson 2013-01-12 22:05:58 CET

Whiteboard: (none) => MGA2-64-OK

Comment 4 Philippe Didier 2013-01-13 02:17:44 CET
MGA2 32 bits

Updating from an everyday used iceape 2.14.1-1 to 2.15-1

Everything went fine : the mail, news and chatzilla configurations are preserved
The mail folders are OK

the previously installed plugins and extensions for the web browser  are verified and working

the opus codec is OK and tested

no problem for java ( it was already installed and enabled)

The bundled lightning module (version 2.0b1) and timezone calendar module are proposed to get activated (they were not for previous version of iceape) and work (though the lightning is not yet well localized, and has not yet a working link to a french page ) 

There's only a cosmetic problem about the global language which is reverted to english (the bundled language packs allow to choose again your native language but you must know where to configure this ... and know enough English to read the menus....) : strangely, these last preferences are lost in prefs.js 

user_pref("general.useragent.locale", "fr")
user_pref("intl.accept_languages", "fr,fr-fr,en-us,en")

user_pref("general.useragent.locale", "en")
user_pref("intl.accept_languages", "en-us,en")

Many Thanks to Christiaan

I would say it's OK for MGA32 bits (unless the little language problem prevents to validate it)

CC: (none) => philippedidier

Comment 5 Philippe Didier 2013-01-13 14:27:08 CET
To Christiaan 

Sorry : I did a mistake and a wrong diagnostic about language preferences and user interface language...

Tried again with backuped profiles

uninstall iceape 2.15-1
recover the last previous backup profile
install last iceape  2.14.1-1

Everything OK : user interface language is french, prefered browser language is French, language spelling is French with iceape 2.14.1-1

Update to iceape 2.15-1

User interface language is now English and can't be modified .
(/menu/edit/preference/appearance : => no other choice than English)
nevertheless the prefered browser language selected is always French, the language spelling selected is French. but don't work :-(
the prefs.js file is not modified at all.

There's only one way to correct this : disable and enable again the French language pack ( /menu/tools/add-on manager)
and then everything is corrected (/menu/edit/preference/appearance : => french is selected without anything to do)
quit and start again iceape and the user interface is right...

doing this we get a modification in prefs.js :
it is now
user_pref("extensions.bootstrappedAddons", "{\"langpack-fr@seamonkey.mozilla.org\":{\"version\":\"2.15\",\"type\":\"locale\",\"descriptor\":\"/usr/lib/iceape-2.15/extensions/langpack-fr@seamonkey.mozilla.org\"}}");
and it was 
user_pref("extensions.bootstrappedAddons", "{\"langpack-fr@seamonkey.mozilla.org\":{\"version\":\"2.14\",\"type\":\"locale\",\"descriptor\":\"/usr/lib/iceape-2.14/extensions/langpack-fr@seamonkey.mozilla.org\"}}");

To summarize : 
the bundled langpack has a hard address in user's profile : prefs.js (/usr/lib/iceape-2.14/extensions/langpack-*) and when we update iceape from 2.14 to 2.15 this address is not automatically modified and there is no link to /usr/lib/iceape-2.15/extensions/langpack-*)
 (there's no problem with the extensions added in the user profile directory, such as flashgot, adblock ... : their address remain identical)

I don't know how it could be automatically modified in each user profile !

The update needs an advice about this for non English users :
After having updated, you need to disable and reenable your langpack in /menu/tools/add-on manager

besides this little problem (with this simple workaround) the update is OK !

Comment 6 Philippe Didier 2013-01-13 14:55:33 CET
Post scriptum

Beware of the fact that depending on which news browser you use to follow gmane.linux.mageia.bugs you may have a wrong display of the extract of prefs.js that I provided :

the folder name : langpack-fr@seamonkey.mozilla.org\
may become wrongly displayed as a mail address (!!!???) :

it is correctly displayed when using firefox to read :

Comment 7 Philippe Didier 2013-01-13 15:05:12 CET
Post post scriptum :)

Definitely unable to correctly display this in a news browser :-(

The post scriptum is even worse to read !!!!

just can say that I never wanted to write any mail address but only a folder name including an arobase : (@)
Comment 8 claire robinson 2013-01-14 15:46:46 CET
Thanks Bill and Philippe


Advisory & srpms in comment 0

Could sysadmin please push from core/updates_testing to core/updates


Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Whiteboard: MGA2-64-OK => MGA2-64-OK mga2-32-OK

Comment 9 Thomas Backlund 2013-01-14 22:40:19 CET
Update pushed:

CC: (none) => tmb
Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.