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

Closed
mschop opened this Issue May 6, 2018 · 23 comments

Comments

Projects
None yet
5 participants
@mschop
Copy link

mschop commented May 6, 2018

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

@rob-lindman

This comment has been minimized.

Copy link

rob-lindman commented May 7, 2018

can you provide details of the cron job?

@gabbo2

This comment has been minimized.

Copy link

gabbo2 commented May 7, 2018

Add logfile to logrotate..

@mschop

This comment has been minimized.

Copy link
Author

mschop commented May 7, 2018

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

@timint

This comment has been minimized.

Copy link
Collaborator

timint commented May 7, 2018

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?

@timint

This comment has been minimized.

Copy link
Collaborator

timint commented May 7, 2018

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

$lines = is_file($not_found_file) ? file($not_found_file, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES) : array();
$lines[] = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
$lines = array_unique($lines);

Repalce with

$lines = is_file($not_found_file) ? file($not_found_file, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES) : array();

if (count($lines) >= 500) {
  $email = new email();
  $email->set_subject('[Not Found Report] '. settings::get('store_name'))
        ->add_body(PLATFORM_NAME .' '. PLATFORM_VERSION ."\r\n\r\n". implode("\r\n", $lines))
        ->send();
  $lines = array();
}

$lines[] = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
$lines = array_unique($lines);
@rob-lindman

This comment has been minimized.

Copy link

rob-lindman commented May 7, 2018

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.

@mschop

This comment has been minimized.

Copy link
Author

mschop commented May 7, 2018

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.

@rob-lindman

This comment has been minimized.

Copy link

rob-lindman commented May 7, 2018

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.

@mschop

This comment has been minimized.

Copy link
Author

mschop commented May 7, 2018

@rob-lindman do you have a server log entry for this 500?

@rob-lindman

This comment has been minimized.

Copy link

rob-lindman commented May 7, 2018

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:

    file_put_contents($not_found_file, implode(PHP_EOL, $lines) . PHP_EOL);

@mschop

This comment has been minimized.

Copy link
Author

mschop commented May 9, 2018

CVE-2018-10827

@rob-lindman

This comment has been minimized.

Copy link

rob-lindman commented May 9, 2018

what are these numbers supposed to refer to?

@paulgurney

This comment has been minimized.

Copy link

paulgurney commented May 9, 2018

Hi Rob,
MSCHOP made a "common vulnerability" report, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10827

@timint

This comment has been minimized.

Copy link
Collaborator

timint commented May 10, 2018

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?

@rob-lindman

This comment has been minimized.

Copy link

rob-lindman commented May 10, 2018

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.

@paulgurney

This comment has been minimized.

Copy link

paulgurney commented May 10, 2018

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
I think he knows better...

@mschop

This comment has been minimized.

Copy link
Author

mschop commented May 10, 2018

@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.

@timint

This comment has been minimized.

Copy link
Collaborator

timint commented May 10, 2018

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.

litecart pushed a commit that referenced this issue May 10, 2018

@timint

This comment has been minimized.

Copy link
Collaborator

timint commented May 10, 2018

@mschop You flagged the wrong version, 2.1.2 is not released yet.
The vulnerable versions are 2.1 and 2.1.1.
2.1.2 will be the version holding the fix.

@rob-lindman

This comment has been minimized.

Copy link

rob-lindman commented May 10, 2018

@mschop TiM was right. While he might not have been super professional, he was accurate. And made me laugh.

  1. You found a potential problem which thus far has affected no one, except for you, and may not affect anyone, ever. I don't know how many times you'd have to 404 a website to fill a modern hard drive, but I'd say it's a lot. You could do the math, I'm not going to bother with that.

  2. You made a big deal out of it. While the information is useful, if it's a security concern, 'professional' would have been to keep it on the down low and contact the vendor through private channels, as recommended. Seeing as how you KNOW that, your motives are nebulous for the activity.

  3. You went out of your way to broadcast it beyond the community for the product. As pointed out, this increases the likelihood that it could be exploited (though pretty unlikely, and this would be a lame DOS attack). Seeing as how you KNOW that, your motives are nebulous for the activity.

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.

@mschop

This comment has been minimized.

Copy link
Author

mschop commented May 10, 2018

@timint
Sorry for the version mistake. I send a update request to mitre.org but it may take a day until this is updated.

@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? .

@timint

This comment has been minimized.

Copy link
Collaborator

timint commented May 10, 2018

@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.

@rob-lindman

This comment has been minimized.

Copy link

rob-lindman commented May 11, 2018

I will look forward to a patch for this and any other 'vulnerabilities' in the future.

@timint timint closed this May 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment