Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 234689 (CVE-2008-3699) - media-sound/amarok <1.4.10 insecure creation of temporary file (CVE-2008-3699)
Summary: media-sound/amarok <1.4.10 insecure creation of temporary file (CVE-2008-3699)
Status: RESOLVED FIXED
Alias: CVE-2008-3699
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: Gentoo Security
URL: http://bugs.debian.org/cgi-bin/bugrep...
Whiteboard: B3 [glsa] Falco
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-13 23:22 UTC by Raphael Marichez (Falco) (RETIRED)
Modified: 2008-09-13 00:30 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raphael Marichez (Falco) (RETIRED) gentoo-dev 2008-08-13 23:22:22 UTC
Secunia has a good description (as usual):
http://secunia.com/advisories/31418/

Description:
A security issue has been reported in Amarok, which can be exploited by malicious, local users to perform certain actions with escalated privileges.

The security issue is caused due to the "MagnatuneBrowser::listDownloadComplete()" function handling temporary files in an insecure manner. This can be exploited via symlink attacks in combination with a race condition to overwrite arbitrary files with the privileges of the user running the application.

The security issue is reported in version 1.4.9.1. Other versions may also be affected.

Solution:
Restrict local access to trusted users only.

Provided and/or discovered by:
Reported by Dwayne Litzenberger in a Debian bug report.

Original Advisory:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494765

--------------------------------------------------------


No CVE assigned yet.

Needs a race condition between the file.remove() and the file.open() Qt calls.

Fixed in amarok 1.4.10 (see http://amarok.kde.org/en/node/535 )
Comment 1 Carsten Lohrke (RETIRED) gentoo-dev 2008-08-14 21:55:41 UTC
Please mark amarok-1.4.10 (_not_ -r1) stable arch teams.
Comment 2 Thomas Anderson (tanderson) (RETIRED) gentoo-dev 2008-08-15 01:28:28 UTC
amd64 stable
Comment 3 Raúl Porcel (RETIRED) gentoo-dev 2008-08-15 13:52:09 UTC
x86 stable
Comment 4 Friedrich Oslage (RETIRED) gentoo-dev 2008-08-15 21:41:19 UTC
sparc stable
Comment 5 Markus Rothe (RETIRED) gentoo-dev 2008-08-16 07:52:19 UTC
ppc64 stable
Comment 6 Tobias Scherbaum (RETIRED) gentoo-dev 2008-08-19 21:43:00 UTC
ppc stable
Comment 7 Robert Buchholz (RETIRED) gentoo-dev 2008-08-19 22:44:21 UTC
GLSA vote: I tend to vote yes
Comment 8 Carsten Lohrke (RETIRED) gentoo-dev 2008-08-25 23:58:59 UTC
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.
Comment 9 Robert Buchholz (RETIRED) gentoo-dev 2008-08-30 14:11:34 UTC
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

Comment 10 Carsten Lohrke (RETIRED) gentoo-dev 2008-08-31 23:49:26 UTC
(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();
    }
Comment 11 Robert Buchholz (RETIRED) gentoo-dev 2008-09-01 01:16:31 UTC
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.
Comment 12 Tobias Heinlein (RETIRED) gentoo-dev 2008-09-02 17:05:20 UTC
YES too, request filed.
Comment 13 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-09-08 18:14:13 UTC
GLSA 200809-08
Comment 14 Carsten Lohrke (RETIRED) gentoo-dev 2008-09-12 23:08:37 UTC
*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.
Comment 15 Robert Buchholz (RETIRED) gentoo-dev 2008-09-13 00:30:02 UTC
(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.