- Security: Fix double-free in server TCP listener cleanup A double-free
in the server could be triggered by an authenticated user if dropbear is
running with -a (Allow connections to forwarded ports from any host)
This could potentially allow arbitrary code execution as root by an
authenticated user.  Affects versions 2013.56 to 2016.74. Thanks to Mark
Shepard for reporting the crash.
CVE-2017-9078 https://secure.ucc.asn.au/hg/dropbear/rev/c8114a48837c

- Security: Fix information disclosure with ~/.ssh/authorized_keys
symlink.  Dropbear parsed authorized_keys as root, even if it were a
symlink.  The fix is to switch to user permissions when opening
authorized_keys

A user could symlink their ~/.ssh/authorized_keys to a root-owned file
they couldn't normally read. If they managed to get that file to contain
valid authorized_keys with command= options it might be possible to read
other contents of that file.
This information disclosure is to an already authenticated user.
Thanks to Jann Horn of Google Project Zero for reporting this.
CVE-2017-9079 https://secure.ucc.asn.au/hg/dropbear/rev/0d889b068123

Refresh patches, rework 100-pubkey_path.patch to work with new
authorized_keys validation.

Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>

Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
(cherry picked from commit 27040dbf89fb45dd9b5cc663e23bb19afc294d29)

The only HMACs currently available use MD5 and SHA1, both of which have known
weaknesses. We already compile in the SHA256 code since we use Curve25519
by default, so there's no significant size penalty to enabling this.

Signed-off-by: Joseph C. Sible <josephcsible@users.noreply.github.com>
(cherry picked from commit 0bf85ef04806e0fd5a6f78ac9f6a32aabb1e7fdc)

Signed-off-by: Felix Fietkau <nbd@nbd.name>

Replace *MD5SUM with *HASH, replace MD5 hashes with SHA256

Signed-off-by: Felix Fietkau <nbd@nbd.name>

Harmonise handling of DEFAULT_PATH by removing the patch introducing #ifndef
guards around the path, and only using one means to set the path in the
makefile.

Signed-off-by: Dario Ernst <Dario.Ernst@riverbed.com>

Configurations without shadow passwords have been broken since the removal
of telnet: as the default entry in /etc/passwd is not empty (but rather
unset), there will be no way to log onto such a system by default. As
disabling shadow passwords is not useful anyways, remove this configuration
option.

The config symbol is kept (for a while), as packages from feeds depend on
it.

Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>

As security precaution and to limit the attack surface based on
the version reported by tools like nmap mask out the dropbear
version so the version is not visible anymore by snooping on the
wire. Version is still visible by 'dropbear -V'

Based on a patch by Hans Dedecker <dedeckeh@gmail.com>

Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [remove trailing _]

Effectively the same for most purposes, but more accurate.

Signed-off-by: Karl Palsson <karlp@etactica.com>

- Security: Message printout was vulnerable to format string injection.

  If specific usernames including "%" symbols can be created on a system
  (validated by getpwnam()) then an attacker could run arbitrary code as root
  when connecting to Dropbear server.

  A dbclient user who can control username or host arguments could potentially
  run arbitrary code as the dbclient user. This could be a problem if scripts
  or webpages pass untrusted input to the dbclient program.

- Security: dropbearconvert import of OpenSSH keys could run arbitrary code as
  the local dropbearconvert user when parsing malicious key files

- Security: dbclient could run arbitrary code as the local dbclient user if
  particular -m or -c arguments are provided. This could be an issue where
  dbclient is used in scripts.

- Security: dbclient or dropbear server could expose process memory to the
  running user if compiled with DEBUG_TRACE and running with -v

  The security issues were reported by an anonymous researcher working with
  Beyond Security's SecuriTeam Secure Disclosure www.beyondsecurity.com/ssd.html

Signed-off-by: Jo-Philipp Wich <jo@mein.io>