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 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:
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
new char[n]
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.