public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: marcandre.lureau@redhat.com
To: edk2-devel@lists.01.org
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Jiewen Yao" <jiewen.yao@intel.com>,
	"Chao Zhang" <chao.b.zhang@intel.com>,
	"Star Zeng" <star.zeng@intel.com>,
	"Laszlo Ersek" <lersek@redhat.com>
Subject: [PATCH v2 1/1] SecurityPkg: fix ZeroMem HashInterfaceHob
Date: Wed,  7 Mar 2018 12:24:41 +0100	[thread overview]
Message-ID: <20180307112441.20278-1-marcandre.lureau@redhat.com> (raw)

From: Marc-André Lureau <marcandre.lureau@redhat.com>

The ZeroMem() call goes beyond the HashInterfaceHob structure, causing
HOB list corruption. The intent was to clear all but the Identifier,
that is starting from HashInterfaceCount.

Quoting Laszlo Ersek:
  Therefore I think the *first* approach to actually fixing this bug would
  be to simply add the "Count" suffix:

  > diff --git a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
  > index dbee0f2531bc..a869fffae3fe 100644
  > --- a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
  > +++ b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
  > @@ -424,7 +424,10 @@ HashLibBaseCryptoRouterPeiConstructor (
  >      // This is the second execution of this module, clear the hash interface
  >      // information registered at its first execution.
  >      //
  > -    ZeroMem (&HashInterfaceHob->HashInterface, sizeof (*HashInterfaceHob) - sizeof (EFI_GUID));
  > +    ZeroMem (
  > +      &HashInterfaceHob->HashInterfaceCount,
  > +      sizeof (*HashInterfaceHob) - sizeof (EFI_GUID)
  > +      );
  >    }
  >
  >    //

  On the other hand, I don't think such a fix would be great. First of
  all, the HASH_INTERFACE_HOB struct definition is not wrapped in

  #pragma pack (1)
  ...
  #pragma pack ()

  in other words, HASH_INTERFACE_HOB is not packed, hence there could be
  an unspecified amount of padding between "Identifier" and
  "HashInterfaceCount". That would lead to the same kind of buffer
  overflow, because "Length" includes the padding, but the "Buffer"
  argument doesn't.

  Second, even if there were no padding (and thus the byte count would be
  a perfect match for the full HOB structure), in the "Buffer" argument
  we take the address of the "HashInterfaceCount" field, and with the
  "Length" field, we still overflow that *individual* field. Although we
  wouldn't overflow the containing HOB structure, this is still (arguably)
  undefined behavior -- I seem to remember that some compilers actually
  blow up on this when you use the standard ISO C memcpy() or memset()
  functions in such contexts.

This patch takes Laszlo suggestion to fix the issue.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
 .../HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c   | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
index dbee0f2531bc..84c1aaae70eb 100644
--- a/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
+++ b/SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterPei.c
@@ -397,6 +397,7 @@ HashLibBaseCryptoRouterPeiConstructor (
 {
   EFI_STATUS            Status;
   HASH_INTERFACE_HOB    *HashInterfaceHob;
+  UINTN                 ClearStartOffset;
 
   HashInterfaceHob = InternalGetHashInterfaceHob (&gZeroGuid);
   if (HashInterfaceHob == NULL) {
@@ -424,7 +425,11 @@ HashLibBaseCryptoRouterPeiConstructor (
     // This is the second execution of this module, clear the hash interface
     // information registered at its first execution.
     //
-    ZeroMem (&HashInterfaceHob->HashInterface, sizeof (*HashInterfaceHob) - sizeof (EFI_GUID));
+    ClearStartOffset = OFFSET_OF (HASH_INTERFACE_HOB, HashInterfaceCount);
+    ZeroMem (
+      (UINT8 *)HashInterfaceHob + ClearStartOffset,
+      sizeof (*HashInterfaceHob) - ClearStartOffset
+      );
   }
 
   //
-- 
2.16.2.346.g9779355e34



             reply	other threads:[~2018-03-07 11:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07 11:24 marcandre.lureau [this message]
2018-03-07 14:55 ` [PATCH v2 1/1] SecurityPkg: fix ZeroMem HashInterfaceHob Marc-André Lureau
2018-03-07 15:09   ` Zeng, Star
2018-03-07 15:35     ` Zhang, Chao B
2018-03-07 20:55       ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180307112441.20278-1-marcandre.lureau@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox