Bug 990539

Summary: iLO2: Unable to login when password contains "
Product: Red Hat Enterprise Linux 7 Reporter: Marek Grac <mgrac>
Component: fence-agentsAssignee: Marek Grac <mgrac>
Status: CLOSED CURRENTRELEASE QA Contact: Cluster QE <mspqa-list>
Severity: high Docs Contact:
Priority: high    
Version: 7.0CC: acathrow, cluster-maint, eedri, fdinitto, gogo.ray, jharriga, jruemker, lmiksik, mbanas, mgrac, mjuricek, obasan
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: fence-agents-4.0.2-16.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 990537 Environment:
Last Closed: 2014-06-13 09:38:47 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: 990537    
Bug Blocks: 782468, 1067873    

Description Marek Grac 2013-07-31 12:18:57 UTC
+++ This bug was initially created as a clone of Bug #990537 +++

It is not possible to login to HP iLO2 when password contains characters that need to be escaped when used in XML attribute.

Unit test:
(before)

fence_ilo -o reboot -a test-ilo -z -l marx -p 'marx"marx'
Unable to connect/login to fencing device

(after)
fence_ilo -o reboot -a test-ilo -z -l marx -p 'marx"marx'

--- Additional comment from Marek Grac on 2013-07-31 08:17:36 EDT ---

Fixed in upstream:

https://git.fedorahosted.org/cgit/fence-agents.git/commit/?id=3a185569e825ee8e948a6cbef8bf847f6a7632dc

Comment 12 Marek Grac 2014-01-22 09:45:16 UTC
*) Non-encryption is not a solution because there is (or was) telnet based interface for ilo2 but it did not work correctly. If I remeber it, problem was that we had to issue power off but ilo always sent it as attempt to graceful shutdown.

@John Harrigan:

*) There is no problem with ilo3/ilo4/... because they support IPMI and that is the only supported way from us.

Comment 14 Marek Grac 2014-02-13 17:05:18 UTC
We can switch to gnutls-cli and remove nss_wrapper completely. With current version, there is no problem with communication with iLO2 (tested with RIBCL 1.22);

The required patch just change the executable and we will lose support for ilo2 & force ipv6 - what is not a problem as hw does not support it anyway.




diff --git a/fence/agents/lib/fencing.py.py b/fence/agents/lib/fencing.py.py
index fd21c69..d87618c 100644
--- a/fence/agents/lib/fencing.py.py
+++ b/fence/agents/lib/fencing.py.py
@@ -28,7 +28,7 @@ EC_INVALID_PRIVILEGES = 11
 
 TELNET_PATH = "/usr/bin/telnet"
 SSH_PATH    = "/usr/bin/ssh"
