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
next prev parent 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.