URL:
<http://savannah.gnu.org/bugs/?38790>
Summary: Invalid "Confidentiality Pad Length" value in
encrypted RMCP+ packets
Project: GNU FreeIPMI
Submitted by: rswindell
Submitted on: Sun 21 Apr 2013 12:23:28 AM GMT
Category: libfreeipmi
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Improper Behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Operating System: None
_______________________________________________________
Details:
Example:
ipmi-dcmi -h 192.168.1.19 --set-asset-tag=123456789012345678901 -Dlan20 -I3
--debug
...
192.168.1.19: [ BYTE ARRAY ... ] = confidentiality_trailer[17B]
192.168.1.19: [ 01h 02h 03h 04h 05h 06h 07h 08h ]
192.168.1.19: [ 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh 10h ]
192.168.1.19: [ 10h ]
The last byte there is the "Confidentiality Pad Length" (10h) which should not
exceed 15 (0x0f). See IPMI 2.0 Table 13-20 for details.
This bug causes the affected packets to be rejected/ignored by
strictly-conforming IPMI 2.0 servers/BMCs.
The fix is to change the following line in ipmi-rmcpplus-interface.c:
>From this:
pad_len = IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH - ((payload_len + 1) %
IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH);
To this:
pad_len = (IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH - ((payload_len + 1) %
IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH)) &
(IPMI_CRYPT_AES_CBC_128_BLOCK_LENGTH-1);
This limits the "Confidentiality Pad Length" to the range of 0 to 15 (the
legal range). The resulting packet (in the failing cases) is now 16 byte
shorter and conforms to IPMI 2.0.
-Rob Swindell
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?38790>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Freeipmi-devel mailing list
Freeipmi-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/freeipmi-devel