-SSL_PATH    = "@LIBEXECDIR@/fence_nss_wrapper"
+SSL_PATH    = "/usr/bin/gnutls-cli"
 SUDO_PATH   = "/usr/bin/sudo"
 
 all_opt = {
@@ -960,7 +960,7 @@ def fence_login(options, re_login_string = "(login\s*: )|(Login Name:  )|(userna
                re_pass  = re.compile("(password)|(pass phrase)", re.IGNORECASE)
 
                if options.has_key("--ssl"):
-                       command = '%s %s %s %s' % (SSL_PATH, force_ipvx, options["--ip"], options["--ipport"])
+                       command = '%s --insecure --crlf -p %s %s' % (SSL_PATH, options["--ipport"], options["--ip"])
                        try:
                                conn = fspawn(options, command)
                        except pexpect.ExceptionPexpect, ex:

Comment 15 Fabio Massimo Di Nitto 2014-02-13 18:18:11 UTC
(In reply to Marek Grac from comment #14)
> We can switch to gnutls-cli and remove nss_wrapper completely. With current
> version, there is no problem with communication with iLO2 (tested with RIBCL
> 1.22);
> 
> The required patch just change the executable and we will lose support for
> ilo2 & force ipv6 - what is not a problem as hw does not support it anyway.
> 
> 
> 
> 
> diff --git a/fence/agents/lib/fencing.py.py b/fence/agents/lib/fencing.py.py
> index fd21c69..d87618c 100644
> --- a/fence/agents/lib/fencing.py.py
> +++ b/fence/agents/lib/fencing.py.py
> @@ -28,7 +28,7 @@ EC_INVALID_PRIVILEGES = 11
>  
>  TELNET_PATH = "/usr/bin/telnet"
>  SSH_PATH    = "/usr/bin/ssh"
> -SSL_PATH    = "@LIBEXECDIR@/fence_nss_wrapper"
> +SSL_PATH    = "/usr/bin/gnutls-cli"


Makes sense to me. Can we consider dropping fence_nss_wrapper completely in favour of gnutls-cli?

Comment 16 Marek Grac 2014-02-14 12:26:55 UTC
@Fabio:

yes, we can completely drop fence_nss_wrapper then

btw: of course in final version the path won't be hard-coded :)

Comment 17 Marek Grac 2014-02-17 13:29:39 UTC
Problem is fixed in upstream:

https://git.fedorahosted.org/cgit/fence-agents.git/commit/?id=52ed50a1bd4b4bfe632bd560de27195fcea65802

nss-wrapper was completely removed in favor of gnutls-cli

Unit test:

fence_ilo -o status ...
fence_ilo -o reboot ...

Comment 23 Fabio Massimo Di Nitto 2014-02-19 18:36:14 UTC
*** Bug 875055 has been marked as a duplicate of this bug. ***

Comment 24 Fabio Massimo Di Nitto 2014-02-20 11:58:14 UTC
Unit test result related to incorrect build:

[root@rhel7-node1 ~]# grep SSL_PATH /usr/share/fence/fencing.py |head -n1
SSL_PATH    = "/usr/bin/gnutls-cli"

Unit test result related to the broken Requires:

[root@rhel7-node1 download]# rpm -U fence-agents-all-4.0.2-16.el7.x86_64.rpm fence-agents-ilo2-4.0.2-16.el7.x86_64.rpm
error: Failed dependencies:
        gnutls-utils is needed by fence-agents-ilo2-4.0.2-16.el7.x86_64
[root@rhel7-node1 download]# yum install gnutls-utils
[root@rhel7-node1 download]# rpm -U fence-agents-all-4.0.2-16.el7.x86_64.rpm fence-agents-ilo2-4.0.2-16.el7.x86_64.rpm
[root@rhel7-node1 download]#

Unit test results related to the gnutls connection to the device. Please note that a new option is required.

The problem:
gnutls > 3.x sets default negotiation protocol to TLS1.x
the device used for testing, while it claims TLS support, only works with SSL3.0

This can be verified either using RHEL6 gnutls-2.x or downgrading RHEL7 gnutls to 2.12.21-2.el7.x86_64.rpm (it will require some mocking around for libtasm.1.so.3 missing)

Default connection using gnutls-2.x on RHEL7:

[root@rhel7-node1 ~]# gnutls-cli --insecure hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com
Resolving 'hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com'...
Connecting to '10.16.64.205:443'...
- Ephemeral Diffie-Hellman parameters
 - Using prime: 1024 bits
 - Secret key: 1022 bits
 - Peer's public key: 1023 bits
- Certificate type: X.509
 - Got a certificate list of 1 certificates.
 - Certificate[0] info:
  - subject `C=US,ST=Texas,L=Houston,O=Hewlett-Packard Company,OU=ISS,CN=hp-dl585g2-01-ilo', issuer `C=US,ST=Texas,L=Houston,O=Hewlett-Packard Company,OU=ISS,CN=hp-dl585g2-01-ilo', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `2002-12-05 20:25:26 UTC', expires `2022-12-05 20:25:26 UTC', SHA-1 fingerprint `73bb4663808c363c08ea088a9e04845b40655d6d'
- The hostname in the certificate does NOT match 'hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com'
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: SSL3.0
- Key Exchange: DHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

Default connection using gnutls-3.x on RHEL7:

[root@rhel7-node1 ~]# gnutls-cli --insecure hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com
Processed 149 CA certificate(s).
Resolving 'hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com'...
Connecting to '10.16.64.205:443'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `C=US,ST=Texas,L=Houston,O=Hewlett-Packard Company,OU=ISS,CN=hp-dl585g2-01-ilo', issuer `C=US,ST=Texas,L=Houston,O=Hewlett-Packard Company,OU=ISS,CN=hp-dl585g2-01-ilo', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `2002-12-05 20:25:26 UTC', expires `2022-12-05 20:25:26 UTC', SHA-1 fingerprint `73bb4663808c363c08ea088a9e04845b40655d6d'
        Public Key Id:
                7ee167b84da6cf478dc2a2860a83bc647652bdd5
        Public key's random art:
                +--[ RSA 1024]----+
                |                 |
                |                 |
                |                 |
                |    .   .        |
                |   . . .SE..   o |
                |...   o. ..oo o .|
                |.*o. . ...+.=o   |
                |+ +o  . o. X  .  |
                | .  .. .  o.+.   |
                +-----------------+

- Status: The certificate is NOT trusted. The certificate issuer is unknown. The name in the certificate does not match the expected.
*** Verifying server certificate failed...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [20]: Bad record MAC
*** Handshake has failed
GnuTLS error: A TLS fatal alert has been received.

Forcing SSL3.0 connection on gnutls-3.x on RHEL7:

[root@rhel7-node1 ~]# gnutls-cli --priority "NORMAL:-VERS-TLS1.2:-VERS-TLS1.1:-VERS-TLS1.0:+VERS-SSL3.0" --insecure hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com

Processed 149 CA certificate(s).
Resolving 'hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com'...
Connecting to '10.16.64.205:443'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `C=US,ST=Texas,L=Houston,O=Hewlett-Packard Company,OU=ISS,CN=hp-dl585g2-01-ilo', issuer `C=US,ST=Texas,L=Houston,O=Hewlett-Packard Company,OU=ISS,CN=hp-dl585g2-01-ilo', RSA key 1024 bits, signed using RSA-MD5 (broken!), activated `2002-12-05 20:25:26 UTC', expires `2022-12-05 20:25:26 UTC', SHA-1 fingerprint `73bb4663808c363c08ea088a9e04845b40655d6d'
        Public Key Id:
                7ee167b84da6cf478dc2a2860a83bc647652bdd5
        Public key's random art:
                +--[ RSA 1024]----+
                |                 |
                |                 |
                |                 |
                |    .   .        |
                |   . . .SE..   o |
                |...   o. ..oo o .|
                |.*o. . ...+.=o   |
                |+ +o  . o. X  .  |
                | .  .. .  o.+.   |
                +-----------------+

- Status: The certificate is NOT trusted. The certificate issuer is unknown. The name in the certificate does not match the expected.
*** Verifying server certificate failed...
- Description: (SSL3.0-PKIX)-(RSA)-(AES-128-CBC)-(SHA1)
- Session ID: D1:23:75:82:B0:93:E4:5B:A5:18:8E:90:CA:4E:D3:1A:34:69:5A:17:97:8C:72:E6:8A:86:0C:BB:8B:E1:E4:13
- Version: SSL3.0
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

======================

Since TLS should always be preferred by default, we add a new config option
specific to those agents that support --ssl (cisco_ucs, ilo, ilo2, rhevm, vmware_soap) "--notls" or "-t".

Pre-patch:
[root@rhel7-node1 ~]# fence_ilo -a hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com -l tester -p testtest -o status
Unable to connect/login to fencing device

Post patch:
[root@rhel7-node1 ~]# fence_ilo -a hp-dl585g2-01-ilo.rhts.eng.bos.redhat.com -l tester -p testtest -o status -t
Status: ON

Since the device does not belong to us, I am currently unable to verify actions other than status or if the original problem with password containing " will work.

Comment 27 Martin Banas 2014-02-21 08:37:21 UTC
*** Bug 1067855 has been marked as a duplicate of this bug. ***

Comment 28 Fabio Massimo Di Nitto 2014-02-24 09:00:56 UTC
*** Bug 1068940 has been marked as a duplicate of this bug. ***

Comment 31 Ludek Smid 2014-06-13 09:38:47 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.