#956 Need to audit packageset for bundling of libiberty
Closed None Opened 11 years ago by toshio.

= phenomenon =

There's a security vulnerability in libiberty. We know that packages are bundling it and will need to be updated but we don't know what they are or how much change will need to be introduced into those pieces of code to plug this vulnerability.

= background analysis =

In the F13 timeframe, FESCo and the FPC worked together to define the concept of copylibs as one basis for granting exceptions to the No Bundled Library rule. As part of that, ajax took a look at one copylib, libiberty, and found 24 packages that bundled it:

https://fedorahosted.org/fesco/ticket/370#comment:13

The FPC rules for exceptions to the No Bundled Library rule requires that packages that bundle a library add a Virtual Provide: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Copylibs

For libiberty, that is: 'bundled(libiberty)'

Unfortunately, the packages that ajax discovered weren't updated with the virtual provide. As of F17, only two packages, gdb and insight provide 'bundled(libiberty)'.

This problem may affect other packages that were added -- for instance, no package has a virtual provide of 'bundled(egglib)' or 'bundled(binc)'. I don't know if any packages are currently bundling those libraries so I don't know if this is an actual problem or just a sign that those libraries are obsolete.

For libiberty, the problem has become apparent because of a CVE against it: ​https://bugzilla.redhat.com/show_bug.cgi?id=849693
a repoquery --whatprovides 'bundled(libiberty)' only reveals 2 packages that have the proper Virtual Provides: gdb and insight.

= implementation recommendation =

There's several steps that need to be taken:

  • The packages that bundle libiberty need to be identified by auditing the sources of the package set.
  • Implementations: Ask ajax if he has anything (scripts, procedure that he could document, results) from his F13 audit that could give us a headstart.
  • Make a cattle call for people who can audit the package set for libiberty
    • Note: If ajax has his results, we may decide it's not worthwhile to manually search the packageset for other instances of bundling as those would hopefully have been caught on new package review.
  • Have someone who can organize handing out managable sets of packages to be dealt with by the volunteers who show up

  • The packages with bundled copies of libiberty have to have the vulnerability fixed.

  • Once we start to assemble a list of affected packages, file bugs for all affected packages
  • Find a few people on hand who can explain how to fix the issue to the maintainers
  • Set a date for maintainers to have fixed the issue.
  • Find a few people who can fix packages where the maintainer hasn't done it before the deadline.

  • The packages with bundled copies need to have the required Virtual Provide added at the same time so that finding these packages in the future is easier.

  • Have a provenpackager who adds the necessary virtual Provides to all packages that are identified

  • Packagers should be reminded to add the virtual Provides for any libraries that they bundle.

  • Once the packages are patched, FESCo can send out a message to devel-announce letting people know about the work that's been done and that the work would have been greatly reduced if packagers kept their virtual provides for bundled libraries accurate and up to date.

ajax doesn't have the list around still. But he may have sent it to the fesco mailing list. If someone would care to browse the archives for 2010-07 and 2010-08 you may be able to find a list.

If not, the procedure he used was just to look for the libiberty directory in exploded source trees. So something like:

find . -name 'libiberty' -type d

I checked archives, there's no private list posts related to this in that timeframe I am afraid.

It would be helpful if pkgdb-cli list --all --nameonly didn't return 500.

So... time for fesco to put out a call for help? Who's taking the action item and who's going to organize the effort?

I can put out a call on -devel, after a bit of research, unless someone comments here first.

Ohh, I think I found something, stay tuned.

Ok, I took this:

http://cecinestpasunefromage.wordpress.com/2012/06/01/need-to-docheck-something-on-lots-of-packages/

And wedged in some koji bits from rel-eng's mass-rebuild script, and am running a mass clone and prep now. We'll see.

Got the kinks worked out, and am currently cloned and prepped all the way through A-Z and a and am into b.

It will be a bit. I'll let it go overnight when I get home.

