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: Wed, 11 Jan 2023 12:54:40 +0100 [thread overview]
Message-ID: <12539387680444945206@scdbackup.webframe.org> (raw)
In-Reply-To: <230133879046361020781@scdbackup.webframe.org>
Hi,
i created another bad ISO which i expect to lead to an endless loop in
existing GRUB (i.e. before applying the proposed change).
Both ISOs can be downloaded as gzip-compressed files now:
http://scdbackup.webframe.org/ce_loop.iso.gz
SHA256: d86b73b0cc260968f50c30a5207b798f5fc2396233aee5eb3cedf9cef069f3c2
http://scdbackup.webframe.org/ce_loop2.iso.gz
SHA256: a6bde0c1562de8959d783bca0a79ad750da2bc129bdea2362b4a7c3e83426b2c
They are smaller than 1 KB and expand to 128 KiB, each.
(Please do not load these ISOs into existing xorriso programs by commands
like -indev. ce_loop.iso leads to SIGSEGV. ce_loop2.iso leads to an
endless loop. The libisofs code fix is only in git for now.)
------------------------------------------------------------------------
Test proposals for GRUB:
If reading ce_loop.iso by GRUB leads to an error message, then my proposed
change is in effect and protected against endless loops.
Original GRUB is supposed to just ignore that situation, because it skips
over the CE entry by mistake.
If reading ce_loop2.iso by GRUB leads to an error message, then the
proposed safety precaution against endless loops is in effect.
I expect unpatched GRUB to loop endlessly with this ISO.
------------------------------------------------------------------------
About the production of ce_loop2.iso:
The CE entry of its file /x points to a dummy SUSP entry XY of length 8
which sits directly before the CE entry. So this dummy entry is the
first to be read by GRUB from the pseudo-contination area, gets processed
by the hook() function (with no side effects), and is then followed by
the CE entry.
Because of the existence of the XY entry, i expect the CE entry not to
be skipped by existing GRUB.
# Production begins by the bad ISO of January 9 where the CE entry
# points to itself
cp ce_loop.iso ce_loop2.iso
# Cut out a copy of the bad CE entry
dd if=ce_loop2.iso bs=1 skip=102734 count=28 of=ce_entry
# After the CE entry is plenty of unused space in the same block.
# The length of the directory entry of /x plus 8 will not exceed 255.
# So put the copy back with an offset of 8 bytes.
dd if=ce_entry bs=1 seek=102742 conv=notrunc of=ce_loop2.iso
# Rename the old CE entry head to XY
echo "XY" | dd bs=1 seek=102734 count=2 conv=notrunc of=ce_loop2.iso
# Give it the length of 8
echo $'\x08' | dd bs=1 seek=102736 count=1 conv=notrunc of=ce_loop2.iso
# Set in the new CE entry the continuation area length to 8 + 28 = 36
echo $'\x24' | dd bs=1 seek=102762 count=1 conv=notrunc of=ce_loop2.iso
echo $'\x24' | dd bs=1 seek=102769 count=1 conv=notrunc of=ce_loop2.iso
# Change the length of the directory record from 134 to 142
echo $'\x8e' | dd bs=1 seek=102628 count=1 conv=notrunc of=ce_loop2.iso
The resulting bytes of the whole directory record of /x are then:
000190e0 : .. .. .. .. 8e 00 37 00 00 00 00 00 00 37 02 00
. . . . 7 7
102624 : ... ... ... ... 142 0 55 0 0 0 0 0 0 55 2 0
000190f0 : 00 00 00 00 00 02 7b 01 09 08 08 1c 00 00 00 00
{
102640 : 0 0 0 0 0 2 123 1 9 8 8 28 0 0 0 0
00019100 : 01 00 00 01 04 58 2e 3b 31 00 50 58 24 01 a4 81
X . ; 1 P X $
102656 : 1 0 0 1 4 88 46 59 49 0 80 88 36 1 164 129
00019110 : 00 00 00 00 81 a4 01 00 00 00 00 00 00 01 e8 03
102672 : 0 0 0 0 129 164 1 0 0 0 0 0 0 1 232 3
00019120 : 00 00 00 00 03 e8 e8 03 00 00 00 00 03 e8 54 46
T F
102688 : 0 0 0 0 3 232 232 3 0 0 0 0 3 232 84 70
00019130 : 1a 01 0e 7b 01 09 08 08 1c 00 7b 01 09 08 08 2f
{ { /
102704 : 26 1 14 123 1 9 8 8 28 0 123 1 9 8 8 47
00019140 : 00 7b 01 09 08 08 1c 00 4e 4d 06 01 00 78 58 59
{ N M x X Y
102720 : 0 123 1 9 8 8 28 0 78 77 6 1 0 120 88 89
00019150 : 08 01 32 00 00 00 43 45 1c 01 32 00 00 00 00 00
2 C E 2
102736 : 8 1 50 0 0 0 67 69 28 1 50 0 0 0 0 0
00019160 : 00 32 4e 01 00 00 00 00 01 4e 24 00 00 00 00 00
2 N N $
102752 : 0 50 78 1 0 0 0 0 1 78 36 0 0 0 0 0
00019170 : 00 24 .. .. .. .. .. .. .. .. .. .. .. .. .. ..
$ . . . . . . . . . . . . . .
102768 : 0 36 ... ... ... ... ... ... ... ... ... ... ... ... ... ...
------------------------------------------------------------------------
Have a nice day :)
Thomas
next prev parent reply other threads:[~2023-01-11 11:56 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
2023-01-11 11:54 ` Thomas Schmitt [this message]
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=12539387680444945206@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.