Bugzilla Bug 234689

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 )

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.