#10 Options for sshd aren't applied

Open
opened 1 month ago by h3artbl33d · 1 comments

Description

Options set in the sshd configuration don’t seem to applu or have any effect.

Expected behaviour

Changing the sshd_config and restarting the sshd daemon should apply the changed configuration.

Actual behaviour

Changing the sshd_config and restarting the sshd daemon doesn’t apply the changed configuration.

Test setup

This issue applies to (at least) HardenedBSD v12.1-stable (FreeBSD 12.1-STABLE-HBSD (HARDENEDBSD) #0 : Sat Jun 20 17:09:01 UTC 2020) and originates at least to HardenedBSD-12-STABLE-v1200059.3 (didn’t test with older builds).

Furthermore, this issue seems specific for HardenedBSD and was confirmed to be absent in FreeBSD $host 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC amd64

Reproduce

  1. Set the following options, as an example, in /etc/ssh/sshd_config:
  PasswordAuthentication=no
  MaxAuthTries=2
  1. Restart sshd
  2. Connect with:
  ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no [system]
#### Description Options set in the `sshd` configuration don't seem to applu or have any effect. #### Expected behaviour Changing the `sshd_config` and restarting the `sshd` daemon should apply the changed configuration. #### Actual behaviour Changing the `sshd_config` and restarting the `sshd` daemon doesn't apply the changed configuration. #### Test setup This issue applies to (at least) HardenedBSD v12.1-stable (`FreeBSD 12.1-STABLE-HBSD (HARDENEDBSD) #0 : Sat Jun 20 17:09:01 UTC 2020`) and originates at least to `HardenedBSD-12-STABLE-v1200059.3` (didn't test with older builds). Furthermore, this issue seems specific for HardenedBSD and was confirmed to be absent in `FreeBSD $host 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC amd64` #### Reproduce 1. Set the following options, as an example, in `/etc/ssh/sshd_config`: ``` PasswordAuthentication=no MaxAuthTries=2 ``` 2. Restart `sshd` 3. Connect with: ``` ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no [system] ```
shawn.webb added the
bug
label 1 month ago
shawn.webb self-assigned this 1 month ago
shawn.webb commented 1 month ago
Owner

Once I finish the integration of filesystem extended attributes into pkg, I’ll take a look at this. Thanks for reporting!

Once I finish the integration of filesystem extended attributes into pkg, I'll take a look at this. Thanks for reporting!
shawn.webb referenced this issue from a commit 2 weeks ago
Assorted TSO fixes for em(4)/iflib(9) and dead code removal: - Ever since the workaround for the silicon bug of TSO4 causing MAC hangs was committed in r295133, CSUM_TSO always got disabled unconditionally by em(4) on the first invocation of em_init_locked(). However, even with that problem fixed, it turned out that for at least e. g. 82579 not all necessary TSO workarounds are in place, still causing MAC hangs even at Gigabit speed. Thus, for stable/11, TSO usage was deliberately disabled in r323292 (r323293 for stable/10) for the EM-class by default, allowing users to turn it on if it happens to work with their particular EM MAC in a Gigabit-only environment. In head, the TSO workaround for speeds other than Gigabit was lost with the conversion to iflib(9) in r311849 (possibly along with another one or two TSO workarounds). Yet at the same time, for EM-class MACs TSO4 got enabled by default again, causing device hangs. Therefore, change the default for this hardware class back to have TSO4 off, allowing users to turn it on manually if it happens to work in their environment as we do in stable/{10,11}. An alternative would be to add a whitelist of EM-class devices where TSO4 actually is reliable with the workarounds in place, but given that the advantage of TSO at Gigabit speed is rather limited - especially with the overhead of these workarounds -, that's really not worth it. [1] This change includes the addition of an isc_capabilities to struct if_softc_ctx so iflib(9) can also handle interface capabilities that shouldn't be enabled by default which is used to handle the default-off capabilities of e1000 as suggested by shurd@ and moving their handling from em_setup_interface() to em_if_attach_pre() accordingly. - Although 82543 support TSO4 in theory, the former lem(4) didn't have support for TSO4, presumably because TSO4 is even more broken in the LEM-class of MACs than the later EM ones. Still, TSO4 for LEM-class devices was enabled as part of the conversion to iflib(9) in r311849, causing device hangs. So revert back to the pre-r311849 behavior of not supporting TSO4 for LEM-class at all, which includes not creating a TSO DMA tag in iflib(9) for devices not having IFCAP_TSO4 set. [2] - In fact, the FreeBSD TCP stack can handle a TSO size of IP_MAXPACKET (65535) rather than FREEBSD_TSO_SIZE_MAX (65518). However, the TSO DMA must have a maxsize of the maximum TSO size plus the size of a VLAN header for software VLAN tagging. The iflib(9) converted em(4), thus, first correctly sets scctx->isc_tx_tso_size_max to EM_TSO_SIZE in em_if_attach_pre(), but later on overrides it with IP_MAXPACKET in em_setup_interface() (apparently, left-over from pre-iflib(9) times). So remove the later and correct iflib(9) to correctly cap the maximum TSO size reported to the stack at IP_MAXPACKET. While at it, let iflib(9) use if_sethwtsomax*(). This change includes the addition of isc_tso_max{seg,}size DMA engine constraints for the TSO DMA tag to struct if_shared_ctx and letting iflib_txsd_alloc() automatically adjust the maxsize of that tag in case IFCAP_VLAN_MTU is supported as requested by shurd@. - Move the if_setifheaderlen(9) call for adjusting the maximum Ethernet header length from {ixgbe,ixl,ixlv,ixv,em}_setup_interface() to iflib(9) so adjustment is automatically done in case IFCAP_VLAN_MTU is supported. As a consequence, this adjustment now is also done in case of bnxt(4) which missed it previously. - Move the reduction of the maximum TSO segment count reported to the stack by the number of m_pullup(9) calls (which in the worst case, can add another mbuf and, thus, the requirement for another DMA segment each) in the transmit path for performance reasons from em_setup_interface() to iflib_txsd_alloc() as these pull-ups are now done in iflib_parse_header() rather than in the no longer existing em_xmit(). Moreover, this optimization applies to all drivers using iflib(9) and not just em(4); all in-tree iflib(9) consumers still have enough room to handle full size TSO packets. Also, reduce the adjustment to the maximum number of m_pullup(9)'s now performed in iflib_parse_header(). - Prior to the conversion of em(4)/igb(4)/lem(4) and ixl(4) to iflib(9) in r311849 and r335338 respectively, these drivers didn't enable IFCAP_VLAN_HWFILTER by default due to VLAN events not being passed through by lagg(4). With iflib(9), IFCAP_VLAN_HWFILTER was turned on by default but also lagg(4) was fixed in that regard in r203548. So just remove the now redundant and defunct IFCAP_VLAN_HWFILTER handling in {em,ixl,ixlv}_setup_interface(). - Nuke other redundant IFCAP_* setting in {em,ixl,ixlv}_setup_interface() which is (more completely) already done in {em,ixl,ixlv}_if_attach_pre() now. - Remove some redundant/dead setting of scctx->isc_tx_csum_flags in em_if_attach_pre(). - Remove some IFCAP_* duplicated either directly or indirectly (e. g. via IFCAP_HWCSUM) in {EM,IGB,IXL}_CAPS. - Don't bother to fiddle with IFCAP_HWSTATS in ixgbe(4)/ixgbev(4) as iflib(9) adds that capability unconditionally. - Remove some unused macros from em(4). - Bump __FreeBSD_version as some of the above changes require the modules of drivers using iflib(9) to be recompiled. Okayed by: sbruno@ at 201806 DevSummit Transport Working Group [1] Reviewed by: sbruno (earlier version), erj PR: 219428 (part of; comment #10) [1], 220997 (part of; comment #3) [2] Differential Revision: https://reviews.freebsd.org/D15720
shawn.webb referenced this issue from a commit 2 weeks ago
HBSD: Pull in libarchive/libarchive@65a23f5dbee4497064e9bb467f81138a62b0dae1 From the commit in libarchive: ``` Fuzzing with CRCs disabled revealed that a call to get_uncompressed_data() would sometimes fail to return at least 'minimum' bytes. This can cause the crc32() invocation in header_bytes to read off into invalid memory. A specially crafted archive can use this to cause a crash. An ASAN trace is below, but ASAN is not required - an uninstrumented binary will also crash. ==7719==ERROR: AddressSanitizer: SEGV on unknown address 0x631000040000 (pc 0x7fbdb3b3ec1d bp 0x7ffe77a51310 sp 0x7ffe77a51150 T0) ==7719==The signal is caused by a READ memory access. #0 0x7fbdb3b3ec1c in crc32_z (/lib/x86_64-linux-gnu/libz.so.1+0x2c1c) #1 0x84f5eb in header_bytes (/tmp/libarchive/bsdtar+0x84f5eb) #2 0x856156 in read_Header (/tmp/libarchive/bsdtar+0x856156) #3 0x84e134 in slurp_central_directory (/tmp/libarchive/bsdtar+0x84e134) #4 0x849690 in archive_read_format_7zip_read_header (/tmp/libarchive/bsdtar+0x849690) #5 0x5713b7 in _archive_read_next_header2 (/tmp/libarchive/bsdtar+0x5713b7) #6 0x570e63 in _archive_read_next_header (/tmp/libarchive/bsdtar+0x570e63) #7 0x6f08bd in archive_read_next_header (/tmp/libarchive/bsdtar+0x6f08bd) #8 0x52373f in read_archive (/tmp/libarchive/bsdtar+0x52373f) #9 0x5257be in tar_mode_x (/tmp/libarchive/bsdtar+0x5257be) #10 0x51daeb in main (/tmp/libarchive/bsdtar+0x51daeb) #11 0x7fbdb27cab96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #12 0x41dd09 in _start (/tmp/libarchive/bsdtar+0x41dd09) This was primarly done with afl and FairFuzz. Some early corpus entries may have been generated by qsym. ``` Signed-off-by: Shawn Webb <shawn.webb@hardenedbsd.org> Sponsored-by: SoldierX
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.