FYI, I'm in the 'g's. Here's what we've got through 'gnash':
./binutils/binutils-2.23.51.0.3/libiberty

./avr-gdb/avr-gdb-7.1/gdb-7.1/libiberty

./cross-gcc/gcc-4.7.1-RC-20120606/gcc-4.7.1-RC-20120606/libiberty

./arm-gp2x-linux-gcc/arm-gp2x-linux-gcc-4.1.2/gcc-4.1.2/libiberty

./cross-binutils/binutils-2.22.52.0.3/binutils-2.22.52.0.3/libiberty

./ghdl/gcc-4.3.4/libiberty

./compat-gcc-32/gcc-3.2.3-20040701/libiberty

./gccxml/gccxml-0.9.0-20120309/GCC/libiberty

./gcc/gcc-4.7.2-20121009/libiberty

./gdb/gdb-7.5.0.20120926/libiberty

./compat-gcc-34/gcc-3.4.6-20060404/libiberty

./avr-binutils/avr-binutils-2.20/binutils-2.20/libiberty

./avr-gcc/avr-gcc-4.6.3/gcc-4.6.3/libiberty

./arm-gp2x-linux-binutils/arm-gp2x-linux-binutils-2.16.1/binutils-2.16.1/libiberty

Ok, here's the whole list.

./msp430-gcc/msp430-gcc/gcc-4.6.3/libiberty

./mono-debugger/mono-debugger-2.10/sysdeps/bfd/libiberty

./gccxml/gccxml-0.9.0-20120309/GCC/libiberty

./gdb/gdb-7.5.0.20120926/libiberty

./mingw-gdb/gdb-7.5/libiberty

./ghdl/gcc-4.3.4/libiberty

./gputils/gputils-0.14.2/libiberty

./insight/insight-7.4.50/libiberty

./mingw-binutils/binutils-2.22.52.0.4/libiberty

./mingw-crt/mingw-w64-v2.0.999/binutils/src/libiberty

./mingw-crt/mingw-w64-v2.0.999/gcc/src/libiberty

./mingw-gcc/gcc-4.7.2/libiberty

./mingw-headers/mingw-w64-v2.0.999/binutils/src/libiberty

./mingw-headers/mingw-w64-v2.0.999/gcc/src/libiberty

./mingw-w64-tools/mingw-w64-v2.0.999/binutils/src/libiberty

./mingw-w64-tools/mingw-w64-v2.0.999/gcc/src/libiberty

./msp430-binutils/msp430-binutils/binutils-2.21.1/libiberty

./binutils/binutils-2.23.51.0.3/libiberty

./sdcc/sdcc/support/cpp/libiberty

./sdcc/sdcc/support/sdbinutils/libiberty

./sh-elf-binutils/sh-elf-binutils-2.21/binutils-2.21/libiberty

./compat-gcc-32/gcc-3.2.3-20040701/libiberty

./nesc/nesc-1.3.4/libiberty

./compat-gcc-34/gcc-3.4.6-20060404/libiberty

./arm-gp2x-linux-binutils/arm-gp2x-linux-binutils-2.16.1/binutils-2.16.1/libiberty

./arm-gp2x-linux-gcc/arm-gp2x-linux-gcc-4.1.2/gcc-4.1.2/libiberty

./cross-binutils/binutils-2.22.52.0.3/binutils-2.22.52.0.3/libiberty

./cross-gcc/gcc-4.7.1-RC-20120606/gcc-4.7.1-RC-20120606/libiberty

./gcc/gcc-4.7.2-20121009/libiberty

./avr-binutils/avr-binutils-2.20/binutils-2.20/libiberty

./avr-gcc/avr-gcc-4.6.3/gcc-4.6.3/libiberty

./avr-gdb/avr-gdb-7.1/gdb-7.1/libiberty

Does anyone want to do anything before I create a tracker and start filing BZs?

So, really what we need to do here is:

  • Add 'Provides: bundled(libiberty)'

  • Bump release

Perhaps we could just script that like we do for mass rebuilds and be done with it?

Don't they need patching?

For the actual security vulnerability, yes.

But I was thinking adding the provides would be something that could be done first in an automated way then that list can be used to populate bugs for the security issue.

I guess it's not a major deal, just seems like it's cleaner to get the provides all at once and then move forward from there.

Ok, I'll do the provides first and update here.

Provides are done, and all are built, with 3 exceptions. compat-gcc-32 and compat-gcc-34 are and already were FTBFS. sdcc is now FTBFS, but wasn't in July when it was last updated.

Missed cross-gcc, building now.

cross-gcc is done. Anything specific to reference in the BZs?

It might be best to simply update https://bugzilla.redhat.com/show_bug.cgi?id=849693 with the list (or repoquery to show the list) and ask them to file security bugs against them. Security folks likely have scripting to do this and want a specific format, etc.

Anything more for us to do here? Or shall we close this now?

Step 1 and step 3 have been done.

Step 2 (get the packages fixed -- put out a call for packagers to help if necessary) has not been done. I've added a comment to the Security bugzilla entry since it might have fallen through the cracks that we were expecting them to open bugs.

Step 4 (Send a reminder to package maintainers to use the virtual provides ) has not been done. It could be done now if we just want to talk about the audit and Virtual Provides having been added (thanks limburgher!) or we could wait for Step 2 to complete if we don't want to draw undue attention to the vulnerability until the other packages have been fixed.

Replying to [comment:22 toshio]:

Step 1 and step 3 have been done.

Step 2 (get the packages fixed -- put out a call for packagers to help if necessary) has not been done. I've added a comment to the Security bugzilla entry since it might have fallen through the cracks that we were expecting them to open bugs.

Step 4 (Send a reminder to package maintainers to use the virtual provides ) has not been done. It could be done now if we just want to talk about the audit and Virtual Provides having been added (thanks limburgher!) or we could wait for Step 2 to complete if we don't want to draw undue attention to the vulnerability until the other packages have been fixed.

Do you want to finish the work or do you need anything from FESCo?

The security team's desires are a little opaque to me but going on what's in the bugzilla I think it might be time for FESCo to put out a cattle call and arrange to track the fixed packages themselves (with tracking bugs or one person to coordinate). The last entry in bugzilla mentions that the only tracking bug opened so far is for gdb and that bug hasn't been touched yet.

I would suggest create bugs for those packages, which surely export those symbols:
binutils, crash, insight, mono-debugger, and mutrace.

limb: do you want to create those bugzillas?

Filed, all block 849693.

I asked Jan why it's the bug not fixed. See his (now public) comment:
https://bugzilla.redhat.com/show_bug.cgi?id=849693#c2

The bug doesn't have high security impact, I do not think it will be fixed. I agree that provides bundled(libiberty) should be added in specfiles, but that's all what should be done.

The problem is better stated in:

https://bugzilla.redhat.com/show_bug.cgi?id=849693#c33

The bug in gdb doesn't have a high security impact. But each package using libiberty would need to be audited in the same way to determine whether the same applies to them.

Just reviewed this... AFAICT, we're in the same state now as we were 13 months ago :-(

I think we should take care of point 4 now -- send out a message to devel-announce to remind packagers to add virtual Provides for bundled libraries.

That will only leave point 2 -- fixing the CVE in packages which have libiberty bundled. there's one unfixed package that was definitely identified as both bundling libiberty and making use of the affected function: mondebugger https://bugzilla.redhat.com/show_bug.cgi?id=877017

There are additional packages in the list on: https://bugzilla.redhat.com/show_bug.cgi?id=849693#c29 that have not been acted upon (it hasn't been determined if they make use of the actual function which is exploitable, if there are mitigating factors, or even if they have patched libiberty to not carry the vulnerability.)

I propose that FESCo open bugs against all packages that are bundling libiberty:

These show up with repoquery --whatprovides 'bundled(libiberty)':

  • nesc-0:1.3.4-3.fc19.x86_64
  • gdb-0:7.6.50.20130731-16.fc21.x86_64
  • binutils-0:2.24-8.fc21.x86_64
  • sdcc-0:3.3.0-0.fc21.x86_64
  • avr-binutils-1:2.23.2-3.fc20.x86_64
  • msp430-binutils-0:2.21.1a-3.fc19.x86_64
  • ghdl-0:0.29-4.150svn.3.fc21.x86_64
  • insight-0:7.4.50-10.20120403cvs.fc20.x86_64
  • msp430-gcc-0:4.6.3-2.fc19.x86_64
  • mono-debugger-0:2.10-7.fc20.i686
  • avr-gcc-0:4.8.2-1.fc21.x86_64
  • gcc-0:4.8.2-7.fc21.x86_64
  • avr-gdb-0:7.1-9.fc20.x86_64
  • gputils-0:1.2.0-3.fc20.x86_64
  • gccxml-0:0.9.0-0.19.20131209.git9a114c0c.fc21.x86_64
  • compat-gcc-34-0:3.4.6-29.fc19.x86_64
  • mono-debugger-0:2.10-7.fc20.x86_64

Bundles older/upstream gdb and therefore bundles libiberty. I had to add the virtual Provide for this:
* crash

These three don't show the bundled(libiberty) Provides in repoquery because they don't generate binary packages for the main package:

  • compat-gcc-32
  • cross-binutils
  • cross-gcc

We can subtract the ones that we know have been dealt with already (from the bug report I found):

  • insight (updated)
  • crash (updated)
  • binutils (patched)
  • gdb (analysis showed that gdb can be crashed by this bug but code cannot be executed. Closed as not a bug)
  • monodebugger: Bug open. No need for a separate bug: https://bugzilla.redhat.com/show_bug.cgi?id=877017

The bug reports should say something like:

libiberty is a collection of functions that are used in a variety of GNU projects. It is designed to be bundled into consuming applications. Unfortunately, one of the functions provided by libiberty has recently been the subject of a CVE. Whenever that happens we have to have packagers of all the consuming applications analyze their package's use of libiberty to decide whether they're affected or not. If affected, the bundled libiberty code needs to be updated.

You can fix this issue in one of the following ways:

  • Analyze your package's code to see if the _objalloc_alloc() function in libiberty/objalloc.c is vulnerable. If so, check whether your package compiles it in and uses the _objalloc_alloc() from libiberty. If so, you may further analyze the package code to see if invalid input can be passed to _objalloc_alloc() and if so, if that input can cause any problems for the application. If that's all true, then you must fix the code in question. If your code is not affected you can close this bug with an explanation of why the _objalloc_alloc() flaw doesn't affect your code.
  • Alternatively, premptively patch the libiberty _objalloc_alloc() code to perform the required overflow checking. This may be less work than doing all of that analysis and may also save you from future headaches because you might not know if your upstream changes its code to start using the _objalloc_alloc() function in the future. You can find a patch for this issue that you may be able to use here: https://bugzilla.redhat.com/attachment.cgi?id=614014&action=diff&context=patch&collapsed=&headers=1&format=raw

This mess shows how broken the concept of a "copylib" is.

  • ACTION: abadger199 to modify the proposal to include what's in the bugzilla comment 30 and link to the upstream patch for the Analysis section and move analysis to the second option.
  • With the modifications that abadger1999 will make, the proposal is approved (+1:5, 0:0, -1:0)
  • ACTION: abadger1999 to take care of the bug filings and other followup as well (abadger1999, 19:00:19)

Adding to the meeting agenda to follow up on this.

Oops -- This slipped off my radar.

/me gets started on those followup items.

  • 956 Need to audit packageset for bundling of libiberty (sgallagh,


    18:41:01)
  • abadger1999 has nearly finished filing bugs. Nothing more for FESCo
    to do. Close ticket. (sgallagh, 18:43:17)

Login to comment on this ticket.

Metadata