Hello Derek, or anyone else affected, Accepted ufw into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ufw/0.36-6ubuntu1 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-focal. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: ufw (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags added: verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1933117 Title: ufw delete can confuse protocol-specific rule with otherwise matching 'proto any' rule Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: Fix Committed Status in ufw source package in Focal: Fix Committed Status in ufw source package in Hirsute: Fix Committed Bug description: [Impact] * The deletion of a rule without the 'proto' field that has a similar rule *with* the 'proto' field might delete the wrong rule (the latter). * This might cause services to be inaccessible or incorrectly allowed, depending on rule ordering (read original description below for examples.) [Test Steps] * Add rules: ufw allow from 1.1.1.1 port 1111 proto tcp ufw allow from 2.2.2.2 port 2222 proto tcp ufw allow from 1.1.1.1 port 1111 * Check iptables: iptables -L ufw-user-input -n ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt:1111 ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt:2222 ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt:1111 ACCEPT udp -- 1.1.1.1 0.0.0.0/0 udp spt:1111 * Delete the third rule above ufw status numbered yes | ufw delete 3 * Check iptables again: iptables -L ufw-user-input -n Observed: (deleted tcp line from first rule, and udp line from third rule) ... ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt:2222 ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt:1111 Expected: (deleted both tcp and udp lines from third rule) ... ACCEPT tcp -- 1.1.1.1 0.0.0.0/0 tcp spt:1111 ACCEPT tcp -- 2.2.2.2 0.0.0.0/0 tcp spt:2222 [Regression Potential] * Potential regressions would be observed when deleting rules. * This fix has been suggested for SRU by jdstrand [1], and has already been available in 21.04 and the snap. [1] https://code.launchpad.net/~mfo/ufw/+git/ufw/+merge/410091/comments/1083005 [Original Description] UFW versions 0.35 (on Ubuntu 16.04 LTS) and 0.36 (on Ubuntu 20.04 LTS) If a rule is inserted without specifying the protocol, it will default to both udp and tcp. If a second rule is inserted earlier in the order that specifies the protocol but is otherwise identical, UFW will delete the wrong rule if the first rule is deleted. This is repeatable with the following script: ufw insert 1 allow from 1.1.1.1/26 to any port 22 ufw insert 2 allow from 1.2.3.4/26 to any port 22 ufw insert 1 allow from 1.2.3.4/26 to any port 22 proto tcp iptables -L -n | grep -A 6 "Chain ufw-user-input" yes | ufw delete 3 iptables -L -n | grep -A 4 "Chain ufw-user-input" The output is as follows: Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22 ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22 ACCEPT udp -- 1.2.3.0/26 0.0.0.0/0 udp dpt:22 Chain ufw-user-input (1 references) target prot opt source destination ACCEPT tcp -- 1.1.1.0/26 0.0.0.0/0 tcp dpt:22 ACCEPT udp -- 1.1.1.0/26 0.0.0.0/0 udp dpt:22 ACCEPT tcp -- 1.2.3.0/26 0.0.0.0/0 tcp dpt:22 UFW deleted the first rule for 1.2.3.0 and then the last rule for 1.2.3.0, leaving the wrong rule remaining. Here is the ufw status: To Action From -- ------ ---- 22/tcp ALLOW 1.2.3.0/26 22 ALLOW 1.1.1.0/26 Mixing ALLOW and REJECT/DENY rules can further result in incorrect behavior due to this incorrect reordering. On port 22, this could render SSH remotely inaccessible. For example, if one had initially set up the following rule to port 22 (TCP and UDP)... ufw insert 1 allow from 1.2.3.4 to any port 22 ...and later wanted to further restrict it to only TCP, while explicitly rejecting any other port 22 connections... ufw insert 1 allow from 1.2.3.4 to any port 22 proto tcp ufw insert 2 reject from any to any port 22 yes | ufw delete 3 ...this would result in SSH becoming inaccessible. Instead if one had the initial configuration... ufw insert 1 reject from 1.0.0.0/8 to any port 22 ufw insert 2 allow from any to any port 22 ...which was later updated to be... ufw insert 1 reject from 1.0.0.0/8 to any port 22 proto tcp ufw insert 2 allow from any to any port 22 proto tcp yes | ufw delete 3 ...this would result in 1.0.0.0/8 incorrectly being allowed to access port 22. While this is a contrived scenario, it is possible and reproducible. A reboot is required to fix the issue, as it reloads the configuration to the expected order. To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/1933117/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
