[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Y2RcnxVZFaql5VNo@itl-email>
Date: Thu, 3 Nov 2022 20:28:10 -0400
From: Demi Marie Obenour <demi@...isiblethingslab.com>
To: oss-security@...ts.openwall.com
Cc: nic.tuv@...il.com, Hanno Böck <hanno@...too.org>
Subject: Re: OpenSSL X.509 Email Address 4-byte Buffer
Overflow (CVE-2022-3602), X.509 Email Address Variable Length Buffer
Overflow (CVE-2022-3786)
On Thu, Nov 03, 2022 at 08:23:32PM +0000, Sam James wrote:
>
>
> > On 3 Nov 2022, at 16:32, Nicola Tuveri <nic.tuv@...il.com> wrote:
> >
> > I can also add that at least this member of the OpenSSL Technical
> > Committee is following the discussion, and I believe I am not the only
> > one.
> >
> > The feedback shared here on oss-security is read and carefully
> > considered, and I know it will be discussed within OTC to continue the
> > ongoing process of improving the OpenSSL project and its procedures.
>
> I'd like to thank the OpenSSL developers for being open to the
> CI improvements I've been making lately.
>
> >
> > I totally concur with Tavis Ormandy:
> >> this is active prolific opensource security researchers discussing their opensource security work on the opensource security mailing list :)
> >
> > Personally, I'd like to thank you all for the feedback so far, as it
> > is in itself a contribution to the project, even when it is harsh and
> > reminds us of our mistakes.
> > As long as it is kept polite and constructive, as it has been so far
> > here, all feedback is very welcome and valuable.
>
> Something I think that should be revisited is the priority
> of undefined behaviour in the codebase.
>
> Undefined behaviour can - and has [0][1] - led to misbehaviour
> at runtime.
>
> Part of living with "Modern C" is embracing the
> techniques we have available to enhance compiler diagnostics
> and detect problems. That includes LTO, as well, which
> generally leads to _far_ better compiler warnings.
>
> The OpenSSL codebase isn't strict aliasing clean, and in
> Gentoo, we've built with -fno-strict-aliasing since ~2005
> (note that -fstrict-aliasing is enabled by default with -O2
> in GCC since at least 10 years ago).
>
> If at all possible, I'd ask that the OpenSSL team revisit
> its assessment of the severity of strict aliasing bugs
> as well as the value of LTO in enhancing diagnostics
> and finding bugs.
-fno-strict-aliasing is definitely the right call. I use it pretty much
everywhere, as complying with the strict aliasing rules is often just
not worth the effort. I suspect that wl_container_of (used in every C
program using libwayland) may violate strict aliasing, and I am nearly
certain X11 clients do.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
