Project

General

Profile

Actions

Bug #6119

closed

Alias entry causes filterdns core dumps

Added by B. Derman almost 8 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Rules / NAT
Target version:
-
Start date:
04/12/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:
amd64

Description

The following is with pfSense 2.2.6 release AMD64 on a Core 2 Duo 3 GHz dual-core with 4 GB ram.
---
While creating an alias containing multiple networks, I used copy/paste and (unthinkingly) pasted 18 of the 22 entries as #.#.#.0/24:

- the first issue is that these were all accepted without warning

- the second issue is that, apparently upon saving the alias definition, these were not created as though I'd selected "24" via the "CIDR" popup menu (which would have made the first issue a feature, not an issue) ... but each /24 entry was expanded to the 256 IPs as though I'd made the separate 256 entries for each

- the third issue is that, once the alias was used in a rule and the alias' table was to be created, the filterdns process was failing:

+ pfSense fails with a "direct" alias definition with 4,612 entries (i.e., not using a URL/file-based alias)
+ during every "reload," filterdns would (seemingly, by watching top) slowly (5-15 minutes) grow in size then core-dump when it reached around 400 MB "RES"
+ during the "reload," the router is effectively "dead" (i.e., seemingly all traffic, including web-configurator, is blocked)
+ the long-lived all-blocking behavior of this issue makes troubleshooting and repair very difficult ... well, very slow, at least

- the fourth issue -- a very serious one -- is that the failure of filterdns caused multiple tables to still be listed as present, but to have no contents (at a quick glance, it appears this is for any alias table that has one or more FQDN entry)

This is a serious issue because the creation of empty tables causes loss of both functionality and security. In fact, we had one device modified due to the inherent loss of security this failure caused.

(I selected "All" for affected version since you don't have 2.2.6 as an available selection.)

Actions #1

Updated by Chris Buechler almost 8 years ago

  • Status changed from New to Feedback

please re-test on 2.3, a lot of validation improvements there into aliases and some relevant filterdns changes.

Actions #2

Updated by Jim Thompson over 7 years ago

  • Assignee set to Jim Pingle

Please retest on 2.3. Close if possible. Let me know if it's still an issue

Actions #3

Updated by Jim Pingle over 7 years ago

  • Status changed from Feedback to Closed
  • Assignee deleted (Jim Pingle)
  • Priority changed from High to Normal

While creating an alias containing multiple networks, I used copy/paste and (unthinkingly) pasted 18 of the 22 entries as #.#.#.0/24:

- the first issue is that these were all accepted without warning
- the second issue is that, apparently upon saving the alias definition, these were not created as though I'd selected "24" via the "CIDR" popup menu (which would have made the first issue a feature, not an issue) ... but each /24 entry was expanded to the 256 IPs as though I'd made the separate 256 entries for each

That is a feature, being able to use ranges and subnets to expand. It's not just meant to be used on that scale. If you're copying and pasting in networks and hosts, use the import feature, which is more prominently displayed on 2.3 on the main aliases page. It was on 2.2.x and earlier but was harder to see (a little up arrow at the bottom)

Input validation prevents it from running too far on 2.3, it will fail to expand once it reaches 5000 entries.

- the third issue is that, once the alias was used in a rule and the alias' table was to be created, the filterdns process was failing:

+ pfSense fails with a "direct" alias definition with 4,612 entries (i.e., not using a URL/file-based alias)

On 2.3, input validation stops this at 5000 entries, which does work provided the browser/client doesn't crash when handling that large of a form.

+ during every "reload," filterdns would (seemingly, by watching top) slowly (5-15 minutes) grow in size then core-dump when it reached around 400 MB "RES"
+ during the "reload," the router is effectively "dead" (i.e., seemingly all traffic, including web-configurator, is blocked)
+ the long-lived all-blocking behavior of this issue makes troubleshooting and repair very difficult ... well, very slow, at least

I can't reproduce any similar problems with filterdns on 2.3, possibly because part of the original conditions could not be replicated.

- the fourth issue -- a very serious one -- is that the failure of filterdns caused multiple tables to still be listed as present, but to have no contents (at a quick glance, it appears this is for any alias table that has one or more FQDN entry)

This is a serious issue because the creation of empty tables causes loss of both functionality and security. In fact, we had one device modified due to the inherent loss of security this failure caused.

Something like that could only happen if you were relying on selective blocking rules before general pass rules. A blank table doesn't match all/any, it matches nothing. So it would simply not match the affected rule and continue on down the ruleset. No issue there except the design of the ruleset.

There doesn't appear to be anything here that's a problem with our current code.

Actions

Also available in: Atom PDF