Slackware issued an advisory on December 16: http://www.slackware.com/security/viewer.php?l=slackware-security&y=2013&m=slackware-security.480127 You can find the patch they applied (after ./configure) here: http://mirrors.slackware.com/slackware/slackware-current/source/l/libiodbc/ It's an ugly way to do it, and you'd think it'd be better to patch configure, but it isn't clear which of the 10 instances of hardcode_libdir_flag_spec being defined with rpath in it you'd change to replicate their change to the "libtool" script. It's also not clear to me what this vulnerability really is or if fixing this is necessary. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA3TOO
More info on this: http://openwall.com/lists/oss-security/2013/12/19/2
A CVE was assigned for this: http://openwall.com/lists/oss-security/2013/12/20/1
Summary: libiodbc possible security issue => libiodbc possible security issue (CVE-2013-7172)
Blocks: (none) => 11726
I'd say this is invalid, but I fixed it anyway. $ objdump -x /usr/bin/iodbctest |grep RPATH RPATH /home/iurt/rpmbuild/BUILD/libiodbc-3.52.7/iodbc/.libs $ objdump -x /usr/bin/iodbctestw |grep RPATH RPATH /home/iurt/rpmbuild/BUILD/libiodbc-3.52.7/iodbc/.libs Fixed with libiodbc-3.52.8-2.1.mga3 + libiodbc-3.52.8-7.mga4
CC: (none) => oe
So is the issue that someone could put libraries in that RPATH directory and then libiodbc would load them? I guess it'd be less of an issue for us since we don't use /tmp as the build directory as slackware apparently does, but I guess if you had a user named iurt it could still be an issue :o)
Version: Cauldron => 3Whiteboard: MGA3TOO => (none)
(In reply to David Walser from comment #4) > So is the issue that someone could put libraries in that RPATH directory and > then libiodbc would load them? I guess it'd be less of an issue for us > since we don't use /tmp as the build directory as slackware apparently does, > but I guess if you had a user named iurt it could still be an issue :o) Not "libiodbc" would load them, but those two binaries I meant of course...
Yes. Highly unlikely. I won't fox this for mbs1.
Thanks Oden! I think it'll be OK to leave this fixed in SVN and leave the bug open unless we have to issue an update for this package for some other reason later.
Severity: normal => minor
Blocks: 11726 => (none)
Does comment #7 mean we can remove the update from updates_testing?
CC: (none) => stormi
(In reply to Samuel VERSCHELDE from comment #8) > Does comment #7 mean we can remove the update from updates_testing? Can I suppose, though I don't see a need to.
(In reply to David Walser from comment #9) > (In reply to Samuel VERSCHELDE from comment #8) > > Does comment #7 mean we can remove the update from updates_testing? > > Can I suppose, though I don't see a need to. Taken alone, there's not a huge need to remove it, but cleaning the updates_testing repos from time to time helps to spot actual missed updates candidates. The ones where the package says "there's xxx.rpm to validate in updates_testing" and forgets (or doesn't know) the process involving QA. The smaller the list of packages at http://mageia.madb.org/rpm/list/source/1/application/0/listtype/updates_testing the better :)
Closing due to Mageia 3 EOL: http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/
Status: NEW => RESOLVEDResolution: (none) => OLD