Skip to contentSkip to conversation

dropbear: security bump to version 2017.75

PATCH New Peter Korsgaard 1 participant 3 messages May 20, 2017 – Jun 1, 2017

lore
Share & tools
lore

Peter Korsgaard

author
#0 lore raw

PATCH 1/1 dropbear: security bump to version 2017.75

Fixes:

- CVE-2017-9078: 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-9079: 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.

Signed-off-by Peter Korsgaard <[email protected]>
---
 package/dropbear/dropbear.hash | 2 +-
 package/dropbear/dropbear.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
package/dropbear/dropbear.hash +1 -1
index 88f3e6ed5..98776e717 100644
@@ -1,2 +1,2 @@
 # From https://matt.ucc.asn.au/dropbear/releases/SHA256SUM.asc
-sha256 2720ea54ed009af812701bcc290a2a601d5c107d12993e5d92c0f5f81f718891 dropbear-2016.74.tar.bz2
+sha256 6cbc1dcb1c9709d226dff669e5604172a18cf5dbf9a201474d5618ae4465098c dropbear-2017.75.tar.bz2
package/dropbear/dropbear.mk +1 -1
index a4e227215..bf7f99d97 100644
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-DROPBEAR_VERSION = 2016.74
+DROPBEAR_VERSION = 2017.75
 DROPBEAR_SITE = http://matt.ucc.asn.au/dropbear/releases
 DROPBEAR_SOURCE = dropbear-$(DROPBEAR_VERSION).tar.bz2
 DROPBEAR_LICENSE = MIT, BSD-2-Clause-like, BSD-2-Clause
Signature · 1 line
2.11.0
author
#1 lore raw

PATCH 1/1 dropbear: security bump to version 2017.75

Quoted 19 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Peter" == Peter Korsgaard <[email protected]> writes:

Fixes:
- CVE-2017-9078: 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-9079: 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.

Quoted 1 line
Signed-off-by Peter Korsgaard <[email protected]>

Committed, thanks.

Signature · 1 line
Bye, Peter Korsgaard
author
#2 lore raw

PATCH 1/1 dropbear: security bump to version 2017.75

In reply to Peter Korsgaard
Quoted 19 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Peter" == Peter Korsgaard <[email protected]> writes:

Fixes:
- CVE-2017-9078: 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-9079: 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.

Quoted 1 line
Signed-off-by Peter Korsgaard <[email protected]>

Committed to 2017.02.x, thanks.

Signature · 1 line
Bye, Peter Korsgaard