All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: grub-devel@gnu.org
Cc: lidong.chen@oracle.com, fengtao40@huawei.com, yanan@huawei.com,
	daniel.kiper@oracle.com, lichenca2005@gmail.com
Subject: Re: Proposal v2: fs/iso9660: Prevent skipping CE or ST at start of continuation area
Date: Mon, 09 Jan 2023 10:32:48 +0100	[thread overview]
Message-ID: <230133879046361020781@scdbackup.webframe.org> (raw)
In-Reply-To: <3E68809E-2A2B-46AF-8F09-40BB0FC42D60@ORACLE.COM>

Hi,

Lidong Chen wrote:
> Thanks for the clarification. I created a new patch for the fix and added
> you as the “Signed-off-by”.
> My question is how to test it.

I just sent libisofs into an endless recursion loop. Grrr.
For this i created a small ISO with a file which surely needs a CE, changed
its fields so that it points to itself, and attempted to load it by xorriso.
(At least it ends by SIGSEGV on an exhausted stack and does not cycle
endlessly.)

--------------------------------------------------------------------------
ISO creation:

   # A dummy file as payload
   echo x >x

   # 250 fattr characters to surely exceed the size of a directory entry
   long_string=0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789

   # Create ISO with the payload file and attached fattr named user.dummy
   test -e ce_loop.iso && rm ce_loop.iso
   xorriso -outdev ce_loop.iso \
           -xattr on \
           -map x /x \
           -setfattr user.dummy "$long_string" /x -- \
           -padding 0

Next i determined by a hex dumper the location of the only Rock Ridge
entry NM and then the location of the next following CE entry (the first
CE belongs to the root directory):
  Byte 102734 decimal = 50 * 2048 + 334 = LBA 0x32 + Offset 0x014e
The size of the continuation area is 270 = 0x010e
The length of CE is 28 = 0x1c

So i patched the own address and size of the CE entry into its fields:

  # The block address (little endian and big endian)
  echo $'\x32' | dd bs=1 seek=102738 count=1 conv=notrunc of=ce_loop.iso
  echo $'\x32' | dd bs=1 seek=102745 count=1 conv=notrunc of=ce_loop.iso

  # The byte offset in that block
  echo $'\x4e'$'\x01' | dd bs=1 seek=102746 count=2 conv=notrunc of=ce_loop.iso
  echo $'\x01'$'\x4e' | dd bs=1 seek=102752 count=2 conv=notrunc of=ce_loop.iso

  # The new size of the CE area is the length of the CE entry
  echo $'\x1c' | dd bs=1 seek=102754 count=1 conv=notrunc of=ce_loop.iso
  echo $'\x1c' | dd bs=1 seek=102761 count=1 conv=notrunc of=ce_loop.iso
  # Zeroize the higher valued bytes of the length field
  dd if=/dev/zero bs=1 seek=102755 count=6 conv=notrunc of=ce_loop.iso

This really bad CE entry then looks in the hex dump like:

00019140 :    00  7b  01  09  08  08  1c  00  4e  4d  06  01  00  78  43  45
                   {                           N   M               x   C   E
  102720 :     0 123   1   9   8   8  28   0  78  77   6   1   0 120  67  69

00019150 :    1c  01  32  00  00  00  00  00  00  32  4e  01  00  00  00  00
                       2                           2   N
  102736 :    28   1  50   0   0   0   0   0   0  50  78   1   0   0   0   0

00019160 :    01  4e  1c  00  00  00  00  00  00  1c  00  00  00  00  00  00
                   N
  102752 :     1  78  28   0   0   0   0   0   0  28   0   0   0   0   0   0

(Note: 00019140 is hex, not octal)

--------------------------------------------------------------------------

I will first try to fix libisofs before i upload this gremlin somewhere.

If you want to try in advance, run above shell commands and check whether
a hex editor shows the expected bytes afterwards. (xorriso is supposed to
be reproducible in respect to sizes and locations. Very old versions might
not fulfill that expectation, though.)


Have a nice day :)

Thomas



  reply	other threads:[~2023-01-09  9:35 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-14 18:55 [PATCH 0/4] fs/iso9660: Fix out-of-bounds read Lidong Chen
2022-12-14 18:55 ` [PATCH 1/4] fs/iso9660: Add check to prevent infinite loop Lidong Chen
2022-12-15 17:52   ` Thomas Schmitt
2022-12-19  8:16     ` Lidong Chen
2022-12-19  9:42       ` Thomas Schmitt
2022-12-14 18:55 ` [PATCH 2/4] fs/iso9660: Prevent read past the end of system use area Lidong Chen
2022-12-15 18:00   ` Thomas Schmitt
2022-12-19  8:39     ` Lidong Chen
2022-12-16  8:54   ` Thomas Schmitt
2022-12-16  9:42   ` Proposal: fs/iso9660: Prevent skipping CE or ST at start of continuation area Thomas Schmitt
2022-12-16 12:57     ` Proposal v2: " Thomas Schmitt
2022-12-20 21:08       ` Lidong Chen
2023-01-06  5:30       ` Lidong Chen
2023-01-06 16:00         ` Thomas Schmitt
2023-01-09  7:34           ` Lidong Chen
2023-01-09  9:32             ` Thomas Schmitt [this message]
2023-01-11 11:54               ` Thomas Schmitt
2023-01-12  5:28                 ` Lidong Chen
2023-01-12  8:45                   ` Thomas Schmitt
2022-12-14 18:55 ` [PATCH 3/4] fs/iso9660: Avoid reading past the entry boundary Lidong Chen
2022-12-15 18:08   ` Thomas Schmitt
2022-12-19  8:42     ` Lidong Chen
2022-12-14 18:55 ` [PATCH 4/4] fs/iso9660: Incorrect check for entry boudary Lidong Chen
2022-12-15 18:20   ` Thomas Schmitt
2022-12-19 21:00     ` Lidong Chen
2022-12-20  9:21       ` Thomas Schmitt
2022-12-14 21:42 ` [PATCH 0/4] fs/iso9660: Fix out-of-bounds read Thomas Schmitt
2022-12-19  8:07   ` Lidong Chen

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-all 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=230133879046361020781@scdbackup.webframe.org \
    --to=scdbackup@gmx.net \
    --cc=daniel.kiper@oracle.com \
    --cc=fengtao40@huawei.com \
    --cc=grub-devel@gnu.org \
    --cc=lichenca2005@gmail.com \
    --cc=lidong.chen@oracle.com \
    --cc=yanan@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.