Summary: | media-sound/amarok <1.4.10 insecure creation of temporary file (CVE-2008-3699) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Raphael Marichez (Falco) (RETIRED) <falco> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | kde, sound |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494765 | ||
Whiteboard: | B3 [glsa] Falco | ||
Package list: | Runtime testing required: | --- |
Description
Raphael Marichez (Falco) (RETIRED)
2008-08-13 23:22:22 UTC
Please mark amarok-1.4.10 (_not_ -r1) stable arch teams. amd64 stable x86 stable sparc stable ppc64 stable ppc stable GLSA vote: I tend to vote yes Should have dropped a word: Turned out this hardly is exploitable as you can read also here: http://amarok.kde.org/blog/archives/777-Responsible-Disclosure,-and-Amarok-1.4.10.html >Secunia has a good description (as usual): Looks more like Secunia is overrating this issue with "less critical". I don't think this deserves a GLSA. carlo, I don't see how this is "hardly" exploitable. It allows for symlink attacks where a local attacker would pre-create the file as a symlink to a file belonging to the user, and amarok dereferences this symlink to overwrite the file. An attacker at one point issues games@peanut ~ $ ln -s /tmp/rbusfile /tmp/album_info.xml The victim (rbu) creates his file: rbu@peanut /tmp $ echo important > rbusfile rbu@peanut /tmp $ ls -la rbusfile album_info.xml lrwxrwxrwx 1 games games 13 2008-08-30 16:02 album_info.xml -> /tmp/rbusfile -rw------- 1 rbu rbu 10 2008-08-30 16:06 rbusfile Then I start amarok, click "Update" in Magnatune and: rbu@peanut /tmp $ ls -la rbusfile album_info.xml lrwxrwxrwx 1 games games 13 2008-08-30 16:02 album_info.xml -> /tmp/rbusfile -rw------- 1 rbu rbu 11M 2008-08-30 16:07 rbusfile (In reply to comment #9) > It allows for symlink > attacks where a local attacker would pre-create the file as a symlink to a file > belonging to the user, and amarok dereferences this symlink to overwrite the > file. The file would have to be created the tiny fraction of time after the existence check and before it is openend - and this in a part of Amarok supposedly very few users of this application run at all. Also it's completely open, if it would be possible to exploit this, while the file is passed through the XML parser. I didn't read of any vulnerability in Qt 3's XML parser. See, this is the code: QFile file( "/tmp/album_info.xml" ); if ( file.exists() ) file.remove(); if ( file.open( IO_WriteOnly ) ) { QTextStream stream( &file ); stream << list; file.close(); } The shell output I pasted above has been obtained by an actual run of the application. There is no race condition to be exploited if the user cannot delete the file (which is the the case if the attacker owns the symlink), the "remove" will be useless -- and its return value is not checked. YES too, request filed. GLSA 200809-08 *hmmmpf* So much for maintainng a critical mind. I followed upstreams argument and since "open" fails when the file handle is already opened I impliend "remove" would keep it open, when it fails, which is nonsense of course. Still, the GLSA wasn't necessary, since a malicious person doesn't gain anything by injecting a file here. (In reply to comment #14) > doesn't gain anything by injecting a file here. That depends on your definition of 'gain'. The attacker can entice a user to overwrite an arbitrary file. If the attacker aims that the user cannot login anymore after that (e.g. by overwriting authorized_keys), he can gain that. |