[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87r2f3wlux.fsf@fifthhorseman.net>
Date: Thu, 29 Nov 2018 17:38:14 -0500
From: Daniel Kahn Gillmor <dkg@...thhorseman.net>
To: Hanno Böck <hanno@...eck.de>,
oss-security@...ts.openwall.com
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 :)
--dkg
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.
