Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 Jan 2019 12:20:42 +0100
From: Vincent Lefevre <vincent@...c17.net>
To: Jeffrey Walton <noloader@...il.com>
Cc: oss-security@...ts.openwall.com, gmp-bugs@...lib.org
Subject: Re: Asserts considered harmful (or GMP spills its sensitive
 information)

On 2018-12-31 14:38:17 -0500, Jeffrey Walton wrote:
> On Mon, Dec 31, 2018 at 2:16 PM Vincent Lefevre <vincent@...c17.net> wrote:
> >
> > On 2018-12-31 13:03:27 -0500, Jeffrey Walton wrote:
> > > The GMP library uses asserts to crash a program at runtime when
> > > presented with data it did not expect. The library also ignores user
> > > requests to remove asserts using Posix's -DNDEBUG. Posix asserts are a
> > > deugging aide intended for developement, and using them in production
> > > software ranges from questionable to insecure.
> >
> > That's much better than letting the program run erratically, with
> > possible memory corruption and/or sensitive information leakage
> > to unauthorized users. You'd better fix bugs in your program.
> 
> To play devil's advocate for this particular example, GMP could have
> validated the parameters and refused to process the data. That is, the
> function could have returned failure and avoided the potential
> information leak.

Unfortunately, this is not always possible, while keeping the original
interface. Moreover, changing the interface can make the library
slower, which could be an issue for GMP (the goal is to be as fast
as possible, just like the C language was designed, where contrary
to other languages, there's the notion of undefined behavior). If you
don't like that, you can write a wrapper library that will sanitize
all the inputs and implement error processing (e.g. where the return
value contains an error code and the result, if any), and call this
library instead of GMP.

Said that, developers who forget to check whether they correctly
follow the API conditions also forget to check failures. Thus this
ends up with a similar issue (a crash).

Moreover, some asserts may come from the detection of an inconsistent
state. In this case, it is better to abort. Otherwise letting the
program continue may have worse consequences.

-- 
Vincent Lefèvre <vincent@...c17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Powered by blists - more mailing lists

Your e-mail address:

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.