Project

General

Profile

Actions

Bug #7887

closed

User permissions do not protect firewall rules

Added by Michael Newton over 6 years ago. Updated over 6 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
Web Interface
Target version:
-
Start date:
09/21/2017
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.3.4_1
Affected Architecture:

Description

User permissions have only cosmetic effect on the firewall page, if any, and are trivially easy to bypass.

Steps to reproduce:
1. Create a user
2. Assign "WebCfg - Firewall: Rules" privilege
3. DO NOT assign "WebCfg - Firewall: Rules: Edit" privilege
4. Log in as new user, view firewall rules
5. Disable some rules, move some around
6. Right click on Save button, inspect in browser's tools and remove "disabled" attribute
7. Click Save and apply changes
8. You are an elite hacker

The failure to check for editing permissions here is kind of a big oversight.

Actions #1

Updated by Kill Bill over 6 years ago

Michael Newton wrote:

6. Right click on Save button, inspect in browser's tools and remove "disabled" attribute

Waste of time, it's no longer disabled after doing any of 5. The purpose of "disabled" is not to protect against changes but to disable the button until some changes are made (plus you cannot protect anything with javascript in the first place.)

Allow access to the 'Firewall: Rules' page means literally that, access to firewall_rules.php. You can do whatever you want there as long as it doesn't involve firewall_rules_edit.php redirect.

These "Edit" privs are not useful as a separate permission any more anywhere where you can shuffle with things via Javascript. Should be just merged.

Actions #2

Updated by Michael Newton over 6 years ago

Kill Bill wrote:

Michael Newton wrote:

6. Right click on Save button, inspect in browser's tools and remove "disabled" attribute

Waste of time, it's no longer disabled after doing any of 5. The purpose of "disabled" is not to protect against changes but to disable the button until some changes are made (plus you cannot protect anything with javascript in the first place.)

Allow access to the 'Firewall: Rules' page means literally that, access to firewall_rules.php. You can do whatever you want there as long as it doesn't involve firewall_rules_edit.php redirect.

These "Edit" privs are not useful as a separate permission any more anywhere where you can shuffle with things via Javascript. Should be just merged.

Ah I got the initial report about the "disabled" attribute from another user, and didn't look too closely at it. I'll edit the report. My point stands about being able to reorder and delete rules. From any common sense point of view, that is editing. Javascript should have no bearing on it, since the permissions (should) get checked on the server side.

Actions #3

Updated by Kill Bill over 6 years ago

Michael Newton wrote:

Javascript should have no bearing on it, since the permissions (should) get checked on the server side.

Not how it works. They are checked when you load the page. You either have access to the page or not. That's all there's to it except for special things such as "Deny config write". It really literally means what's said about that permission in User Manager. Allow access to the 'Firewall: Rules' page

Actions #4

Updated by Jim Pingle over 6 years ago

  • Status changed from New to Not a Bug
  • Priority changed from Urgent to Normal

It is working as designed. If you have permissions for a page, you can do anything on that page. The "Edit" page edits the content of rules. The main page lets you manage the rule set for an interface, including reorder, delete disable/enable, etc. That may be "editing" the rule set but it is not editing a rule.

If you want a user to not make any changes, give them the 'Deny Config Write' privilege.

In the future, please report potential security issues using proper disclosure practices outlined at https://www.pfsense.org/security/

Actions

Also available in: Atom PDF