Past Security Attacks
In the interests of full disclosure this page will stand as a permanent record of any security vulnerabilities which have been discovered in the server.
GNUMP3d v2.0 Password File Weakness
GNUMP3d supports two simple methods of securing access to your music archive, (these are described more fully here), IP address access control and a password system.
The password system relies upon their being a file within the music archive containing a list of usernames and passwords which may be used to access the system.
When this system was created I was careful to deny browsers the ability to download this file - as part of the re-write in Perl I missed this important step.
This meant that if password protection were in use it would be possible for an authentificed user to download the password file - gaining access to all other account names and passwords.
This vulnerability was spotted and reported to me by Daniel Lyons <fusion@nmt.edu> and was fixed the same day - with release 2.2
(Due to the fact the release was only out for one day before it was patched, and the low liklihood of this version of the server being widespread in the wild I've chosen to not notify bugtraq et al).
Note: Password protection was removed in 3.0 as being too weak to be useful.
Directory Traversal Attack
There are three bugs relating to directory traversal:
- The first, discovered by "dabfus"
This is a bug which was caused by inadequate filtering of the requested URI. It was fixed with the release of v2.9.3.
- The second, discovered and fixed by myself
This was another issue where clients were allowed to make requests which were not adequately filtered. This was given the ID CAN-2005-3123, and fixed in the release 2.9.7.
- The third, reported to vendor-sec
This related to the handling of CGI parameters, and cookie values.
The issue was given the ID CVE-2005-3355 and fixed in the release of v2.9.8.
Insecure Use of Temporary Files
When the music server starts it automatically attempts to update the index of music automatically. (Unless given the --fast command line argument).
To prevent potential issues with the indexing being started more than once it created a "lock file":
- The server looks for the file "/tmp/index.lok" and if it is present it exits
- If the lockfile is not present then it is created and the indexing begins.
- Once the indexing is complete the lockfile is removed.
The lockfile was created in the directory /tmp, which all local users can write to, in an insecure manner. This could have allowed a local user to create, or delete any file upon the system which the server had permission to modify.
In the release of version 2.9.8 the lockfile code was simply removed.