Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 29 Nov 2018 17:38:14 -0500
From: Daniel Kahn Gillmor <>
To: Hanno Böck <>,
Subject: Re: memory safety bugs in bc

On Thu 2018-11-29 23:12:55 +0100, Hanno Böck wrote:
> The idea here is that "mild" memory safety violations (invalid reads,
> nullptr) don't get security treatment if they're in a standalone tool,
> yet they do if they're in a library, which may have larger implications
> in more complex apps.

Sure, i understand how memory errors in libraries offer a much larger
"attack surface" than errors in code called across a process boundary.

However, i am used to looking at a lot of code that calls across process
boundaries (hello, GnuPG!) and i can tell you that there's a lot of
software out there that doesn't cope well with (or, maybe worse, doesn't
even notice) surprising terminations, surprising output on certain file
descriptors, or surprising return codes.  sounds like two of your 5
examples have at least surprising terminations and return codes.

These oversights can lead to other failures or problems that we don't
expect, so i'm reluctant to encourage people to ignore them, though i
grant that these failures with full memory access is even worse :)


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.