Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 01 Jan 2019 13:12:04 +0000
From: halfdog <me@...fdog.net>
To: oss-security@...ts.openwall.com
Subject: Re: Asserts considered harmful (or GMP spills its sensitive information)

Jeffrey Walton writes:
> The GMP library uses asserts to crash a program at runtime
> when presented with data it did not expect.  ...

For me, that seems to be the best way. In the end the discussion
is mostly about if you value confidentiality and integrity over
availability (and a little confidentiality as shown by you).

Usually for highly secure systems (those where availability
is top priority are quite often safety-critical, not security),
you can mitigate effects of such a DoS permanently (by fixing
the program) but you cannot reverse the effects of leaked data,
which happens more easily by corrupting/manipulating a target
program state and get the data exfiltrated by the target itself
than gaining access to the machine another way and read (unnoticed)
core dumps created even via another mechanism.

Also cleaning up corrupted data is often much more expensive
than having some outage and then start again. This is what your
24/7 devops team is for (with highly secure systems).


So in my opinion your example, even when it demonstrates a small
information leak on aborting, is even a better example, why
aborting was the right thing to do: on the first highly secure
system, where your software aborted, the malfunction was detected
immediately and easily. Thus it was possible to fix it timely
and you avoided having broken software running for years without
getting noticed (by developers, operators or worse: attackers).

Note 1: The only exception for functions NOT aborting on corrupted
data are secure "validate-data-functions" or "parse-functions"
(if they provide secure data validation also).

Note 2: Little off-topic, but in the same line more APIs should
abort on insane requests. So for example I do not understand, why
read(2) should EFAULT on bad addresses instead of SEGV. The only
thing I use this feature for is to probe memory maps inside chroots
(or where /proc/self/maps is inaccessible for other reasons).
But maybe EFAULT is a very useful POSIX feature in use cases
I did not think about yet.

hd


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.