Bug 1489013

Summary:	ssh is failing to export the display variable when configured vi /etc/sysctl.conf
Product:	Red Hat Enterprise Linux 7	Reporter:	Ajinkya Patil <ajipatil>
Component:	openssh	Assignee:	Jakub Jelen <jjelen>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.4	CC:	cww, jjelen, nmavrogi, riehecky, stepglenn, szidek
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1662189 (view as bug list)		Environment:
Last Closed:	2018-11-12 10:07:53 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1594286, 1662189

Description Ajinkya Patil 2017-09-06 15:10:39 UTC

Description of problem:
ssh is failing to export the display variable when configured vi /etc/sysctl.conf

Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1.edit /etc/sysctl.conf and add below lines:-
~~~
net.ipv6.conf.all.disable_ipv6 = 1

net.ipv6.conf.default.disable_ipv6 = 1

net.ipv6.conf.lo.disable_ipv6 = 1
~~~
2.Reboot the system
3.Take ssh acces with X11 forwarding enabled.

Actual results:
X11 forwarding request failed on channel 0

Expected results:
ssh should be able to check for available ipv4

Additional info:

Comment 2 Pat Riehecky 2017-09-06 15:15:07 UTC

See also: https://bugzilla.mindrot.org/show_bug.cgi?id=2143

Comment 3 Jakub Jelen 2017-09-20 09:27:22 UTC

As visible from the upstream bug, there is no progress except for the proposed bug from Suse. I would like to avoid introducing something different solutions than will end up being upstream (though there are not many other possibilities how it can be fixed, it it will ever be).

We discussed basically the same issue in the bug #1436097. Another discussion about the same issue is in upstream bug [1], but so far we have only workaround that needs a configuration using AddressFamily.

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=1356

Comment 4 Pat Riehecky 2017-09-20 13:12:36 UTC

That plan makes sense.  Can something be done to get the upstream bug assigned?  Currently it is assigned to no one which doesn't make progress likely.

Comment 5 Jakub Jelen 2017-09-27 13:25:32 UTC

> Can something be done to get the upstream bug assigned?  Currently it is assigned to no one which doesn't make progress likely.

No. I am not OpenSSH upstream developer so it does not make sense to assign myself to this bug. It does not look good if you try to assign somebody else from the developers either. At this point, the only hope is patience and workarounds.

Comment 6 Ajinkya Patil 2017-11-07 14:36:21 UTC

Greetings,

Do we have any update?

Comment 7 Jakub Jelen 2017-11-07 15:47:33 UTC

No, there is no update on upstream bug nor on any other related in upstream.

As I noted in the previous comment, there is no way how to make some upstream resolution from here nor I see this as a very high priority to implement it downstream with potential security implications, since we have pretty simple documented workarounds for these specific use cases.

Comment 8 Ajinkya Patil 2017-11-08 10:15:51 UTC

hello jakub,

I completely understand the situation, however one our customer needs a patch for this. They are not willing to stay with the workaround for a long time.

Comment 9 Jakub Jelen 2017-11-08 13:58:01 UTC

OK, once again I went down the the CVE-2008-1483 and tried to understand the consequences, the current fix and if the proposed fix opens this or some different security problem.

For the interested parties, the initial report about the CVE was filled in the Debian bug tracked and describes the way how to drive this attack:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463011

The problem represented in the CVE is that if we do not bind the port on IPv4 address but on IPv6 only, the attacker can have access to IPv4 one and because the DISPLAY environment variable does not list the host address family (just :10 for example), the X applications can send the data to the attacker.

I just tested the behavior with the proposed patch from upstream bug and with two Fedora 26 boxes. It works as expected, the client gets the next display and attacker can not get hold of the data as described in the Debian reproducer.

I am quite convinced that it is safe to apply this change. For some reason, upstream is not so I added one more comment to this bug if we can get some update.

If we would like to go without upstream, we would really need QE confirmation. I will try to bring it up if there will be able to move on without upstream.

Comment 10 Ajinkya Patil 2017-11-09 11:00:00 UTC

Hello Jakub,

Thank you for your efforts. I will wait for your update. Please let me know if you need any further data.