New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DOS-Vulnerability through not_found.log #119
Comments
|
can you provide details of the cron job? |
|
Add logfile to logrotate.. |
|
Logrotate doesn't really help. That would only help, if you rotate e.g. every 10 Minutes. But rotating so often doesn't really make sense. I would just truncate the file through a cron every 10 Minutes. echo "" > /pathtowebroot/logs/not_found.log |
|
I'm not sure how Apache does it in error_log and access_log. I've seen access logs that are in the size of GBytes. How about only storing the last 500 rows or something like that? Or dumping the log over email once it reaches a certain size or amount? |
|
We can't rely of logrotate as everyone might not have access to use it on their machines. Here is how to dump it when it reaches 500 rows. In ~/index.php Find Repalce with |
|
Perhaps the developer will have a better answer. Apache already logs 404 codes, so I am not sure if this log is needed at all. |
|
The not_found.log makes sense, if you need to display unfound links to non technical persons in the shop backend. Otherwise it's superflous (server logs). If there is no functionality to display the log in the backend, this function can be completely removed. If it should be displayed to a customer, the logs should be stored in the MySQL-Database, because you then can store a much greater amount of entries without having a dos vulnerability. The database approach is much more flexible. E.g. if one needs to filter for a specific url. |
|
T.Almaroth, I implemented this, but it caused a 500 error in my shop, so I removed it. Don't really have time at the moment to see what the issue is with the addition. |
|
@rob-lindman do you have a server log entry for this 500? |
|
As I said, I don't have time at the moment to see what the problem is with the above code. I think that one could just comment out this line for now in the index.php while TiM works out a solution: |
|
what are these numbers supposed to refer to? |
|
Hi Rob, |
|
Ok who is being a dickhead? First of all a report of a vulnerability is very much appreciated. But.. You don't go posting it in a public forum or issue tracker. You send it silently over a secure private channel. And you don't go posting a CVE and provide instructions how to exploit it until the author has released a fix. Do I need to explain why or does it make good sense? |
|
TiM makes my day yet again! I agree with the sentiment he's expressed... and also... this is not a serious vulnerability. Telling mom about it isn't going to save the world. |
|
I agree with TiM, too... there is a proper way to do this kind of reporting. my guess was that @mschop didn't know better, or did it for self-serving reasons. EDIT: see this: projectsend/projectsend#547 |
|
@timint I would recommend you to be more professional. Just create a hotfix for the issue instead of insulting me here. The problem is not critical and super easy to fix. To be honest, I expected that you would publish a fix version within few days. Furthermore I added a suggestion, how shop owner can protect against this vulnerability until you publish a fix. I'm aware of the normal process but decided against it in this case for the previous reasons. If it was a XSS, CSRF or Injection e.g. I would have sent it through a private channel. |
|
Many users do not even possess knowledge how to FTP upload files. So a hotfix will only benefit few. I'm already working on wrapping up a new version release where this fix will be included. But it will be a few days until it is rolled out through the Softaculous update channel and all. |
|
@mschop You flagged the wrong version, 2.1.2 is not released yet. |
|
@mschop TiM was right. While he might not have been super professional, he was accurate. And made me laugh.
Anyway, I got a chuckle out of it. I'll be happy to see and apply a fix for this. Try not to freak out. |
|
@timint @rob-lindman / @timint Let's make it short: I think we should end the discussion. I think we can all spend our time productive instead (e.g. fining more vulnerabilities). I will use the private communication way to prevent such discussions in future. By the way: I have to verify this first, but it could be that I found another vulnerability. Do you have a GPG public key and according email address for contacting you (@timint) securely in future? . |
|
@mschop I don't have any current GPG setup in my mail client. As we are not dealing with nukes I think it's safe just to take it over a private channel. On Skype I am tim-international. |
|
I will look forward to a patch for this and any other 'vulnerabilities' in the future. |
Hi,
I found a DOS-Vulnerability in litecart. If an attacker sends random URL's to LiteCart, those URLs (if unique) are saved to the file logs/note_found.log. Unfortunatly this file is fully loaded to RAM if a not existing URL is called.
By sending a large number of invalid request to litecart, the file size can be increased infinite. Then every call to litecart, that has an invalid url takes the full available memory and causes a lot of IO.
Recommendations
The entries should be logged to dababase. An upsert command can be used to create or update the entries in the db.
How can you protect your system, until a bugfix is published?
E.g. create a cron that empties the not_found.log file.
Best Regards
mschop
The text was updated successfully, but these errors were encountered: