Thank you, I've reached out to MITRE for CVE numbers, I will
communicate them once assigned (hopefully within a few days).
Best regards,
Jonathan
On Tue, Feb 11, 2025 at 1:29 PM Tom Rini <tr...@konsulko.com> wrote:
>
> On Tue, Feb 11, 2025 at 08:26:37AM -0800, Jonathan Bar Or wrote:
> > Hi Tom and the rest of the team,
> >
> > Please let me know about fix time, whether this is acknowledged and
> > whether you're going to request CVE IDs for those or if I should do
> > it.
> > The reason is that I found similar issues in other bootloaders, so I'm
> > trying to synchronize all of them. For what it's worth, Barebox has
> > similar issues and are currently fixing.
>
> Yes, these seem valid. We don't have a CVE requesting authority so if
> you want them, go ahead and request them. You saw Gao Xiang's response
> for erofs, and I'm hoping one of the squashfs maintainers will chime in.
>
> >
> > Best regards,
> > Jonathan
> >
> > On Mon, Feb 10, 2025 at 7:51 PM Gao Xiang <hsiang...@linux.alibaba.com>
> > wrote:
> > >
> > > Hi Tom,
> > >
> > > On 2025/2/11 00:41, Tom Rini wrote:
> > > > On Fri, Feb 07, 2025 at 09:53:01AM -0800, Jonathan Bar Or wrote:
> > > >
> > > >> Thank you.
> > > >>
> > > >> So, I'm attaching my findings in a md file - see attachment.
> > > >> All of those could be avoided by using safe math, such as
> > > >> __builtin_mul_overflow and __builtin_add_overflow, which are used in
> > > >> some
> > > >> modules in Das-U-Boot.
> > > >> There are many cases where seemingly unsafe addition and
> > > >> multiplication can
> > > >> cause integer overflows, but not all are exploitable - I believe the
> > > >> ones I
> > > >> report here are.
> > > >>
> > > >> Let me know your thoughts.
> > > >
> > > > Adding in the eorfs and squashfs maintainers..
> > > >
> > > >>
> > > >> Best regards,
> > > >> Jonathan
> > > >>
> > > >> On Fri, Feb 7, 2025 at 7:50 AM Tom Rini <tr...@konsulko.com> wrote:
> > > >>
> > > >>> On Thu, Feb 06, 2025 at 07:47:54PM -0800, Jonathan Bar Or wrote:
> > > >>>
> > > >>>> Dear U-boot maintainers,
> > > >>>>
> > > >>>> What is the best way of reporting security vulnerabilities (memory
> > > >>>> corruption issues) to Das-U-Boot? Is there a PGP key I should be
> > > >>>> using?
> > > >>>> I have 4 issues that I think are worth fixing (with very easy fixes).
> > > >>>>
> > > >>>> Best regards,
> > > >>>> Jonathan
> > > >>>
> > > >>> Hey. As per https://docs.u-boot.org/en/latest/develop/security.html
> > > >>> please post them to the list in public. If you have possible solutions
> > > >>> for them as well that's even better. Thanks!
> > > >>>
> > > >>> --
> > > >>> Tom
> > > >>>
> > > >
> > > >> Filesystem-based Das-U-Boot issues.
> > > >>
> > > >> == erofs
> > > >>
> > > >> === Integer overflow leading to buffer overflow in symlink resolution
> > > >> In file `fs.c`, when resolving symlinks, the function `erofs_off_t`
> > > >> gets an `erofs_inode` argument and performs a lookup on the symlink.
> > > >> The function blindly trusts the `i_size` member of the input as such:
> > > >>
> > > >> ```c
> > > >> size_t len = vi->i_size;
> > > >> char *target;
> > > >> int err;
> > > >>
> > > >> target = malloc(len + 1);
> > > >> if (!target)
> > > >> return -ENOMEM;
> > > >> target[len] = '\0';
> > > >>
> > > >> err = erofs_pread(vi, target, len, 0);
> > > >> if (err)
> > > >> goto err_out;
> > > >> ```
> > > >>
> > > >> The `erofs_inode` structure's `i_size` member is defined with the type
> > > >> `erofs_off_t` (which is a 64-bit unsigned integer).
> > > >> Thereofre, if supplied as 0xFFFFFFFFFFFFFFFF, the `len + 1` input to
> > > >> `malloc` would overflow to 0, allocating a chunk with 0.
> > > >> That chunk (saved in `target`) is later written with `erofs_pread`,
> > > >> overriding the chunk with partial data controlled by an attacker.
> > > >> Therefore, we will have a heap buffer overflow due to an integer
> > > >> overflow in `len` calculation.
> > >
> > > Yeah, it's a corner case, I will try to address it later.
> > >
> > > Thanks,
> > > Gao Xiang
>
> --
> Tom
