RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1489013 - ssh is failing to export the display variable when configured vi /etc/sysctl.conf
Summary: ssh is failing to export the display variable when configured vi /etc/sysctl....
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssh
Version: 7.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1594286 1662189
TreeView+ depends on / blocked
 
Reported: 2017-09-06 15:10 UTC by Ajinkya Patil
Modified: 2023-12-15 15:57 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1662189 (view as bug list)
Environment:
Last Closed: 2018-11-12 10:07:53 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenSSH Project 1356 0 None None None 2018-12-26 22:31:56 UTC

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.
Note You need to log in before you can comment on or make changes to this bug.