Be careful of dynamic assertions

Jeffrey Walton <noloader@...>
 

Hi Everyone,

Thanks for the service. I really like the idea of a mini Security
Architecture document so projects can discuss their governance,
policies and procedures. I've written a lot of them over they years
and I know they are helpful.

I recently added Crypto++ to CII. Also see
https://bestpractices.coreinfrastructure.org/en/projects/3806.

Under "Dynamic code analysis", one of the recommendations is:

It is SUGGESTED that the software produced by the project include
many run-time assertions...

As a C/C++/ObjC developer when I see "run-time assertions" I think of
Posix assert (https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/assert.h.html).
Runtime assertions in production software could be bad for several
reasons.

Let me preface it with: runtime assertions are not dangerous at
development time. At development time they aide the programmer by
snapping the debugger. Asserts create self-debugging code in this
instance. I embrace asserts at development time.

Runtime assertions are not dangerous to some software in production,
like music players and video players. An assert may annoy a user, but
the app is not handling sensitive information so it is just another UI
bug.

However, high integrity software must be careful of assertions in
production. Here are the reasons given for Crypto++ in the CII report.

<SNIP>
The library never asserts in production for four reasons. First, it is
the application's authors decision to crash their app. The library
does not make policy decisions for the application author.

Second, some platforms, like Apple iOS, do not allow asserts to crash
an application because it degrades the UI experience. The library will
not cause an author's app to be rejected from an App Store.

Third, the library handles sensitive information like private keys,
shared secrets and passwords. When an assert fires the core file will
include the sensitive information. That means the sensitive
information has been egressed outside the application's security
boundary. Folks with access to the mobile device or a computer
paired/sync'd with a mobile device will be able to recover the secrets
from the filesystem.

Fourth, the core file may be shipped to an Error Reporting Service.
Now Apple, Google, Fedora, Red Hat, Ubuntu or Microsoft have the
user's private keys, shared secrets and passwords. Then the
information is passed onto the developer who has the user's private
keys, shared secrets and passwords.

Fifth, when an assert crashes a server, it (1) may preserve data
Integrity at the expense of (2) Confidentiality of the data and (3)
Availability of the server. If an author wishes to preserve Integrity,
they merely need to call exit(1) without the loss of Confidentiality.
</SNIP>

In fact, when I was working as a Security Architect in US Financial
(Bank of America and Morgan Stanley), we would reject vendor apps that
used asserts in production. There was too much financial and
reputational risk with using asserts. The firm did not want to pay a
regulatory fine or suffer the reputational harm because customer SSNs
were not handled properly.

Also see "GMP and assert()" on LWN at
https://lwn.net/Articles/780817/. It caused a shit storm when posted
to OSS Security mailing list.

Jeffrey Walton
Baltimore, MD, US

Join Cii-badges-questions@lists.coreinfrastructure.org to automatically receive all group messages.