[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o7vrksad.fsf@hope.eyrie.org>
Date: Wed, 07 Sep 2022 10:28:42 -0700
From: Russ Allbery <eagle@...ie.org>
To: oss-security@...ts.openwall.com
Subject: Re: sagemath denial of service with abort() in gmp:
overflow in mpz type
Georgi Guninski <gguninski@...il.com> writes:
> on ubuntu 20 a lot of stuff depends on libgmp:
> $ apt-cache rdepends libgmp10 | wc -l
> 2442
> $ apt-cache rdepends libgmp10 | grep -i crypt | wc -l
> 28
> some examples:
> gcc-9
> gawk
> g++-9
> dnsmasq-base
> cpp-9-s390x-linux-gnu
> will the infidels who argue that crash in python is nothing
> still will claim that gmp crash in any of the 2442 packages
> is still nothing?
I don't think anyone here is trying to defend the behavior of gmp. That
it aborts on unexpected input has been a long-standing problem that's
provoked a lot of discussion elsewhere. It's certainly surprising, and it
violates the expectations that a lot of people have about how libraries
should work. (I feel obligated to say that the gmp maintainers do have
reasons for why they do this, so it's not a one-sided debate, but I think
everyone would agree that the error handling is less than ideal and
primarily disagree about whether doing better is practically feasible for
this specific library.)
The point that I think folks are making, and at least the point that I'm
making, is that not all bugs are security bugs. Even very serious bugs
are not necessarily security bugs. You'll find a bit of skepticism from
time to time in the security community about declaring something a
security bug because it's not uncommon for people to try to use security
as a lever to get a bug that annoys them fixed. (I'm not saying you're
doing this, just that we've all seen it happen at one point or another.)
The ability to make a program crash is not inherently a security bug. The
ability to make a program dump cryptographic keys to a core dump file is
not inherently a security bug if the same person who can make it do that
can also attach to it with gdb and just read the keys directly out of
memory. (And if you're particularly concerned about the core dump case,
just turning off core dumps globally for your security-sensitive
application may be easier than trying to chase each possible cause of a
core dump.) Sometimes this is equivalent to Ctrl-C or kill -SEGV or other
operations that, while possibly unexpected, fall within the expected
permission model. There has to be some sort of impact on the permission
model for it to be a security bug.
There probably *are* such cases in the long list of things that depend on
gmp. That abort() behavior has led to DoS security bugs and potential
information leakage via core dumps in the past and probably will in the
future. But, for example, I'm skeptical that there is a case where
forcing gcc to crash with invalid input is going to count as a very
interesting security bug. If you're running gcc with untrusted input,
you're probably already in a world where you need to be doing heavy
sandboxing, and I'm not sure gmp's behavior is going to be your biggest
challenge.
--
Russ Allbery (eagle@...ie.org) <https://www.eyrie.org/~eagle/>
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.
