Re: [Libcdio-devel] Vulnerable use of strcpy in iso9660_fs.c

2024-05-13 Thread Rocky Bernstein
Just wanted to post a follow-up on this. Mansour Gashasbi has reminded me about this. He is willing to come up with a set of patches for the issues he has come across. So expect a request for comments on this when it come through. (I am back from a wonderful time at BlackHat Asia 2024 - talk text

Re: [Libcdio-devel] Vulnerable use of strcpy in iso9660_fs.c

2024-04-09 Thread Pete Batard
On 2024.04.09 09:00, Thomas Schmitt via Libcdio-devel wrote: Hi, Pete Batard wrote: Or maybe there's a mathematical proof that a UTF-8 glyph byte encoding can never be larger than 1.5 the UTF-16 glyph byte encoding I thought to have given one. Let me try again: https://datatracker.ietf.or

Re: [Libcdio-devel] Vulnerable use of strcpy in iso9660_fs.c

2024-04-08 Thread Thomas Schmitt via Libcdio-devel
Hi, Pete Batard wrote: > Or maybe there's a mathematical proof that > a UTF-8 glyph byte encoding can never be larger than 1.5 the UTF-16 glyph > byte encoding I thought to have given one. Let me try again: https://datatracker.ietf.org/doc/html/rfc3629 "In UTF-8, characters from the U+..

Re: [Libcdio-devel] Vulnerable use of strcpy in iso9660_fs.c

2024-04-08 Thread Pete Batard
Hi Thomas, Thanks for the input. At least in Rufus (and most likely in the proposal I submit) I'm not going to bother trying to "guess" what the maximum possible size of a trick UTF-8 string might be, because, if the Unicode Comittee decides to add a bunch of new codepages where a UTF-16 seque

Re: [Libcdio-devel] Vulnerable use of strcpy in iso9660_fs.c

2024-04-08 Thread Rocky Bernstein
First of all Thomas, your suggestions are *greatly appreciated! * Right now I am getting ready for eclipse-watching in the US and am out of town and/or vacationing. But when I get back I'll soon travel to Singapore to talk at BlackHat Asia 2014 and will spend a couple of weeks in Malaysia after th

Re: [Libcdio-devel] Vulnerable use of strcpy in iso9660_fs.c

2024-04-06 Thread Thomas Schmitt via Libcdio-devel
Hi, Pete Batard wrote: > strncpy(cpy_result, p_psz_out, i_inlen); Known as nitpicker i want to to point out that this would avoid a memory corruption in case of overflow but would also truncate the name, potentially to an incomplete UTF-8 byte sequence at the end. I add the technical part of m

Re: [Libcdio-devel] Vulnerable use of strcpy in iso9660_fs.c

2024-04-06 Thread Pete Batard
Hi Rocky, The person who reported it to you originally found the issue in Rufus (which I where I pointed them to libcdio), and I am planning to patch it there when I get a chance, as well as send a proposal for a libcdio fix. The most obvious fix, since that's where we overflow and, if we loo

[Libcdio-devel] Vulnerable use of strcpy in iso9660_fs.c

2024-04-04 Thread Rocky Bernstein
I just received a report about a place in libiso9660 where we use strcpy() instead of strncpy(). If someone has a suggestion for how to fix, please let me know. I can send a more detailed report for those interested