freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Freeipmi-devel] [bug #38790] Invalid "Confidentiality Pad Length" value


From: Rob Swindell
Subject: [Freeipmi-devel] [bug #38790] Invalid "Confidentiality Pad Length" value in encrypted RMCP+ packets
Date: Sun, 21 Apr 2013 00:23:29 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]