Unable to connect to a hiddne network iwctl ===== [iwd]# station wlan0 connect-hidden "Hidden-network" Type the network passphrase for Hidden-network psk. Passphrase: ************************ Message recipient disconnected from message bus without replying iwd -d output ============= src/station.c:__station_connect_network() connecting to BSS <MAC-ADDRESS> src/station.c:station_enter_state() Old State: autoconnect_full, new state: connecting src/scan.c:scan_periodic_stop() Stopping periodic scan for wdev c src/scan.c:scan_cancel() Trying to cancel scan id 14 for wdev c src/netdev.c:netdev_mlme_notify() MLME notification New Station(19) src/station.c:station_netdev_event() Associating src/netdev.c:netdev_mlme_notify() MLME notification Authenticate(37) src/netdev.c:netdev_authenticate_event() src/netdev.c:netdev_unicast_notify() Unicast notification 129 src/netdev.c:netdev_control_port_frame_event() src/netdev.c:netdev_mlme_notify() MLME notification Associate(38) src/netdev.c:netdev_associate_event() src/netdev.c:netdev_link_notify() event 16 on ifindex 9 src/netdev.c:netdev_mlme_notify() MLME notification Connect(46) src/netdev.c:netdev_connect_event() src/eapol.c:eapol_handle_ptk_1_of_4() ifindex=9 4-Way handshake failed for ifindex: 9, reason: 1 src/wiphy.c:wiphy_radio_work_done() Work item 15 done free(): double free detected in tcache 2
same for 1.19, 1.20 **9999? Is upstream aware? I could not see a fix in https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/ChangeLog
> same for 1.19, 1.20 **9999? Same for 1.19 and 1.20. The **9999 can't be installed. Log ---------- Failed to emerge net-wireless/iwd-9999, Log file: >>> '/var/tmp/portage/net-wireless/iwd-9999/temp/build.log' * Messages for package net-wireless/iwd-9999: * REGULATORY DOMAIN PROBLEM: please enable CFG80211_CRDA_SUPPORT for proper regulatory domain support * Please check to make sure these options are set correctly. * Failure to do so may cause unexpected problems. * ERROR: net-wireless/iwd-9999::gentoo failed (unpack phase): * Unable to fetch from any of EGIT_REPO_URI * * Call stack: * ebuild.sh, line 127: Called src_unpack * environment, line 3320: Called git-r3_src_unpack * environment, line 2595: Called git-r3_src_fetch * environment, line 2589: Called git-r3_fetch * environment, line 2511: Called die * The specific snippet of code: * [[ -n ${success} ]] || die "Unable to fetch from any of EGIT_REPO_URI"; ---------- My kernel config CFG80211_CRDA_SUPPORT: n ===================== You should enable this option unless you know for sure you have no it, for example when using the regulatory database loaded as a firmware file. CONFIG_EXTRA_FIRMWARE: y ===================== ... iwlwifi-7265D-29.ucode regulatory.db regulatory.db.p7s ... > Is upstream aware? I don't know, because I did not know who was the main maintenance or the owner ... upstream. Now I know. Who should report the bug in the upstream? I'm worried about iwd. I like it because it's user friendly, but it isn't safe. wpa_supplicant with wpa_priv is more secure than iwd. In addition iwctl is accessible by any non-root user. Furthermore, seeing this absurd "double free" bug takes away a lot of reliability from the tool. At least if it had been developed in Rust, this would not have happened.
(In reply to Vasile M. from comment #2) > > same for 1.19, 1.20 **9999? > > Same for 1.19 and 1.20. The **9999 can't be installed. > > Log > ---------- > > Failed to emerge net-wireless/iwd-9999, Log file: > > >>> '/var/tmp/portage/net-wireless/iwd-9999/temp/build.log' > > * Messages for package net-wireless/iwd-9999: > > * REGULATORY DOMAIN PROBLEM: please enable CFG80211_CRDA_SUPPORT for > proper regulatory domain support > * Please check to make sure these options are set correctly. > * Failure to do so may cause unexpected problems. > * ERROR: net-wireless/iwd-9999::gentoo failed (unpack phase): > * Unable to fetch from any of EGIT_REPO_URI > * > * Call stack: > * ebuild.sh, line 127: Called src_unpack > * environment, line 3320: Called git-r3_src_unpack > * environment, line 2595: Called git-r3_src_fetch > * environment, line 2589: Called git-r3_fetch > * environment, line 2511: Called die > * The specific snippet of code: > * [[ -n ${success} ]] || die "Unable to fetch from any of > EGIT_REPO_URI"; > > > ---------- > > My kernel config > > CFG80211_CRDA_SUPPORT: n > ===================== > You should enable this option unless you know for sure you have no > it, for example when using the regulatory database loaded as > a firmware file. > > CONFIG_EXTRA_FIRMWARE: y > ===================== > ... iwlwifi-7265D-29.ucode regulatory.db regulatory.db.p7s ... > > > > Is upstream aware? > > I don't know, because I did not know who was the main maintenance or the > owner ... upstream. > Now I know. Who should report the bug in the upstream? You found it and you ostensibly know how to trigger it. You're the best person to report it. > I'm worried about iwd. I like it because it's user friendly, but it isn't > safe. > > wpa_supplicant with wpa_priv is more secure than iwd. In addition iwctl is > accessible by any non-root user. What leads you to believe this has any more impact than a DoS? > Furthermore, seeing this absurd "double free" bug takes away a lot of > reliability from the tool. At least if it had been developed in Rust, this > would not have happened. Rust can crash too. Is this issue reproducible? I'm able to connect to hidden PSK networks with IWD, so not sure what your issue is.
Upstream reported bug: https://bugzilla.kernel.org/show_bug.cgi?id=215377 ---------- > What leads you to believe this has any more impact than a DoS? The DoS attack is the least important in this scenario. Privacy ======= If any console user can access iwd, this is a high leak of privacy: anyone can see saved networks, scan for nearby wifi networks and give your location. 'any' can be: third-party vim plugins (for example belongs to coc-nvim), third party software and plugins like Android Studio, etc. For now there is no one who performs this type of practice (like Google on Android), but you should not trust anyone in terms of privacy and security. Otherwise, the passwords would not exist. To temporarily fix this, you have to go to solutions other than iwd. For example, limit user access by creating rules in '/etc/dbus-1/system.d/'. Note: This doesn't exists on the Gentoo wiki and iwd man pages. Security ======== A well known bug that allow remote code execution without the user interaction is CVE-2021-0326. (In p2p.c, the p2p_copy_client_info does not check bounds while wifi direct is searching for peers). Important: This bug is an example, does not affect iwd at all. Imagine that in the future anyone will find a similar bug in iwd. If iwd is run as root, the attacker has full privileges on the system. This is the same as before: do you have to trust that no one will do bad things or that the iwd tool is safe enough? If it were true, the passwords would not exist. Again, To temporarily fix this, you have to go to solutions other than iwd. For example, sandboxing the iwd, giving phy/dev device permissions to a regular user using udev rules, etc. wpa_supplicant already does privilege separation. ---------- Note: The 'double free' bug appears when connecting to a network. Not strictly related to hidden networks. (I can't check it now, but I'm pretty sure). If it works for you, it's probably because of my kernel configuration. But it shouldn't because I've followed the gentoo wiki instructions (iwd).
(In reply to Vasile M. from comment #4) > Upstream reported bug: > https://bugzilla.kernel.org/show_bug.cgi?id=215377 > > ---------- > > > What leads you to believe this has any more impact than a DoS? > > The DoS attack is the least important in this scenario. So is this bug about a double free or insecure defaults?
(In reply to John Helmert III from comment #5) > So is this bug about a double free or insecure defaults? Excuse the misunderstanding that I have caused. This bug is about the double free.
This looks abandoned. The upstream says nothing. https://bugzilla.kernel.org/process_bug.cgi
(In reply to Vasile M. from comment #7) > This looks abandoned. The upstream says nothing. > > https://bugzilla.kernel.org/process_bug.cgi You've not really made the security issue clear, and probably doesn't help that you linked a private bug. In any case, this seems like a denial of service at most, which seems only triggerable by the "victim", when connected to a trusted network. The privilege separation complaint that you have would seem to be deliberate, and well known. As such, I think this security bug is invalid. Making public again as this is public elsewhere.
