| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Plus: fix the libressl patch to align with this upstream PR:
https://github.com/duosecurity/duo_unix/pull/116
|
| | |
|
| | |
|
| |
|
|
|
| |
Commit 63f5e7d295659 assigned the SPDX 3 license.
This commit refines the license to show the exact variant.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
What's different about the source at the URLs?
* New URL: Github is the raw, authoritative source URL.
* Old URL: The vendor takes the Github source,
runs './bootstrap', and posts it to their download site.
This commit makes the build process more transparent.
Why change the URL now?
The vendor has tagged a new version of duo_unix on github but
has not yet made the new version available at their official
download site.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit updates $license variable in all APKBUILDs to comply with
short names specified by SPDX version 3.0 [1] where possible. It was
done using find-and-replace method on substrings inside $license
variables.
Only license names were updated, not "expressions" specifying relation
between the licenses (e.g. "X and Y", "X or Y", "X and (Y or Z)") or
exceptions (e.g. "X with exceptions").
Many licenses have a version or multiple variants, e.g. MPL-2.0,
BSD-2-Clause, BSD-3-Clause. However, $license in many aports do not
contain license version or variant. Since there's no way how to infer
this information just from abuild, it were left without the variant
suffix or version, i.e. non SPDX compliant.
GNU licenses (AGPL, GFDL, GPL, LGPL) are especially complicated. They
exist in two variants: -only (formerly e.g. GPL-2.0) and -or-later
(formerly e.g. GPL-2.0+). We did not systematically noted distinguish
between these variants, so GPL-2.0, GPL2, GPLv2 etc. may mean
GPL-2.0-only or GPL-2.0-or-later. Thus GNU licenses without "+" (e.g.
GPL2+) were left without the variant suffix, i.e. non SPDX compliant.
Note: This commit just fixes format of the license names, no
verification has been done if the specified license information is
actually correct!
[1]: https://spdx.org/licenses/
|
| | |
|
| | |
|
| |
|
|
|
| |
Remove libressl patch because it's in upstream duo_unix as of
https://github.com/duosecurity/duo_unix/commit/c539ba7aa3ec064
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Duo Product Security Advisory
=============================
Advisory ID: DUO-PSA-2017-002
Publication Date: 2017-05-31
Revision Date: 2017-05-31
Status: Confirmed, Fixed
Document Revision: 1
Overview
--------
Duo Security has identified an issue in duo_unix, which, under
certain uncommon configurations, could enable attackers to bypass
second-factor user authentication. Duo has no evidence that this
vulnerability has actively been exploited and we believe this
specific configuration is extraordinarily uncommon.
This issue was resolved in version 1.9.21 of duo_unix. Customers
using an affected configuration should update to the latest
version as soon as possible (see "Solution" section below).
Description
-----------
Prior to version 1.9.21, duo_unix (which includes both login_duo
and pam_duo), supported setting an HTTP proxy configuration
through the standard 'http_proxy' environment variable. Under some
uncommon configurations (examples listed below), however, it is
possible for an untrusted user to set a value for the 'http_proxy'
variable prior to initiating a Duo authentication attempt.
If an invalid proxy host (e.g. '0.0.0.0') is selected, then
login_duo/pam_duo will ultimately fail to connect to Duo's API,
and as a result, trigger the configured "failmode" behavior. If
"failmode" is set to "safe" (which is the default), then this
could result in a bypass of second-factor authentication.
Duo has identified two specific configuration scenarios in which an
untrusted user may be able to control the value of the 'http_proxy'
environment variable.
1. login_duo with nonstandard sshd "AcceptEnv" configurations:
OpenSSH can permit clients to forward environment variables
to servers. By default, OpenSSH server distributions generally
allow only a whitelisted set of variables (which does not include
'http_proxy') to be forwarded in this way. It is possible, however,
for an administrator to configure a less-restrictive policy using
the AcceptEnv keyword in sshd_config.
If a server has been configured with a non-default AcceptEnv
policy that permits clients to send an 'http_proxy' environment
variable, and is using login_duo to add Duo 2FA to ssh logins,
then this configuration could result in a bypass of Duo 2FA.
This scenario only applies to login_duo; when used with OpenSSH,
pam_duo is unaffected by this issue.
2. pam_duo with local authentication (e.g. su / sudo):
While pam_duo is not affected by this issue when used with OpenSSH,
when pam_duo is being used to perform 2FA in other contexts -
particularly, to authenticate system-local actions performed
by untrusted users - it may be possible for untrusted users to
control the value of the 'http_proxy' environment variable prior
to initiating an authentication attempt.
In particular, Duo has confirmed that configurations which use
pam_duo to add Duo 2FA to the "su" and "sudo" commands are impacted
by this issue.
Version 1.9.21 of duo_unix has been released to resolve this
issue. It removes support for configuring an HTTP Proxy via an
environment variable.
Impact
------
Attackers may be able to bypass second-factor authentication
on impacted configurations which accept attacker-controlled
environment variables.
Affected Product(s)
-------------------
All versions of duo_unix prior to 1.9.21 are impacted when used
in one of the following configuration scenarios:
* login_duo is performing 2FA for SSH logins, and
sshd has been configured with a permissive (non-default) AcceptEnv policy
* pam_duo is performing 2FA for scenarios other than SSH logins
Workaround
----------
Customers using login_duo in an affected configuration may work
around this issue by ensuring that their AcceptEnv configuration
for sshd (e.g. in /etc/ssh/sshd_config) does not permit clients
to send an 'http_proxy' variable.
Customers using pam_duo in an affected configuration must upgrade
to the latest version of duo_unix.
Solution
--------
Customers should upgrade to the latest version of the duo_unix
client as discussed above. Clone the latest version from:
* https://github.com/duosecurity/duo_unix
For more information on upgrading duo_unix,
see https://duo.com/docs/duounix
Vulnerability Metrics
---------------------
Vulnerability Class: CWE-454: External Initialization of Trusted Variables or Data Stores
https://cwe.mitre.org/data/definitions/454.html
Remotely Exploitable: [No]
Authentication Required: [Partial]
Severity: [High]
CVSSv2 Overall Score: 5.0
CVSSv2 Group Scores: Base: 6.0, Temporal: 5.0
CVSSv2 Vector: AV:L/AC:M/Au:S/C:P/I:P/A:N/E:F/RL:OF/RC:C
References
----------
* CWE-454: External Initialization of Trusted Variables or Data Stores - https://cwe.mitre.org/data/definitions/454.html
* Duo Unix Reference - https://duo.com/docs/duounix
Timeline
--------
2017-05-19
* Duo privately receives report of a security vulnerability in Duo Unix
* Duo acknowledges receipt of report and begins investigation
2017-05-22
* Duo confirms vulnerability exists in related case to original report
2017-05-30
* Duo completes development and testing of fixes
2017-05-31
* Advisory released to all Duo customers using duo_unix
Credits/Contact
---------------
Technical questions regarding this issue should be sent to
support@duosecurity.com and reference "DUO-PSA-2017-002" in the
subject, or to your Customer Success Manager, if appropriate.
Duo Security would like to thank Fred Emmott for reporting this issue.
|
| | |
|
| | |
|
| |
|
|
| |
let abuild pull in the needed libraries
|
| | |
|
| | |
|
| |
|
