When extracting a specially crafted xbox-iso image, it is possible to traverse directories. Maybe it's possible to overwrite the .bashrc with arbitrary code. Reproducible: Always Steps to Reproduce: 1. Get a specially crafted ISO-File 2. Extract 3. Check results Actual Results: bash-2.05b$ extract-xiso test.iso extract-xiso v2.4b2 for linux - written by in <in@fishtank.com> extracting test.iso: extracting test/.%2f..%2f..%2f..%2fTESTFILE (0 bytes) [OK] extracting test/./../../xploit (0 bytes) [OK] extracting test/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA~ (0 bytes) [OK] extracting test/OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO (0 bytes) [OK] 4 files in test.iso total 0 bytes bash-2.05b$ xdvdfs_extract test.iso Opening input file / device... Mounting filesystem... Extracting files... /./../../xploit /.%2f..%2f..%2f..%2fTESTFILE /AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA~ /OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO Done. bash-2.05b$ xbiso test.iso bash: xbiso: command not found bash-2.05b$ ./xbiso test.iso Failed to create root directory: File exists Extracting file ./../../xploit Extracting file AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA~ Extracting file OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO Extracting file .%2f..%2f..%2f..%2fTESTFILE End of archive Expected Results: Do whatever is necessary to prohibit directory traversals
Upstream looks dead on xbiso and extract-xiso...
xiso bugzilla has a bug open for "Segmentation Fault (due to 'long filenames'?)" for a while. It's probably exploitable as well. I guess when these apps were written nobody thought about malicious ISO images. There's a perl port of xbiso at http://www.bogus.net/~codex/files/xbiso.tar.gz. Maybe it could be a suitable replacement (assuming it does better path checking, it does at least force a -d option) if no fix is forthcoming. xdvdfs-tools seems to have an official page now http://www.layouts.xbox-scene.com/ and a newer 2.1 release. Stefan, do you have any idea whether it's also vulnerable?
xdvds_extract 2.1 has the same problem.
Maybe you could report it upstream? I had a quick look at the new xdvdfs tools site but couldn't find an email address anywhere.
Ok, I tried to contact a guy called VooD via an email-address i found in his forum-profile. Let's hope it works...
Got a response from Vood. Upstream (Somebody called CloneXB) is now aware of this, but it'll probably take some time till he updates, since he is very busy.
Hi, I checked the extractor code, and I think CloneXB didn
Hi, I checked the extractor code, and I think CloneXB didn´t make any change from the original by [SNK]/Supremacy. The extractor fitted our needs so we didn´t need to change anything and we focused on the xbox layout dumper and new options/fixes for the creator. Anyway is in pure C, and is very simple,so I think It won´t be hard for a medium linux user to fix that. Also, I think CloneXB has not coding experiences with linux so...maybe you´ll get a faster solution by just asking some good linux coder to fix the problem. Btw, sorry for not including any email adress on the web, but I use to visit the web´s forums everyday, and either CloneXB, Moobar, and me are easily accesible from Xbox-Scene forums. (I had VERY bad experiences with spam, and users in a previous project) If some of you finally manages to fix that security issue let me know, so I could send the fixes to CloneXB and include them in the next "official" release...maybe we should open a sf.net account but XBDVDFS_tools original coder is hard to contact (VERY...in fact all the feedback we got from him in 6 months of work was a post in xbox-scene) and I think we should first ask him for his permission. Regards
I've commited fixes for them all. xdvdfs-tools is version bumped and only the latest one has the fix (I'll remove the older one if it works ;-)). Stefan can you please test whether the fixes work with your modified ISOs and report back. As regards sourceforge, I'd say go for it, since it's GPL license and the original author appears to have abandoned it.
None of my modified images works with the patched version of xdvdfs-tools. Good work. VooD, an sf-project would be great. xdvdfs-tools is, imho, the best tool of the 3 mentioned in this bug, give it a try!
Created attachment 59552 [details, diff] xdvdfs-tools-2.1-fnamefix.patch
xbiso and extract-xiso patches submitted upstream, maybe someone will take care of them. Attaching xdvdfs-tools patch here, since it has no upstream. Closing.
Chris: security will close it when the vulnerability will be fixed... Please bump xdvdfs-tools with the patch, and we'll wait for upstream on the other two.
I've already commited patches for them all. I have a feeling upstream may be unresponsive..
Great :) Could you revbump them so that people pick the fix up by upgrading ? This is also needed for GLSA, should we include one. Thx in advance
Done.
Thx Chris ! Ready for GLSA vote
I vote for a GLSA on this one.
i'm no real dev, but i vote for no GLSA. exploitation is hard (i'm not really sure if its possible to extract actual content to files, i only managed to overwrite with 0byte files, you've got to know the name of the file to overwrite etc) it's a poor directory traversal and the affected tools aren't widely spread.
I tend to vote NO on this one too.
Agreed it's a little unlikely, voting NO and closing.