Re: [Libcdio-devel] Rock Ridge and libisofs/xorriso 'AL' extension

[Rocky Bernstein]

On Fri, Jul 28, 2017 at 10:45 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> if Rocky agrees that
>   https://savannah.gnu.org/bugs/?45015
> can be solved by changing
>   offset++;
> to
>   offset+= ISO_BLOCKSIZE - (offset % ISO_BLOCKSIZE);
> and that the whitelist of SUSP signatures can then be dropped,
> there remain two issues which made the further wrong consequences
> of the bug possible.
>

Thanks for your support. I promise I'll look at over the weekend. First
thought is that this is okay,
but I should do due diligence.


> I am not sure whether they need action. But i think they should be
> named and described here:
>
> 1:
>
> libcdio did not notice that the mistaken directory record (caused by the
> stray byte with value 128) reached over the end of the current block.
>
> One could add such a check to increase security against bad ISOs
> like the one of bug 45015.
>
> 2:
>
> libcdio seems to assume a valid chain of SUSP fields when it encounters
> additional space after the end of ISO 9660 file name and possible padding
> byte. But the existence of System Use Area does not imply that there is
> the SUSP protocol inside.
>
> I got a link to SUSP-1.10 from Ady Ady whom i know from the SYSLINUX list:
>   https://archive.org/details/enf_pobox_Susp
> Already this version, which is the earliest known, prescribes mandatorily
> the presence of field "SP" in the first directory record of the root
> directory (that's the "." directory record).
>
> So actually one should not assume the byte-wise definition of SUSP fields
>
>   SIG1, SIG2, LENGTH, VERSION, DATA(1), ..., DATA(LENGTH - 4)
>
> unless the "SP" field was found at its fixely defined position, namely
> byte offset 34 and 35 of the block of which the number is recorded
> as little-endian 32-bit number at byte offset 32768+158 from the
> start of the ISO session.
> The byte sequence must be
>
>   {'S', 'P', 7, 1, 0xbe, 0xef, LEN_SKP }
>
> where any value of the LEN_SKP byte other than 0 would be an unusual
> challenge. SUSP-1.10 and 1.12 say:
>
>   "BP 7 - Bytes Skipped (LEN_SKP)" shall specify as an 8-bit number
>   the number of bytes to be skipped within the System Use Area of
>   each Directory Record (except the "." entry of the root directory)
>   before recording System Use Fields other than the "SP" field.
>
> I am not aware of any ISO which has non-zero as LEN_SKP.
> So i doubt that provisions for that are tested, if they exist at all.
>
> Further, RRIP-1.10 prescribes the existence of an "ER" field with
> Extension Identifier "RRIP_1991A".
> RRIP-1.12 prescribes "IEEE_P1282" instead.
> There are also RRIP-1.12 documents which say "IEEE_1282" (without a "P")
> All three should be considered valid.
>
> The "ER" filed has to be among the SUSP fields of the first directory
> record of the root directory. I.e. in the same record which bears the
> "SP" record or in its SUSP Continuation Area.
>
> Normally i would strongly urge to first check for "SP" indicating SUSP,
> and only then for an "ER", which indicates Rock Ridge, and only then
> enable reading of the System Use Area when accessing directories in
> that ISO.
>
> But to my assessment, the Linux kernel is quite as tolerant towards
> missing "SP" or "ER" with one of above Extension Identifiers.
> libcdio could well declare this as its guideline.
> In that case i would put more emphasis on a check against block limit
> crossing.
>
>
> Have a nice day :)
>
> Thomas
>
>
>