Vulmon
On Thu, Feb 27, 2020 at 6:24 PM Jonathan Brossard <endrazine () gmail com>
wrote:
It should be noted that this is referring to an old release from 2016 and
pointing to a repository that is an ancient snapshot of the actual project
development repository, i.e., not discussing what is in the real
development tree or recent releases.
--[ Vulnerabilities Summary:
IMHO, those claims for impact are highly questionable.
It has been discovered that hostapd before version 2.6 wasn't seeding
This is very unlikely to be hit in any realistic system using WPS. hostapd
used /dev/urandom to generate the WPS PIN if explicitly requested by upper
layer management software to enable a random PIN. The insecure random() use
would be reachable only if the device did not have a working /dev/urandom.
Furthermore, use of a random WPS AP PIN is not common deployment model (PIN
value from an upper layer software or manufacturing time configuration was
used more commonly).
Claiming this to result in remote network access is going pretty far. And
that change of removing the fallback mechanism for the broken /dev/urandom
case is a reasonable improvement in being more defensive in security
related functionality, but claiming this to be a silent fix for a
vulnerability is not accurate.
This is referring to the EAP-pwd server functionality in hostapd. The
particular value in question is the anti-clogging token value which is
defined in RFC 5931 as "MUST be unpredictable and SHOULD NOT be from a
source of random entropy" and the author of that implementation (and the
protocol designer) was explicitly documenting the used LFSR to be
sufficient for the particular use. That said, all recent releases of
hostapd are using /dev/urandom -based values for this as well.
- Jouni