[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAHN_R2F99BmuwkLMiL8MFeuoB0UxdvVxLaRxXP3z2nebY_B=g@mail.gmail.com>
Date: Fri, 23 Jun 2023 07:29:40 -0400
From: Siddhesh Poyarekar <siddhesh.poyarekar@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2023-31975: memory leak in yasm
On Fri, Jun 23, 2023 at 2:40 AM Smith, Stewart <trawets@...zon.com> wrote:
> I don’t think you are, I can’t see anything here either.
>
> Even if you were doing all the wrong things and running a yasm-as-a-service continually building untrusted source right alongside other processes as the same user, that contain all sorts of things you don’t want exposed, I still don’t see how this would be anything but a 0.0.
I know you probably only said that for effect but if someone is
running a compiler-as-a-service building untrusted source but hasn't
sandboxed it, the security issue is in the setup, not the compiler.
Compilers for the most part have to assume trusted input because not
doing so is a practical nightmare. The golang project is the only one
I know that accepts CVEs for untrusted input to the compiler (more
power to them, and commiserations to the ecosystem that has to
continuously respin everything to appease the CVE bots) while all
other projects, implicitly or otherwise, reject the notion that you
can just throw them on the internet and assume everything will be OK.
Sid
--
https://gotplt.org
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
