Bugzilla – Bug 64337
VUL-0: CVE-2005-1847: yamt arbitrary command execution
Last modified: 2021-10-19 13:57:15 UTC
We received the following report. The issue is public. From djb@cr.yp.to Wed Dec 15 14:22:46 2004 Date: 15 Dec 2004 08:28:39 -0000 From: D. J. Bernstein <djb@cr.yp.to> To: securesoftware@list.cr.yp.to, bratislav@users.sourceforge.net Subject: [remote] [control] YAMT 0.5 id3tag_sort does not check for nasty characters Manigandan Radhakrishnan, a student in my Fall 2004 UNIX Security Holes course, has discovered a remotely exploitable security hole in YAMT, an MP3-organization tool. I'm publishing this notice, but all the discovery credits should be assigned to Radhakrishnan. YAMT is no longer maintained, according to its developers, but it is still included in (for example) FreeBSD ports. You are at risk if you take an MP3 file from a web page (or any other source that could be controlled by an attacker) and feed it to the YAMT Sort option. Whoever provides that MP3 file then has complete control over your account: he can read and modify your files, watch the programs you're running, etc. Here's the bug: id3tag_sort(), in id3tag.c, runs the command mv "%s/%s" "%s%s/%s/%s" with various %s strings replaced by, e.g., the MP3 Artist tag. YAMT does not check for nasty characters---in particular, double quotes---inside the Artist tag. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
Is there any patch? Is there any standard function for escaping strings? Besides this, also check for ../ (or slash) in tag is needed, isn't it?
If mv is called though a shell it's probably hopeless to try to escape stuff, you have to use a whitelist instead. It's better to use execl(). You are right, one has to also replace slashes with underscores or something like that.
And two lines above the system() call there is sprintf(), which is vulnerable to buffer overflow. Even for ID3v1, dir_level1 and dir_level2 can have 32 bytes both. 10 characters are in mv command. It means, that you can get buffer overflow, if PWD + rootdir has more than 6 bytes (i. e. in any case). How to fix this? Enlarge buffer? Use asprintf().
for path names you can use a fixed buffer of size PATH_MAX an snprintf into that.
In this case I need something more than 2*PATH_MAX+64+n where 64 is 2x32 - number of charecters in ID3v1 tag n is number of extra letters in command Even in case of sanitization of tag name, PWD cannot be sanitized and if PWD is '/home/me" ; rm -rf ~ ; echo "', system() call will do strange things. My guess of solution: 1. Sanitize artist and song name replacing all '/' by '_'. 2. Don't use system command, but prepare name with two snprintf() commands and then use execl() then.
* This comment was added by mail. | In this case I need something more than 2*PATH_MAX+64+n | where | 64 is 2x32 - number of charecters in ID3v1 tag | n is number of extra letters in command A path to a file on the disk cannot be longer than PATH_MAX. | Even in case of sanitization of tag name, PWD cannot be sanitized and if PWD is | '/home/me" ; rm -rf ~ ; echo "', system() call will do strange things. Where does PWD come from? If it's not read from the id3 tag it's irrelevant. | My guess of solution: | | 1. Sanitize artist and song name replacing all '/' by '_'. | 2. Don't use system command, but prepare name with two snprintf() commands and | then use execl() then. Ok. But hey, it doesn't need to be the perfect solution. yamt is 8.1&8.2 only anyway.
A path to a file on the disk cannot be longer than PATH_MAX, but sprintf() result can. PWD is current directory. And current directory can be a result of previous rename.
* This comment was added by mail. | A path to a file on the disk cannot be longer than PATH_MAX, but sprintf() | result can. That's why one uses snprintf instead of sprintf :-)
Created attachment 27770 [details] yamt-directory-traversal.patch I prepared this patch. Please review. This patch fixes: - directory traversal in rename - directory traversal in sort - arbitrary command execution in sort - buffer overflow in sort (only in this platform - 2*strlen(ID3v1)+1 < PATH_MAX) - buffer overflow in rename (only in this platform - entering suspect Format: is not possible because strlen(ID3v1)*maxlen(Format)<PATH_MAX)
There are still strcat but to exploit those the user would have to define a quite stupid format himself to exceed 4096 bytes by concatenating lots of 30 byte strings => no problem, patch ok.
I guess it's impossible. Format string entry has limited length and yamt works only with ID3v1 tags limited to 32 characters. Fix submitted for 8.1 and 8.2. - Several security fixes (#49337): - directory traversal in rename - directory traversal in sort - buffer overflow in sort - buffer overflow in rename - arbitrary command execution in sort (reported by D. J. Bernstein) Please inform about directory traversal and buffer overflow bugs other interested parties. These were not part of original bug report.
the double quote thing is CAN-2004-1302
Is a patchinfo file missing/needed?
ah, ok.. it's already there.
packages approved.
> >====================================================== >Candidate: CAN-2005-1846 >URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1846 >Reference: CONFIRM:http://rpmfind.net/linux/RPM/suse/updates/8.2/ >i386/rpm/i586/yamt-0.5-1277.i586.html >Reference: CONFIRM:http://www.vuxml.org/freebsd/99b5cfa5- >d3d2-11d9-8ffb-00061bc2ad93.html > >Multiple directory traversal vulnerabilities in YaMT before 0.5_2 >allow attackers to overwrite arbitrary files via the (1) rename or (2) >sort options. > > >====================================================== >Candidate: CAN-2005-1847 >URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1847 >Reference: CONFIRM:http://rpmfind.net/linux/RPM/suse/updates/8.2/ >i386/rpm/i586/yamt-0.5-1277.i586.html >Reference: CONFIRM:http://www.vuxml.org/freebsd/99b5cfa5- >d3d2-11d9-8ffb-00061bc2ad93.html > >Multiple buffer overflows in YaMT before 0.5_2 allow attackers to >execute arbitrary code via the (1) rename or (2) sort options. > >
CVE-2005-1847: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)