Directing your attention to pym/portage/xpak.py, xpand function and tbz2.unpackinfo, those functors are basically the same thing, and both assume that the tbz2 it is examining is trustworthy. That's a dumb assumption, obviously. Picking on xpand: 248 def xpand(myid,mydest): 249 myindex=myid[0] 250 mydata=myid[1] 251 try: 252 origdir=os.getcwd() 253 except SystemExit as e: 254 raise 255 except: 256 os.chdir("/") 257 origdir="/" 258 os.chdir(mydest) 259 myindexlen=len(myindex) 260 startpos=0 261 while ((startpos+8)<myindexlen): 262 namelen=decodeint(myindex[startpos:startpos+4]) 263 datapos=decodeint(myindex[startpos+4+namelen:startpos+8+namelen]); 264 datalen=decodeint(myindex[startpos+8+namelen:startpos+12+namelen]); 265 myname=myindex[startpos+4:startpos+4+namelen] 266 dirname=os.path.dirname(myname) 267 if dirname: 268 if not os.path.exists(dirname): 269 os.makedirs(dirname) 270 mydat = open(_unicode_encode(myname, 271 encoding=_encodings['fs'], errors='strict'), 'wb') 272 mydat.write(mydata[datapos:datapos+datalen]) 273 mydat.close() 274 startpos=startpos+namelen+12 275 os.chdir(origdir) Line #269, this allows arbitrary directory creation. Line #270-273 allows arbitrary writing to the fs of content the attacker wishes utilizing the privileges of whatever user triggered the xpak load. The problem here is this is how portage pulls apart xpak data; meaning this is ran for /any/ xpak loads; if Packages doesn't have the necessary data, xpak is loaded. No Packages cache, xpak is loaded for any key access, etc. Considering pkg_pretend is ran for arbitrary remote binpkgs, there already are some holes here; pretty sure in a quick glance through the binpkg hash code that also looks like it's got holes in it. Either way, pointing this one out since it's very easy to fix; http://code.google.com/p/pkgcore/source/browse/pkgcore/binpkg/xpak.py . Currently marked security only- adjust as y'all see fit.
(In reply to comment #0) > Considering pkg_pretend is ran for arbitrary remote binpkgs, there already are > some holes here; pretty sure in a quick glance through the binpkg hash code > that also looks like it's got holes in it. Yeah, can't see a point in making this a non-public bug when it's common knowledge that a binpkg contains executable content that poses a security threat if it's compromised somehow. Obviously, we'd have to sign the hashes in order head off MITM attacks.
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b3cfb2065ccbeb8f769d630ff997c0327fb2eb35
This is fixed in 2.1.10.46 and 2.2.0_alpha86.
