Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible
Hi Markus, On Mi 20 Mär 2019 13:36:01 CET, Markus Koschany wrote: Hi Mike, On Fri, 08 Mar 2019 22:40:52 + Mike Gabriel wrote: [...] The critical patch is CVE-2019-6111-2.patch. With that patch added I get segfaults with scp. Without that patch scp works, but is susceptible to the earlier mentioned exploit for CVE-2019-6111. I am a bit lost here and would appreciate some ideas about what is going wrong here. [...] I think I have found the root cause of the segfault. In order to fix CVE-2019-6111 we have to backport two functions, reallocarray and recallocarray. There are some conditionals which must be defined first, otherwise those functions won't be compiled and are not available at runtime. For instance ifndef HAVE_REALLOCARRAY So the solution is to define them in openbsd-compat/openbsd-compat.h #ifndef HAVE_REALLOCARRAY void *reallocarray(void *, size_t, size_t); #endif #ifndef HAVE_RECALLOCARRAY void *recallocarray(void *, size_t, size_t, size_t); #endif and in config.h.in add /* Define to 1 if you have the `reallocarray' function. */ #undef HAVE_REALLOCARRAY /* Define to 1 if you have the `recallocarray' function. */ #undef HAVE_RECALLOCARRAY After that all patches work as intended and I consider this issue to be resolved for Wheezy. I'm going to upload a new revision now. Regards, Markus Ok. I will look at your modifications and upload the same to jessie. Mike -- mike gabriel aka sunweaver (Debian Developer) mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net pgpXZW6j0Ueo_.pgp Description: Digitale PGP-Signatur
Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible
Hi Mike, On Fri, 08 Mar 2019 22:40:52 + Mike Gabriel wrote: [...] > The critical patch is CVE-2019-6111-2.patch. With that patch added I > get segfaults with scp. Without that patch scp works, but is > susceptible to the earlier mentioned exploit for CVE-2019-6111. > > I am a bit lost here and would appreciate some ideas about what is > going wrong here. [...] I think I have found the root cause of the segfault. In order to fix CVE-2019-6111 we have to backport two functions, reallocarray and recallocarray. There are some conditionals which must be defined first, otherwise those functions won't be compiled and are not available at runtime. For instance ifndef HAVE_REALLOCARRAY So the solution is to define them in openbsd-compat/openbsd-compat.h #ifndef HAVE_REALLOCARRAY void *reallocarray(void *, size_t, size_t); #endif #ifndef HAVE_RECALLOCARRAY void *recallocarray(void *, size_t, size_t, size_t); #endif and in config.h.in add /* Define to 1 if you have the `reallocarray' function. */ #undef HAVE_REALLOCARRAY /* Define to 1 if you have the `recallocarray' function. */ #undef HAVE_RECALLOCARRAY After that all patches work as intended and I consider this issue to be resolved for Wheezy. I'm going to upload a new revision now. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible
Hi again
I finally found out why I could not use xstrdup so with that fixed I run
the tests again. No crash. My guess is that the crash is some other part of
the code and not the newly introduced functions.
// Ola
On Mon, 11 Mar 2019 at 00:09, Ola Lundqvist wrote:
> Hi Mike
>
> I have had a look at this. First of all I do not think the CVE is
> completely fixed even with the additional patch. I also do not fully
> understand how 6111-2.patch is supposed to work. More about this below.
> Let us give some example commands.
>
> [1] scp host:/foobar/a* b
> [2] scp host:a* b
> [3] scp -r host /foobar/a* b
> [4] scp -r host a* b
>
> My understanding is that only case 1 is protected by 6111-1.patch
> 6111-2.patch seems to protect against case 2.
>
> But to my understanding we do not protect against 3 and 4. Am I missing
> something?
>
> Anyway I have tried to see if I could reproduce the segfault. I do not
> know fully how you have tested it so I decided to copy the new code to a
> new test.c file and test different patterns.
> The functionality as such seems to be working fine.
>
> I did one change though to make it work. I changed xstrdup to strdup
> because I could not find link against it for some reason. Could that be
> your problem too?
>
> Essentially my test.c file looks like this:
> #include
> #include
> #include
> #include
> #include
> #define fatal sprintf
>
> ... the new functions code here ...
>
> int testpattern(char* pattern) {
> char **patterns = NULL;
> size_t npatterns = 0;
> int i = 0;
> printf(" Test pattern %s \n", pattern);
> brace_expand(pattern, , );
> for (i = 0; i < npatterns; i++) {
> printf("Pattern %d: %s\n", i, patterns[i]);
> }
> }
>
> int main(int argc, char** argv) {
> testpattern("filea");
> testpattern("dira/filea");
> testpattern("dira/file{a,b}");
> testpattern("file{a,b}");
> testpattern("file*");
> testpattern("file{a,b}{c,d}");
> testpattern("file{a,b}*");
> testpattern("dir{a,b}*/d");
> testpattern("dir{a,b}/file*{a,b}*");
> }
>
> I could not reproduce the crash. How did you reproduce it?
>
> Best regards
>
> // Ola
>
>
> On Fri, 8 Mar 2019 at 23:41, Mike Gabriel wrote:
>
>> Hi Colin, hi Debian LTS team,
>>
>> On Fr 01 Mär 2019 13:24:30 CET, Colin Watson wrote:
>>
>> > And yes, it looks OK - I'll upload it to unstable shortly.
>>
>> I have prepared a backport of this newly added patch [1] (see #923486
>> for details) to openssh in Debian jessie LTS, but with that patch
>> backported to openssh in Debian jessie, I get a segmentation fault
>> whenever I copy something using the scp cmdline tool (I have of course
>> backported all other patches regarding CVE-2019-6109 and CVE-2019-6111).
>>
>> I have attached the complete .debdiff between openssh 1:6.7p1-5+deb8u7
>> (in jessie-security) and my (not-yet-)proposal for 1:6.7p1-5+deb8u8.
>>
>> The critical patch is CVE-2019-6111-2.patch. With that patch added I
>> get segfaults with scp. Without that patch scp works, but is
>> susceptible to the earlier mentioned exploit for CVE-2019-6111.
>>
>> I am a bit lost here and would appreciate some ideas about what is
>> going wrong here.
>>
>> I will only be able to continue on this on Monday, but maybe someone
>> else can offer some genuine input over the weekend. Will be much
>> appreciated.
>>
>> Thanks+Greets,
>> Mike
>>
>> [1]
>>
>> https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874
>> --
>>
>> mike gabriel aka sunweaver (Debian Developer)
>> mobile: +49 (1520) 1976 148
>> landline: +49 (4354) 8390 139
>>
>> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
>> mail: sunwea...@debian.org, http://sunweavers.net
>>
>>
>
> --
> --- Inguza Technology AB --- MSc in Information Technology
> | o...@inguza.como...@debian.org|
> | http://inguza.com/Mobile: +46 (0)70-332 1551 |
> ---
>
>
--
--- Inguza Technology AB --- MSc in Information Technology
| o...@inguza.como...@debian.org|
| http://inguza.com/Mobile: +46 (0)70-332 1551 |
---
Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible
Hi Mike
I have had a look at this. First of all I do not think the CVE is
completely fixed even with the additional patch. I also do not fully
understand how 6111-2.patch is supposed to work. More about this below.
Let us give some example commands.
[1] scp host:/foobar/a* b
[2] scp host:a* b
[3] scp -r host /foobar/a* b
[4] scp -r host a* b
My understanding is that only case 1 is protected by 6111-1.patch
6111-2.patch seems to protect against case 2.
But to my understanding we do not protect against 3 and 4. Am I missing
something?
Anyway I have tried to see if I could reproduce the segfault. I do not know
fully how you have tested it so I decided to copy the new code to a new
test.c file and test different patterns.
The functionality as such seems to be working fine.
I did one change though to make it work. I changed xstrdup to strdup
because I could not find link against it for some reason. Could that be
your problem too?
Essentially my test.c file looks like this:
#include
#include
#include
#include
#include
#define fatal sprintf
... the new functions code here ...
int testpattern(char* pattern) {
char **patterns = NULL;
size_t npatterns = 0;
int i = 0;
printf(" Test pattern %s \n", pattern);
brace_expand(pattern, , );
for (i = 0; i < npatterns; i++) {
printf("Pattern %d: %s\n", i, patterns[i]);
}
}
int main(int argc, char** argv) {
testpattern("filea");
testpattern("dira/filea");
testpattern("dira/file{a,b}");
testpattern("file{a,b}");
testpattern("file*");
testpattern("file{a,b}{c,d}");
testpattern("file{a,b}*");
testpattern("dir{a,b}*/d");
testpattern("dir{a,b}/file*{a,b}*");
}
I could not reproduce the crash. How did you reproduce it?
Best regards
// Ola
On Fri, 8 Mar 2019 at 23:41, Mike Gabriel wrote:
> Hi Colin, hi Debian LTS team,
>
> On Fr 01 Mär 2019 13:24:30 CET, Colin Watson wrote:
>
> > And yes, it looks OK - I'll upload it to unstable shortly.
>
> I have prepared a backport of this newly added patch [1] (see #923486
> for details) to openssh in Debian jessie LTS, but with that patch
> backported to openssh in Debian jessie, I get a segmentation fault
> whenever I copy something using the scp cmdline tool (I have of course
> backported all other patches regarding CVE-2019-6109 and CVE-2019-6111).
>
> I have attached the complete .debdiff between openssh 1:6.7p1-5+deb8u7
> (in jessie-security) and my (not-yet-)proposal for 1:6.7p1-5+deb8u8.
>
> The critical patch is CVE-2019-6111-2.patch. With that patch added I
> get segfaults with scp. Without that patch scp works, but is
> susceptible to the earlier mentioned exploit for CVE-2019-6111.
>
> I am a bit lost here and would appreciate some ideas about what is
> going wrong here.
>
> I will only be able to continue on this on Monday, but maybe someone
> else can offer some genuine input over the weekend. Will be much
> appreciated.
>
> Thanks+Greets,
> Mike
>
> [1]
>
> https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874
> --
>
> mike gabriel aka sunweaver (Debian Developer)
> mobile: +49 (1520) 1976 148
> landline: +49 (4354) 8390 139
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
> mail: sunwea...@debian.org, http://sunweavers.net
>
>
--
--- Inguza Technology AB --- MSc in Information Technology
| o...@inguza.como...@debian.org|
| http://inguza.com/Mobile: +46 (0)70-332 1551 |
---
Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible
Hi Colin, hi Debian LTS team,
On Fr 01 Mär 2019 13:24:30 CET, Colin Watson wrote:
And yes, it looks OK - I'll upload it to unstable shortly.
I have prepared a backport of this newly added patch [1] (see #923486
for details) to openssh in Debian jessie LTS, but with that patch
backported to openssh in Debian jessie, I get a segmentation fault
whenever I copy something using the scp cmdline tool (I have of course
backported all other patches regarding CVE-2019-6109 and CVE-2019-6111).
I have attached the complete .debdiff between openssh 1:6.7p1-5+deb8u7
(in jessie-security) and my (not-yet-)proposal for 1:6.7p1-5+deb8u8.
The critical patch is CVE-2019-6111-2.patch. With that patch added I
get segfaults with scp. Without that patch scp works, but is
susceptible to the earlier mentioned exploit for CVE-2019-6111.
I am a bit lost here and would appreciate some ideas about what is
going wrong here.
I will only be able to continue on this on Monday, but maybe someone
else can offer some genuine input over the weekend. Will be much
appreciated.
Thanks+Greets,
Mike
[1]
https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874
--
mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net
diff -Nru openssh-6.7p1/debian/changelog openssh-6.7p1/debian/changelog
--- openssh-6.7p1/debian/changelog 2018-09-12 13:23:59.0 +0200
+++ openssh-6.7p1/debian/changelog 2019-02-01 00:45:09.0 +0100
@@ -1,3 +1,16 @@
+openssh (1:6.7p1-5+deb8u8) jessie-security; urgency=medium
+
+ * Non-maintainer upload by the LTS Team.
+ * CVE-2018-20685: Disallow empty incoming filename or ones that refer
+to the current directory; based on report/patch from Harry Sintonen.
+ * CVE-2019-6109: Sanitize scp filenames via snmprintf. To do this we move
+the progressmeter formatting outside of signal handler context and have the
+atomicio callback called for EINTR, too.
+ * CVE-2019-6111: Check in scp client that filenames sent during remote->local
+directory copies satisfy the wildcard specified by the user.
+
+ -- Mike Gabriel Fri, 01 Feb 2019 00:45:09 +0100
+
openssh (1:6.7p1-5+deb8u7) jessie-security; urgency=medium
* Add debian/patches/CVE-2016-1908-3.patch: client_x11_get_proto: check if
diff -Nru openssh-6.7p1/debian/patches/CVE-2018-20685.patch
openssh-6.7p1/debian/patches/CVE-2018-20685.patch
--- openssh-6.7p1/debian/patches/CVE-2018-20685.patch 1970-01-01
01:00:00.0 +0100
+++ openssh-6.7p1/debian/patches/CVE-2018-20685.patch 2019-02-01
00:35:55.0 +0100
@@ -0,0 +1,27 @@
+From 6010c0303a422a9c5fa8860c061bf7105eb7f8b2 Mon Sep 17 00:00:00 2001
+From: "d...@openbsd.org"
+Date: Fri, 16 Nov 2018 03:03:10 +
+Subject: [PATCH] upstream: disallow empty incoming filename or ones that refer
+ to the
+
+current directory; based on report/patch from Harry Sintonen
+
+OpenBSD-Commit-ID: f27651b30eaee2df49540ab68d030865c04f6de9
+
+[sunweaver] - Ported to OpenSSH 1:6.0p1 as found in Debian wheezy (ELTS)
+---
+ scp.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/scp.c
b/scp.c
+@@ -1039,7 +1039,8 @@
+ size = size * 10 + (*cp++ - '0');
+ if (*cp++ != ' ')
+ SCREWUP("size not delimited");
+- if ((strchr(cp, '/') != NULL) || (strcmp(cp, "..") == 0)) {
++ if (*cp == '\0' || strchr(cp, '/') != NULL ||
++ strcmp(cp, ".") == 0 || strcmp(cp, "..") == 0) {
+ run_err("error: unexpected filename: %s", cp);
+ exit(1);
+ }
diff -Nru openssh-6.7p1/debian/patches/CVE-2019-6109-1.patch
openssh-6.7p1/debian/patches/CVE-2019-6109-1.patch
--- openssh-6.7p1/debian/patches/CVE-2019-6109-1.patch 1970-01-01
01:00:00.0 +0100
+++ openssh-6.7p1/debian/patches/CVE-2019-6109-1.patch 2019-01-31
17:17:12.0 +0100
@@ -0,0 +1,253 @@
+Backport of:
+
+From 8976f1c4b2721c26e878151f52bdf346dfe2d54c Mon Sep 17 00:00:00 2001
+From: "dtuc...@openbsd.org"
+Date: Wed, 23 Jan 2019 08:01:46 +
+Subject: [PATCH] upstream: Sanitize scp filenames via snmprintf. To do this we
+ move
+
+the progressmeter formatting outside of signal handler context and have the
+atomicio callback called for EINTR too. bz#2434 with contributions from djm
+and jjelen at redhat.com, ok djm@
+
+OpenBSD-Commit-ID: 1af61c1f70e4f3bd8ab140b9f1fa699481db57d8
+---
+ atomicio.c | 20 ++-
+ progressmeter.c | 53 ++---
+ progressmeter.h | 3 ++-
+ scp.c | 3 ++-
+ sftp-client.c | 18 +
+ 5 files changed, 53 insertions(+), 44 deletions(-)
+
+Index: openssh-6.6p1/atomicio.c
Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible
On Thu, Feb 28, 2019 at 11:05:37PM +0100, Salvatore Bonaccorso wrote: > Colin, but please double check if this is enough. A server which sends > an additional malicious file is blocked by that (and the patch is not > following git-dpm workflow as I'm unfamiliar with it). Cherry-picked as follows, given an up-to-date upstream remote: $ git-dpm checkout-patched Switched to a new branch 'patched' You are now in branch 'patched' $ git cherry-pick 3d896c157c722bc47adca51a58dca859225b5874 error: could not apply 3d896c157... upstream: when checking that filenames sent by the server side hint: after resolving the conflicts, mark the corrected paths hint: with 'git add ' or 'git rm ' hint: and commit the result with 'git commit' [... resolve conflicts in scp.c ...] $ git add scp.c $ git cherry-pick --continue [... in the above, edit the commit message to add DEP-3 headers ...] $ git-dpm update-patches $ dch [... add changelog entry ...] $ git commit --amend [... amends git-dpm's merge commit to include changelog entry ...] (You can combine the last three steps using "git-dpm dch". I do it this way because I normally prefer to edit debian/changelog using my normal editor.) And yes, it looks OK - I'll upload it to unstable shortly. Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible
Hi
Attached the patch and debdiff for unstable which fixes this issue.
Colin, but please double check if this is enough. A server which sends
an additional malicious file is blocked by that (and the patch is not
following git-dpm workflow as I'm unfamiliar with it).
dummy@sid:~$ scp -P foo@localhost:test.txt .
The authenticity of host '[localhost]: ([127.0.0.1]:)' can't be
established.
RSA key fingerprint is SHA256:BCYLeKMU5zuQ/Xd2Xc8sur4Mp7pQTMHcpwQkfAAmeXM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:' (RSA) to the list of known hosts.
foo@localhost's password:
test.txt 100% 32 0.7KB/s
00:00
protocol error: filename does not match request
dummy@sid:~$
Regards,
Salvatore
diff -Nru openssh-7.9p1/debian/changelog openssh-7.9p1/debian/changelog
--- openssh-7.9p1/debian/changelog 2019-02-28 20:31:49.0 +0100
+++ openssh-7.9p1/debian/changelog 2019-02-28 22:45:36.0 +0100
@@ -1,3 +1,11 @@
+openssh (1:7.9p1-8.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * When checking that filenames sent by the server side match what the client
+requested (Closes: #923486)
+
+ -- Salvatore Bonaccorso Thu, 28 Feb 2019 22:45:36 +0100
+
openssh (1:7.9p1-8) unstable; urgency=medium
[ Colin Watson ]
diff -Nru openssh-7.9p1/debian/patches/series
openssh-7.9p1/debian/patches/series
--- openssh-7.9p1/debian/patches/series 2019-02-28 11:37:30.0 +0100
+++ openssh-7.9p1/debian/patches/series 2019-02-28 22:45:36.0 +0100
@@ -30,3 +30,4 @@
check-filenames-in-scp-client.patch
fix-key-type-check.patch
request-rsa-sha2-cert-signatures.patch
+upstream-when-checking-that-filenames-sent-by-the-se.patch
diff -Nru
openssh-7.9p1/debian/patches/upstream-when-checking-that-filenames-sent-by-the-se.patch
openssh-7.9p1/debian/patches/upstream-when-checking-that-filenames-sent-by-the-se.patch
---
openssh-7.9p1/debian/patches/upstream-when-checking-that-filenames-sent-by-the-se.patch
1970-01-01 01:00:00.0 +0100
+++
openssh-7.9p1/debian/patches/upstream-when-checking-that-filenames-sent-by-the-se.patch
2019-02-28 22:45:36.0 +0100
@@ -0,0 +1,351 @@
+From: "d...@openbsd.org"
+Date: Sun, 10 Feb 2019 11:15:52 +
+Subject: upstream: when checking that filenames sent by the server side
+Origin:
https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874
+Bug-Debian: https://bugs.debian.org/923486
+
+match what the client requested, be prepared to handle shell-style brace
+alternations, e.g. "{foo,bar}".
+
+"looks good to me" millert@ + in snaps for the last week courtesy
+deraadt@
+
+OpenBSD-Commit-ID: 3b1ce7639b0b25b2248e3a30f561a548f6815f3e
+---
+ scp.c | 282 +++---
+ 1 file changed, 270 insertions(+), 12 deletions(-)
+
+diff --git a/scp.c b/scp.c
+index 96fc246cd9ba..80bc0e8b16d1 100644
+--- a/scp.c
b/scp.c
+@@ -630,6 +630,253 @@ parse_scp_uri(const char *uri, char **userp, char
**hostp, int *portp,
+ return r;
+ }
+
++/* Appends a string to an array; returns 0 on success, -1 on alloc failure */
++static int
++append(char *cp, char ***ap, size_t *np)
++{
++ char **tmp;
++
++ if ((tmp = reallocarray(*ap, *np + 1, sizeof(*tmp))) == NULL)
++ return -1;
++ tmp[(*np)] = cp;
++ (*np)++;
++ *ap = tmp;
++ return 0;
++}
++
++/*
++ * Finds the start and end of the first brace pair in the pattern.
++ * returns 0 on success or -1 for invalid patterns.
++ */
++static int
++find_brace(const char *pattern, int *startp, int *endp)
++{
++ int i;
++ int in_bracket, brace_level;
++
++ *startp = *endp = -1;
++ in_bracket = brace_level = 0;
++ for (i = 0; i < INT_MAX && *endp < 0 && pattern[i] != '\0'; i++) {
++ switch (pattern[i]) {
++ case '\\':
++ /* skip next character */
++ if (pattern[i + 1] != '\0')
++ i++;
++ break;
++ case '[':
++ in_bracket = 1;
++ break;
++ case ']':
++ in_bracket = 0;
++ break;
++ case '{':
++ if (in_bracket)
++ break;
++ if (pattern[i + 1] == '}') {
++ /* Protect a single {}, for find(1), like csh */
++ i++; /* skip */
++ break;
++ }
++ if (*startp == -1)
++ *startp = i;
++ brace_level++;
++ break;
++ case '}':
++ if (in_bracket)
++ break;
++ if (*startp < 0) {
++
Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible
Hi Salvatore, On Do 28 Feb 2019 22:43:26 CET, Salvatore Bonaccorso wrote: Hi Unchecked yet, but there was a related follow up commit upstream as per https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874 Regards, Salvatore will rebase that against my jessie version and try it out tomorrow. Thanks! Mike -- mike gabriel aka sunweaver (Debian Developer) mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: sunwea...@debian.org, http://sunweavers.net pgpVqzffjVMSH.pgp Description: Digitale PGP-Signatur
Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible
Hi Unchecked yet, but there was a related follow up commit upstream as per https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874 Regards, Salvatore
Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible
Source: openssh
Version: 1:7.9p1-7
Severity: important
Tags: security
Control: found -1 1:7.9p1-6
Control: found -1 1:7.4p1-10+deb9u5
Control: found -1 1:6.7p1-5+deb8u7
Hi,
while working on a fixed openssh version for Debian jessie LTS regarding
CVE-2019-6110
CVE-2019-6111
CVE-2018-20685
after several checks, code readings, double checking, I am pretty sure
that CVE-2019-6111 is still not yet fixed. Neither in Debian, nor
openssh upstream (though I haven't tested that, only from code
readings I assume that).
What I tested this with is this piece of Python code:
https://www.exploit-db.com/exploits/46193
In fact, the sshtranger_things.py script needs a little bit of
patching, to not throw unwanted exceptions:
```
--- sshtranger_things.py.orig 2019-02-28 21:48:41.868955825 +0100
+++ sshtranger_things.py2019-02-28 20:47:01.456096511 +0100
@@ -85,7 +85,10 @@
return paramiko.OPEN_FAILED_ADMINISTRATIVELY_PROHIBITED
def check_channel_exec_request(self, channel, command):
-command = command.decode('ascii')
+try:
+command = command.decode('ascii')
+except:
+pass
logging.info('Approving exec request: %s', command)
parts = command.split(' ')
# Make sure that this is a request to get a file:
```
Can someone please double-check this with a second pair of eyes? I
guess this needs to be communicated back to upstream. Can this be
handled by the security team and/or the package maintainers?
Thanks+Greets,
Mike
--
mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net
pgpdLn8k2CcJM.pgp
Description: Digitale PGP-Signatur
