#954 Need to plan and perform Fedora 18 C++ packages mass rebuild due to gcc fix for CVE-2002-2439
Closed None Opened 11 years ago by jlieskov.

From Florian Weimer:

Hi,

I'd like to get a fix for the operator new[] into RHEL 7 because this
GCC misfeature introduced vulnerabilities before. Here's a relatively
recent example where the operator new[] overflow led to the need for an
erratum: https://bugzilla.redhat.com/show_bug.cgi?id=821803 (Note that
this was initially misclassified.)

CVE-2009-3608 is another example. Mozilla identifies CVE-2010-2765 and
CVE-2011-077 as being related to the operator new[] issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=466445 There are likely
more such cases.

One annoying aspect is that the vulnerability lies within compiled GCC
code. The offending multiplication is in code which is expanded inline
by the compiler. So it's not just a matter of patching GCC, we'd have
to rebuild all C++ programs using a patched compiler.

This has been fixed upstream in late August. As far as I know, there
have been now complaints about regressions. A subsequent patch for a
related library function still awaits review:

http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01416.html

But this function isn't used by GCC, so it is less critical for us (but
we should get it in eventually).

I opened a bug for getting this fix into Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=850911

I discussed this with Jakub and made a backport proposal following his
suggestions. However, I've not been able to move this forward (I've
pinged Jakub on 2012-09-12 without reply), and I fear that we might miss
some deadline to get this into RHEL 7.

Florian

Florian Weimer / Red Hat Product Security Team


Summary (jlieskov):
1) to have CVE-2002-2439 issue fixed in Fedora 18, gcc fix is not enough,
2) based on the above all C++ packages, that might be using the vulnerable
new[] implementation would require to be rebuilt too,
3) as of right now Fedora gcc package versions aren't updated wrt to CVE-2002-2439:
https://bugzilla.redhat.com/show_bug.cgi?id=853918
https://bugzilla.redhat.com/show_bug.cgi?id=850911
4) but once this is done, we would need to plan and perform Fedora 18 C++
packages mass rebuild (the true purpose of this ticket)


Is there any kind of ABI change from this? If not, just put the change in gcc and RHEL 7 will get built with it. Fedora binaries aren't directly imported into RHEL.

Replying to [comment:1 mjg59]:

Is there any kind of ABI change from this?

After check with Florian, no, this shouldn't lead to ABI change (just the code needs to be re-generated to be generated in correct way).

If not, just put the change in gcc and RHEL 7 will get built with it. Fedora binaries aren't directly imported into RHEL.

Ok, brilliant. Thank you.

The fix should be in F-18 soon. Do we want plan rebuild of packages for F-18?

Please minimize the list of packages to be rebuilt if possible, full distro rebuild takes 2-4 weeks on secondary arches (this means an additional delay for our GA) and costs serious amount of storage and other resources. Thanks, Dan for Fedora/s390x

FESCo:

agreed Get the gcc with fix in f18, but do no mass rebuild. Only packages with specific vulnerability should be rebuild.

I'll leave it open for comments. It could be closed as soon as the fix will be in Fedora 18.

It doesn't appear this is in f18 yet. ;(

Any progress?

Replying to [comment:8 kevin]:

It doesn't appear this is in f18 yet. ;(

Any progress?

The fix is in F18's GCC. I've just verified by compiling a small test program. We miss an optimization for new char[n], but that's been stuck in upstream review for a while: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02966.html

I think it was decided not to do another mass rebuild. I believe most of the critical packages (Firefox, Thunderbird, Libreoffice) have already been built since the fix went into GCC.

Login to comment on this ticket.

Metadata