[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnump3d-users] A few 2.7 Issues

From: koan
Subject: Re: [Gnump3d-users] A few 2.7 Issues
Date: Thu, 10 Nov 2005 09:01:54 -0500

My apologies if this is a duplicate, but after emailing you (steve) directly several times, I haven't recieved any responses so I assume the previous emails were caught by a spam filter or some such thing.

"I have found bit more specific information about the issue. Some of my orginal assumptions were a bit off.

This is how I encountered the problem initially:
GNUMP3d  w/ user authentication onf and any theme that prints the "standard header" linking to "/random/directory" in the error page.

Case to reproduce:
ACTION: Connect to the mp3d server and purposely fail the authentication
RESULT: Theme then prints template with normal header, etc and error message

ACTION: Select the "Random Directory" directory link and again purposely fail login.
RESULT: The theme then prints template with normal header, etc and error message as before, but also error.log begins to fill with messages and gnump3d process CPU usage spikes.

Further investigation revealed that even without the authentication at all, it is possible to duplicate the issue if you simply open a browser and go directly to the URL " http://zzzzzz/random/directory " where zzzz is your host/root directory.

I'm not sure about this next part, but it also appears this could be a possible DoS situation: although the system usage wasn't much of a problem for my box (Athlon XP 2500), the log file grew to over a GB in ajust a few minutes and eventually filled the entire partition. I don't have a separate /var/log partition ( yes shame on me! ) so filling the disk could have made some nice nasties had I not noticed it right away. I'm not great with perl, so I cant quite tell what safeguards you may/may not have in place for this type of thing.

Also, although I dont want to press the issue too much further after your initial reply, I would think this helps justifiy my initial concerns about printing this extra information in the cases of access control: had the header not been printed I would have never discovered this issue.


Can anyone else verify this occurs with 2.9.7 ?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]